Kuinka palkata parempia kehittäjiä

[Huomaa] Tämä on artikkeli, joka on kirjoitettu vuokrausyhtiön tai työntekijän näkökulmasta, joka haluaa saada mukavia ja päteviä kollegoja.

Aion tuoda esiin näkökohtia, jotka koskevat koko kehittäjää, mutta puhun enemmän fullstack JS -kehittäjän kokemuksesta, joten jotkut asiat eivät ehkä sovi käsineeksi sinun tapauksellesi.

Huomauttamalla nämä asiat, kyse ei ole vain siitä, mikä on suurimmassa osassa vuokrausprosesseja vikaa, vaan myös joistain keskeisistä indikaattoreista, mitä on tarkasteltava ja mitä voitaisiin parantaa (tehdä ja tehdä, mutta enimmäkseen ei).

  1. Älä kysy tyhmiä kysymyksiä

Kysymys joltakin kuinka monta ananaa mahtuu valaan ruhoon vain nähdäksesi, sopiiko se taianomaisten 'maagisten' vastaustesi tulokseen, ei auta ketään, etenkään kehittäjän aivoja.

2. Vältä painostamasta ja / tai asettamasta aikaa vievää tai liian monimutkaista paikalla tehtäviin

Ellei yrityksesi todella ole c ** p, ominaisuutta ei todennäköisesti tarvitse julkaista 20 minuutissa, ja olen melko varma, että siihen ei liity jälkityötä tai binaaripuita eikä O (n) -optimointeja hasmapsia käyttämällä.

Vastauksen saaminen sellaisista tai muista kysymyksistä riippuu myös DE: n henkisestä valmiudesta ja mielialasta kyseisenä ajankohtana, eikä se oikeastaan ​​kerro sinulle liikaa.

Se on silti kannattavaa tehdä, jos testit ovat todella yksinkertaisia ​​ja niitä käytetään vain todella huonojen suodattamiseen, tai vain sinun katsoa ajatteluprosessia ja aloittaa keskustelu kompromisseista.

3. Kirjoituskoodi paperille (erityisesti kielikohtaiset koodit)

Ellet ole Google, tämä on yleensä ärsyttävää AF: tä. Vain siksi, että suuret yritykset tekevät, se ei tarkoita, että se olisi hyvää, se tarkoittaa vain sitä, että heillä on varaa olla tuhlaukseen, koska ihmiset tulevat muutenkin tulemaan, joten heillä on vain ylellisyys saada ihmiset erittäin vahvalla teoreettisella pohjalla, vaikka he käyttäisivät sitä tieto vai ei.

Olkaamme rehellisiä, unohdat suurimman osan algoritmeista 2–3 vuoden kuluttua yliopistosta poistumisesta, ellet työskentele todella alhaisen tason tuotteen kanssa.

Mutta .. tarvitseeko hyvän kehittäjän tietää, kuinka tehdä 4 tyyppiä lajittelua? Epäilen sitä.

Tärkeää on kyky ymmärtää se vain lukemalla se ja kyetä selvittämään kunkin erot ja erityispiirteet.

Joten ehkä vain järjestä se itse ja kysy vain mitä se tekee, haasta häntä selittämään se yksinkertaisemmin, jotta ymmärretään hyvä koodi. Lisäksi, jos huomaat tarpeelliset henkiset kyvyt kääntää kyseinen kuva jotain vastaavaa, mikä on järkevämpää vähemmän tekniselle henkilölle, se olisi hienoa.

Koska jos hän tekee kaiken tämän, voit olla varma, että hän voi käydä läpi kaikki ne kuvitteelliset kuvaajaalgoritmit, joita rakastat niin paljon muutamassa päivässä, ja oppia kaiken uudelleen, jos todella tarvitset sitä.

4. Lopeta API-kysymysten esittäminen koskien sellaista tekniikkaa / kieltä, joka ei koske tätä. Etsi sen sijaan käsitteitä

Tarkoitan tällä sitä, että kysymällä joltakin MongoDB-operaation kyselykielestä / syntaksista ei ole mitään merkitystä… Mielestäni ihmiset, jotka muistavat täydellisesti API: n syntaksin sydämestäni, ovat yleensä huonompia kehittäjiä kuin ihmiset, jotka sen unohtavat.

Nyt tosissaan, kuinka muuten aiot oppia jotain uutta ja nopeaa, jos muistat asioita kuten ala-asteella? Todellisessa maailmassa sinun on opittava toinen tekniikka tommorow pitääkseen reunan.

Missä Powa'si on nyt?

Etsimällä käsitteitä tarkoitan, että sinun pitäisi esimerkiksi nähdä, tarttuuko hän käsitteisiin, kuten transaktioitavuus, skaalautuvuus, johdonmukaisuuden tyypit, integroinnin helppous ja moottorille käytettävissä olevien sovellusliittymien helppokäyttöisyys, erityyppiset tietokannat (asiakirja, sql , kuvaaja jne.) ja myös mihin sitä tulisi käyttää, tyypillisiin käyttötapoihin ja yleisiin heikkoihin / vahvoihin kohtiin.

SQL-sovellusliittymän muistaminen on toinen esimerkki "miten teet tämän LIITÄNNÄ tai tämän ja sen toiminnon". Sinun ei tarvitse muistaa, että jos sinulla on perusajatus relaatiotietokannoista, niin lopun elämääsi, hyvän kehittäjän tulisi pystyä kertomaan sinulle erilaiset tilamuunnokset ja tapa, jolla nämä tyyppisissä tietokannoissa tehtävät toiminnot tehdään, heidän kanssaan tulevat kompromissit.

Ja kaikki, vain rajaton API-käyttö.

