Kuidas palgata paremaid arendajaid

[Märkus] See on artikkel, mis on kirjutatud rentiva ettevõtte vaatenurgast või töötaja perspektiivist, kes sooviksid toredaid ja kompetentseid kolleege.

Toon välja aspektid, mis puudutavad arendajaid tervikuna, kuid räägin rohkem täisstacki JS-i arendaja kogemusest, nii et mõned asjad ei pruugi teie juhtumi jaoks kindaks sobida.

Nendele asjadele tähelepanu juhtides ei tule küsimus ainult selles, mis enamikul rendiprotsessidel valesti on, vaid ka mõningatest põhinäitajatest, mida vaadata ja mida saaks parendada (teha ja mitte, aga enamasti ei tohi).

  1. Ärge küsige rumalaid küsimusi

Kui kelleltki küsite, mitu ananassi mahub vaala rümba sisse lihtsalt selleks, et näha, kas see sobib teie väljamõeldud „võluväeliste” vastustega, ei aita see kedagi, eriti mitte arendaja aju.

2. Vältige kohapealsete ülesannete survet ja / või aeganõudvate või liiga keeruliste ülesannete seadmist

Kui teie ettevõte pole tõepoolest c ** p, ei pea funktsiooni tõenäoliselt 20 minuti jooksul vabastama ja olen üsna kindel, et sellega ei kaasne tagasitõmbamisi ega binaarpuid ega O (n) optimeerimist hashmapside abil.

Sellistest või muudest küsimustele vastuse saamine sõltub ka devandi vaimsest valmisolekust ja meeleolust sellel konkreetsel ajal ega tähenda teile tegelikult liiga palju.

Tasub seda ikkagi teha, kui testid on tõesti lihtsad ja neid kasutatakse lihtsalt tõeliselt halbade välja filtreerimiseks või kui lihtsalt peate mõtlema mõtlemisprotsessi ja alustama kompromisside arutelu.

3. Paberil kirjutatav kood (eriti keelespetsiifiline kood)

Kui te pole google, on see tavaliselt tüütu AF. See, et suured ettevõtted seda ei tee, ei tähenda, et see hea oleks, tähendab, et nad saavad endale lubada raiskamist, sest inimesi tuleb niikuinii juurde, seega on neil lihtsalt luksus saada väga tugeva teoreetilise baasiga inimesed, isegi kui nad seda kasutavad teadmine või mitte.

Olgem ausad, unustate suurema osa algoritme 2–3 aasta jooksul pärast ülikoolist lahkumist, kui te ei tööta tõesti väga madala tasemega toote kallal.

Aga .. kas hea arendaja peab teadma, kuidas teha 4 tüüpi sorteerimist? Ma kahtlen selles.

Mis tegelikult loeb, on see, kui mõistame seda lihtsalt seda lugedes ja mõeldes välja erinevused ja eripärad igas osas.

Ehk siis lihtsalt tehke seda sorteerimist ise ja lihtsalt küsige, mida see teeb, kutsuge teda üles seda lihtsamate sõnadega selgitama, et koodist hästi aru saada. Samuti, kui oskate märgata vajalikke vaimseid võimeid selle pildi teisendamiseks millegi sarnaseks, mis on vähem tehnilise inimese jaoks mõistlikum, oleks see väga tore.

Sest kui ta teeb seda kõike, siis võite olla kindel, et ta suudab mõne päeva jooksul üle minna kõigist neist väljamõeldud graafikute algoritmidest, mida teile nii väga meeldib, ja õppida kõik uuesti, kui seda tõesti vajate.

4. Lõpetage API küsimuste esitamine tehnoloogia / keele kohta, mis seda ei puuduta. Otsige selle asemel mõisteid

Mida ma mõtlen selle all, on see, et kellegi käest küsimisel, kui suur osa MongoDB-operatsiooni päringkeelest / süntaksist on, ei ole üldse kaalul ... Ma arvan, et inimesed, kes mäletavad täiuslikult API süntaksi südame järgi, on üldiselt halvemad arendajad kui inimesed, kes selle unustavad.

Tõsiselt, kuidas sa muidu õpid midagi uut ja kiiret, kui meelde jätta selliseid asju nagu põhikoolis? Päris maailmas peate serva hoidmiseks õppima veel ühe tehnoloogia tommorowi.

Kus su pulm nüüd on?

Mõistete otsimise all pean silmas seda, et peaksite näiteks mõistma, kas ta mõistab selliseid mõisteid nagu tehingulisus, mastabeeritavus, järjepidevuse tüübid, integreerimise lihtsus ja mootorile saadaolevate API-de kasutuslihtsus, eri tüüpi andmebaasid (dokument, sql , graafik jne) ja ka seda, milleks seda tuleks kasutada, tüüpilised kasutusjuhud ja üldised nõrgad kohad.

SQL API meeldejätmine on veel üks näide, "kuidas sa teed selle LIITUMISE või selle ja selle toimingu". Te ei pea meeles pidama, et kui te saate relatsiooniliste andmebaaside põhiidee, siis peaks hea arendaja oskama teile öelda, millised on erinevad oleku mutatsioonid ja kuidas seda tüüpi andmebaasides toiminguid teha, nendega kaasnevad kompromissid.