Hyvä kehittäjä ei ole kehittäjä, joka osaa ratkaista ongelmasi paperilla, se on sellainen, joka tietää, mitkä ovat sallitut toiminnot ja abstraktiot, jotka voidaan tehdä sen ratkaisemiseksi tietyn ympäristön luomiseksi, eikä sillä välttämättä ole matriisinäyttöä hänen päänsä sisällä ohjeet tai API-dokumentaatiopalat.

Kysy häneltä esimerkiksi, millaista tietokantaa sinun pitäisi käyttää yhdelle järjestelmästäsi, joka suorittaa verkkotunnuskohtaisen tehtävän / ongelman, jonka olet kokenut projekteissasi, ja anna hänen kertoa perusteet sen taustalla.

5. Joo, mutta tiedätkö todella nämä puitteet? Kuinka paljon kokemusta sinulla on siitä?

Joskus sillä on merkitystä, joskus ei. Kysyttäessäsi, millaista kokemusta sinulla on Reaktista (puhumme ydinreagoinnista, ei koko troonikierästä kirjastokokoelmista), kysytään periaatteessa mitään, jos olet viettänyt yli 2 vuotta JS: n koodausta siihen saakka.

Itse React on korkeintaan 2–3 päivän arvoinen luku, jotta sitä voidaan käyttää käytännössä. Onko tämä "hukkaan mennyt" aika kriittinen yrityksellesi? No, jos on, ehkä se on joka tapauksessa paskayritys, joten älä välitä muuttamaan sitä ... jatka menemistä ja mene sitten pois (:

Jos ei, niin sinun kannattaa kysyä kehittäjältä esimerkiksi kuinka paljon aikaa hän vietti oppiaksesi (lisätä nimesi) kehystä, saadaksesi paremman kuvan ajatteluprosessista, mielipiteistä ja niiden asteittaisesta muutoksesta (oppimisvaiheet ja käyrät) , tukokset jne.) ja vertaa sen jälkeen näitä tietoja muihin joukkueeseen kuuluviin.

Waay hyödyllisempi. Kysy häneltä, mitä hän pitää siitä ja mitä hänellä ei ole. Tämän pitäisi antaa sinulle nopea ja hyvä käsitys siitä syvyydestä, joka hänellä on heihin, jos olet tosissasi (jostain syystä)

6. Hyvän kehittäjän tulisi osata etsiä asioita

Mielestäni tämä on se osa, joka tekee eron tuoreen grad / juniori ja keskitason tai vanhempi kehittäjä välillä.

Kyky löytää vastauksia itsellesi, etsiä lisätietoja, lukea dokumentaatiota ja etsiä muita näkökulmia.

Huonot kehittäjät yrittävät yleensä keksiä pyörän uudelleen, kun niin ei ole. Yritä etsiä tätä ominaisuutta, ja jos se puuttuu, se on ehdottomasti ei-ei.

7. Missä näet itsesi X vuoden kuluttua

Jos hän vastaa tähän pyrkimykseen… vain leikkiä… vain älä, älä kysy, tämä kysymys ansaitsee oman osan, koska se tekee muista tyhmistä kysymyksistä näyttävät hyvältä.

8. Saat paremman kuvan hänen teknisistä taidoistaan ​​tekemällä siitä hauskaa kaikille

Se on oikeastaan ​​aika yksinkertaista, anna hänelle pienen / keskimäärin monimutkainen kotitehtävä ja anna hänen rakentaa tämä ratkaisu. Pyydä häntä seuraamaan likimääräinen kulunut aika, joka meni sinua kiinnostavien toimintojen jokaiseen päälohkoon, ja ehkä kysyä sieltä täällä, kun hän on valmis.

Ihmiset haluavat haastaa, ja saat paljon tietoja joku tekemällä sen sijaan, että painostettaisi häntä tekemään esimerkiksi taulun testiä.

Nyt voit myös nähdä kuinka nopeasti hän ymmärtää 'lisää kehysnimesi'.

9. Älä ota huomioon hänen mielipiteitään itsestään

Huh?

Kysyttäessä (valinnaisesti matalaa itsetuntoa) rockstar-kehittäjältä hänen taitoistaan ​​ja vertaamalla sitä keskitason kehittäjän vastauksiin, et kerro sinulle mitään niistä taitoista, joita etsit, se kertoo sinulle korkeintaan jotain henkilökohtaisista piirteistä.

Mitä enemmän opit, sitä enemmän huomaat, että et tiedä paljon, siksi Impostor-oireyhtymä on todellinen asia, joka jatkuu tällä hetkellä, etenkin JS-maailmassa.

Jos tavoitteesi on saada hyödyllistä teknistä tietoa tällaisista kysymyksistä, sinun pitäisi jo pudottaa ne.

10. Annetaan riittävästi aikaa todistaa itsensä

Teknomaailma on monimutkainen, ja oppimiskäyrät ovat jyrkkiä jopa kirkkaimmallekin. Ainoa paras tapa tietää varmasti, jos joku sopii, on tosiasiallisesti käymällä useita kuukausia työskennellessään kyseisen henkilön kanssa, ts. Jos sinulla on varaa siihen.

Kaikki muut indikaattorit eivät sano paljoa verrattuna tähän, eivät edes kokemusta. Pidä tämä mielessä, koska mikä tahansa suunnitelmasi selvittää kehittäjä kaikista näkökulmista, se todennäköisesti epäonnistuu monille mahdollisesti hyvistä ehdokkaista ja onnistuu ainakin joillekin huonoille.

___________________________________________________________________

Kiitos lukemisesta :).

Yritin tarkoituksella välttää sukupuoleen liittyvien pronominien kirjoittamista, koska se on vuosi 2016 ja haluan välttää epäseksuaalisten ihmisten ja joidenkin merihevoslajien loukkaamista. Rakastan merihevosia.