Ja seda kõike ainult koos API-de vähetähtsa kasutamisega.

Hea arendaja ei ole arendaja, kes teab, kuidas teie probleemi paberil lahendada, vaid see, kes teab, mida on lubatud toimingud ja abstraktsioonid, mida selle lahendamiseks konkreetse keskkonna jaoks teha saab, ning sellel pole tingimata maatrikskuva peas, koos juhiste või API-dokumentide tükkidega.

Näiteks küsige temalt, millist andmebaasi peaksite kasutama ühe oma süsteemi jaoks, mis täidab teie projektides ilmnenud domeenipõhist ülesannet / probleemi, ja laske tal öelda selle põhjused.

5. Jah, aga kas sa tõesti tead seda raamistikku? Kui palju kogemusi teil sellega on?

Mõnikord on see oluline, mõnikord mitte. Kui küsida, milliseid kogemusi teil Reaketiga on (rääkides tuumreaktist, mitte kogu troonide mängust, raamatukogupaladest), ei küsita põhimõtteliselt midagi, kui olete selle ajani JS-is kodeerinud 2+ aastat.

Reakt ise on 2–3 päeva väärt lugemine, et seda praktiliselt kasutada, kas see on teie ettevõtte jaoks raisatud aeg kriitiline? Noh, kui on, siis võib-olla on see ikkagi jamaettevõte, nii et ärge viitsige seda muuta ... palun jätkake ja minge siis minema (:

Kui see pole nii, siis võiksite küsida arendajalt (nt kui palju aega ta kulutas raamistiku õppimiseks (sisestage oma nimi), saada rohkem teavet mõtlemisprotsessist, arvamustest ja nende järkjärgulistest muutustest (õppimise sammud ja kõverad) , teetõkked jms) ja võrrelge neid andmeid pärast seda, kui keegi teine ​​meeskonnas on.

Waay kasulikum. Küsige temalt, mis talle selles meeldib ja mis mitte, see peaks andma teile kiire ja hea ettekujutuse nende sügavusest, kui te tegelikult olete (mingil põhjusel)

6. Hea arendaja peaks teadma, kuidas asju otsida

Ma arvan, et see on osa, mis teeb vahet värske astme / juuniori ja keskastme või vanema arendaja vahel.

Võimalus leida ise vastuseid, otsida lisateavet, lugeda dokumentatsiooni ja otsida muid seisukohti.

Halvad arendajad üritavad ratast tavaliselt uuesti leiutada, kui see pole nii. Proovige seda joont otsida ja kui see puudub, siis on see kindlasti ei-ei.

7. Kus sa näed ennast X aasta pärast

Kui ta vastab sellele küsimusele ... teeme ainult nalja ... lihtsalt palun ärge, siis väärib see küsimus oma osa, sest see muudab teised rumalad küsimused headeks.

8. Saate oma tehnilistest oskustest parema ülevaate, muutes selle kõigile lõbusaks

See on tegelikult üsna lihtne, andke talle väikese / keskmise keerukusega kodutöö ja laske tal see lahendus üles ehitada. Pange tal jälgida oma ligikaudset aega, mis kulus teile huvipakkuvate funktsioonide igasse suuremasse plokki, ja võib-olla küsige pärast töö tegemist siit ja seal küsimust.

Inimestele meeldib väljakutse esitada ja seal on palju teavet, mida kellegi kohta saate, selle asemel, et suruda teda tegema selliseid asju nagu tahvli test.

Nüüd näete ka, kui kiiresti ta saab aru teie sisestatud raaminimest.

9. Ärge võtke arvesse tema arvamust enda kohta

Ah ?

Kui küsite (valikuliselt madala enesehinnanguga) rockstari arendajalt oma oskuste kohta ja võrrelge seda keskastme arendaja vastustega, siis ei ütle teile midagi nende oskuste kohta, mida otsite, vaid see ütleb teile kõige rohkem midagi isiklike omaduste kohta.

Mida rohkem õpite, seda rohkem saate aru, et te ei tea palju, sellepärast on Impostori sündroom reaalne asi, mis praegu toimub, eriti JS-i maailmas.

Kui teie eesmärk on sellistest küsimustest kasuliku tehnilise teabe hankimine, peaksite need juba loobuma.

10. piisavalt aega enda tõestamiseks

Tehnikamaailm on keeruline ja õppimiskõverad on järsud isegi kõige eredamate jaoks. Ainus parim viis kindlalt teada saamiseks, kas keegi sobib, on tegelikult selle inimesega mitu kuud tööd teha, st kui saate seda endale lubada.

Kõik muud näitajad ei ütle selle näitajaga võrreldes kuigi palju, isegi mitte kogemused. Pidage seda meeles, sest hoolimata sellest, kuidas plaanite arendajat kõigist nurkadest välja mõelda, kukub see tõenäoliselt paljude potentsiaalselt heade kandidaatide jaoks ja õnnestub vähemalt mõne halva jaoks.

___________________________________________________________________

Tänud lugemise eest :).

Püüdsin tahtlikult vältida soospetsiifiliste asesõnade (ta) kirjutamist, kuna see on aasta 2016 ja ma tahan vältida seksuaalsete inimeste ja mõnede mereloomade liikide solvamist. Ma armastan merihobuseid.