Kuidas taltsutada juniorit?

Kuidas jõuda suurde ettevõttesse, kui oled algaja? Kuidas palgata vääriline algaja, kui oled suur ettevõte? Allpool räägin meie kogemusest noorte front-end arendajate palkamisel: kuidas me töötasime välja testülesanded, valmistusime intervjuudeks ja lõime mentorlusprogrammi algajate arendamiseks ja onboardimiseks, ning miks tavalised intervjuuküsimused ei toimi.

Ma üritan taltsutada algajat.

Tere! Minu nimi on Pavel, ma teen front-endi tiimis Wrike. Loome projektihalduse ja koostöö süsteemi. Olen veebiga tegelenud alates 2010. aastast, töötasin 3 aastat rahvusvahelises kaug-töös, osalesin mitmes idufirmas ja õpetasin ülikoolis veebitehnoloogiate kursust. Ettevõttes osalen arengutehniliste kursuste ja Wrike'i mentorlusprogrammi väljatöötamises algajatele, samuti nende värbamises.

Miks me üldse mõtlema hakkasime algajate palkamisele.

Kuni hiljutise ajani palkasime front-end arendajaid, kelle oskused olid keskmised või kõrged — piisavalt iseseisev, et pärast onboardimist tegeleda tootearendusega. Selle aasta alguses mõistsime, et soovime seda poliitikat muuta: poole aasta jooksul on meie tootearendustiimide arv peaaegu kahekordistunud, front-end arendajate arv on lähenenud sajale ja lähitulevikus peaks see kahekordistuma veel kord. Tööd on palju, vabade käte arv on väike ja turul on neid veel vähem, seega otsustasime pöörduda nende poole, kes on alles oma front-end teekonna alguses, ja mõistsime, et oleme valmis investeerima nende arengusse.

Kes on algaja?

See on kõige esimene küsimus, mida me endalt küsisime. Kriteeriume on erinevaid, kuid kõige lihtsam ja arusaadav põhimõte on järgmine:

Algajale tuleb selgitada, millist funktsiooni ja kuidas teha. Keskmisele arendajale tuleb selgitada, milline funktsioon on vajalik, ja ta vaatab ise, kuidas rakendada. Kogenud arendaja aga selgitab sulle ise, miks seda funktsiooni üldse teha ei ole vaja.

Nii või teisiti, algaja on arendaja, kes vajab nõu, kuidas konkreetsed lahendused ellu viia. Mida me otsustasime põhjalda:

1. Algaja on see, kes soovib areneda ja on valmis selle nimel palju tööle;
2. Ta ei tea alati, millises suunas soovib areneda;
3. Ta vajab nõu ja otsib abi väljastpoolt — oma liidilt, mentorilt või kogukonnalt.

Meil oli ka mitu hüpoteesi:

1. Junior positsioonile tuleb taotluste torm.Tuleb filtreerida juhuslikud taotlused juba CV saatmise etapis;
2. Esialgne filter ei aita — vajalikud on veel testülesanded;
3. Testülesanded hirmutavad kõiki eemale — need ei ole vajalikud.

Ja muidugi oli meil eesmärk: 4 juniorit 3 nädalaga.

Selle arusaamisega hakkasime eksperimenteerima. Plaan oli lihtne: alustada maksimaalselt laia toruga ja proovida seda järk-järgult kitsendada, et jõuda voolu töötlemisega, kuid mitte viia seda 1 kandidaadini nädalas.

Avaldame töökuulutuse

Ettevõtte jaoks: Tuleb sadu taotlusi! Mõelge filtrile.

Juniorile: Ärge kartke küsimustikku CV saatmise enne ja testülesannet — see on märk sellest, et ettevõte hoolib teist ja on protsessi hästi seadnud.

Esimese päeva jooksul saime umbes 70 CV-d kandidaatidelt 'JavaScripti teadmistega'. Ja siis veel. Ja veel. Me ei saanud füüsiliselt kõiki intervjuule kutsuda ja valisime neist inimesed, kellel olid kõige ägedamad pet-projektid, aktiivne GitHub või vähemalt kogemus.

Aga peamine järeldus, mille me esimesel päeval tegime, — torm on alanud. Aeg on lisada küsimustiku vorm CV saatmise enne. Selle eesmärk oli eraldada kandidaate, kes ei ole valmis minimaalset pingutust tegema CV saatmiseks, ja neid, kes ei valda teadmisi ja konteksti vähemalt niipalju, et õiged vastused Googeldada.

Küsimustes olid standardküsimused JS, veebidisaini, veebitehnoloogia ja arvutiteaduse kohta — neid teab igaüks, kes teab, mida küsitakse frontend-infosse. Mis vahe on let/var/const? Kuidas rakendada stiile ainult ekraanidele, mille laius on väiksem kui 600px? Me ei tahtnud neid küsimusi tehnilisel intervjuul küsida — praktika on näidanud, et neile saab vastata pärast 2-3 intervjuud, mitte teades programmeerimisest. Kuid need suudavad esialgu näidata, kas kandidaat mõistab üldiselt konteksti.

Igas kategoorias olime ette valmistanud 3-5 küsimust ja päevast päeva muutsime nende komplekti vastamise vormis, kuni olime välja jätnud kõige lihtsamad ja kõige keerulisemad. See võimaldas voolu vähendada — 3 nädalaga saime 122 kandidaati, kellega edasi töötada. Need olid IT-üliõpilased; noored mehed, kes soovisid liikuda tagasiotsimisest esiplaanile; töötajad või insenerid vanuses 25-35 aastat, kes soovisid kardinaalselt muuta oma ametit ja pingutasid erineval määral enesetäiendamise, kursuste ja praktikate nimel.

Tutvume lähemalt

Ettevõtte jaoks: Testülesanne ei peleta kandidaate, vaid aitab lühendada värbamisprotsessi.

Juniorile: Ärge kopeerige testülesandeid — see on silmatorkav. Ja hoidke oma GitHub korras!

Kui me oleksime kõik tehnilisele vestlusele kutsunud, oleksime pidanud tegema umbes 40 vestlust nädalas ainult noorte ja ainult esiplaanil. Seetõttu otsustasime kontrollida teist hüpoteesi — testülesande osas.

Mis oli meie jaoks testülesandes oluline:

1. Hea skaleeritava arhitektuuri loomine, kuid ilma üleinsenerimise;
2. Parem on teha kauem, aga teha hästi, kui ühel ööl uhkeldada midagi ja saata koos kommentaariga „kindlasti viin lõpuni“;
3. Arenduse ajalugu Gitis — insenerikultuur, arenduse iteratiivsus ja et lahendus ei oleks täielikult kopeeritud.

Oleme kokku leppinud, et tahame vaadata ühte algoritmilist ülesannet ja väikest veebirakendust. Algoritmilised ülesanded olid ette valmistatud esikursuse laboratoorsete tööde tasemel — binaarne otsing, sortimine, anagrammide kontrollimine, töö loenditega ja puude struktuuridega. Lõpuks valisime binaarse otsingu esimese katsevariandina. Veebirakendus pidid olema noughts and crosses (ristid nullid) kasutades mistahes raamistikke (või ilma).

Peaaegu pooled allesjäänud noormehed läbisid testülesande — me saime lahendused 54 kandidaati.Uskumatu teadmine — kui palju ristikrõõde, mis on valmis kopeerimiseks, on internetis?

Kui palju?Tegelikkuses tundub, et ainult 3. Suuremiku lahendustes olid just need 3 varianti.
Mida me ei meeldi:

• kopeerimine või arendamine sama õpetuse järgi ilma oma arhitektuurita;
• kaks ülesannet ühes hoidlas erinevates kaustades, kommitide ajalugu ei ole muidugi olemas;
• räpane kood, DRY rikkumine, formaadist puudumine;
• mudeli, vaate ja kontrollija segamine ühte klasse, mille pikkus on sadade koodiridade ulatuses;
• üksuse testimise puudumine;
• lahendus "otse" - kõvakood 3x3 võidukombinatsioonide maatriksist, mis on üsna keeruline laiendada näiteks 10x10-le.

Me pöörasime tähelepanu ka naabreportsioonidele - ägedad pet-projektid tulid kasumisse, kuid hulk testülesandeid teistelt ettevõtetelt oli pigem märk, miks kandidaat seal edasi ei pääsenud.

Lõpuks leidsime ägedaid variante Reacti, Angulari ja Vanilla JS-i põhjal - neid kogunes kokku 29. Ja veel ühe kandidaadi otsustasime kutsuda ilma testita, kuna tal olid väga head pet-projektid. Meie hüpotees testülesannete kasulikkuse kohta sai kinnitust.

Tehniline intervjuu

Ettevõtte jaoks: Teie juurde tulid mitte keskastme/seniorid! Vajame rohkem individuaalset lähenemist.

Juniorile: Pidage meeles, et see pole eksam - ärge proovige vaikida, et saavutada lihtsalt kolm või petta professorit kõigi oma teadmistest, et ta segadusse satuks ja "suurepäraselt" hindaks.

Mida me tahame teada tehnilises intervjuus? Lihtsat asja - kuidas kandidaat mõtleb. Tõenäoliselt on tal mingid kõval oskused, kui ta on läbinud esimesed valikute etapid - jääb selgitada, kas ta oskab neid rakendada. Otsustasime kolme ülesande kasuks.

Esimene - algoritmid ja andmestruktuurid. Paberil, paberile ja pseudokoodiga ning joonistamise abil arutasime, kuidas kopeerida puu või kuidas eemaldada element ühesuunalisest loendist. Ebameeldiv avastus oli, et mitte kõik ei mõista rekurssiooni ja kuidas viidatud lingid töötavad.

Teine - reaalajas koodimine. Me külastasime codewars.com, valisime lihtsad asjad, nagu sõnade massiivi sortimine viimase tähe järgi ja püüdsime 30-40 minuti jooksul koos kandidaadiga kõik testid läbima. Tundus, et ristsõnu teinud inimesed ei peaks üllatama - kuid praktikas ei suutnud kõik aru saada, et väärtust tuleb salvestada muutujasse ja funktsioon peab midagi tagastama läbi return. Kuigi ma loodan, et see oli pingutus ja poisid suudavad nende ülesannetega kergemates oludes toime tulla.

Lõpuks, kolmas - natuke arhitektuurist. Arutasime, kuidas teha otsinguriba, kuidas sellega töötab debounc'e, kuidas erinevaid vidinaid renderdada otsinguettepanekutes, kuidas frontend saab backendiga suhelda. Leidsime palju huvitavaid lahendusi, sealhulgas serveripoolset renderdamist ja veebipõhiseid sokette.

Me oleme läbi viinud 21 intervjuud sellise kavaga. Publik oli täiesti mitmekesine — vaatame koomikseid:

1. «Raketa». Ta ei rahune kunagi maha, tungib igale poole ja intervjuul pommitab teid mõtete vooluga, mis ei ole otseselt seotud esitatud küsimusega. Kui see toimuks ülikoolis, oleks see tuttav paljudele katse demonstreerida kõiki oma teadmisi, kui poppi pileti kohta mäletad vaid seda, et otsustasid eelmisel õhtul mitte õppida — ikkagi ei tõmba sa.
2. «Groot». Temaga on raske kontakti saada, sest ta on Groot. Intervjuul peab teda kaua käivitama, vastuseid välja ärkama sõna haaval. Hästi, kui see on lihtsalt seisak — muidu on teil igapäevasel tööl hiljem väga raske.
3. «Drax». Varem tegeles ta kaubaveoga, kuid programmi õppis ta ainult JS-i Stackoverflow's, seega ei saa ta alati aru, millest üldse räägitakse intervjuul. Samas on ta hea inimene, tal on parimad kavatsused ja ta tahab saada suurepäraseks front-end arendajaks.
4. Ja kindlasti, «Star-Lord». Üldiselt on ta normaalne kandidaat, kellega saab kokku leppida ja dialooge luua.

Meie uurimiste lõpuks 7 kandidaati sattusid finaali, kinnitades oma hard skillid suurepärase testülesande ja headega vastustega intervjuul.

Kultuuriline sobivus

Ettevõtte jaoks: Kas see inimene on valmis teiega töötama! Kas kandidaat on tõeliselt valmis oma arengu nimel äärmiselt palju tööd tegema? Kas ta sobib meeskonda?

Juniorile: Kas need inimesed on valmis teiega töötama! Kas ettevõte on tõeliselt valmis investeerima noorte arengusse, või lükkab kogu musta töö teie peale madala palga eest?

Iga noor, peale tootemeeskonna, kelle juht peab nõustuma, et ta võtaks, satub mentori käe alla. Mendi ülesanne on viia ta läbi kolme kuu onboordimise ja hard skillide arendamise protsessi. Seetõttu käisime igas kultuurilises sobivuses mentorsidena ja küsisime endalt: «Kas ma võtan vastutuse arendada kandidaati kolme kuu jooksul meie plaani järgi?»

See etapp kulges tavapäraselt ja lõpuks tõi meile 4 pakkumist, millest 3 võeti vastu, ja poisid liitusid meeskondadega.

Elu pärast pakkumist

Ettevõtte jaoks: Hoolitsege oma noorte eest, või teevad seda teised!

Juniorile: AAAAAAA!!!

Kui uus töötaja tuleb, tuleb ta sisse viia – tutvustada talle protsesse, rääkida, kuidas kõik ettevõttes ja meeskonnas toimib ning kuidas üldse tööd teha. Kui tuleb junior, tuleb aru saada, kuidas teda arendada.

Kui me sellele mõtlema hakkasime, koostasime loendi 26 oskusest, millega meie arvates peaks junior olema varustatud kolme kuu jooksul onboardingu lõpuks. Nende hulka kuulusid hard-skills (meie tehnoloogiate kohaselt), teadmised meie protsessidest, scrummist, infrastruktuurist ja projekti arhitektuurist. Koondasime need ajakava järgi kolmeks kuuks rooadmaappi.

Näiteks, siin on minu juniori rooadmaap.

Iga junioriga liidame mentori, kes töötab temaga individuaalselt. Olenevalt mentorist ja kandidaadi praegusest tasemest võivad kohtumised toimuda 1 kuni 5 korda nädalas tunni kaupa. Mentoriteks saavad vabatahtlikult algatusvõimelised frontend-arendajad, kes soovivad teha midagi rohkemat kui lihtsalt koodi kirjutada.

Osa koormusest mentorite pealt võetakse meie tehnoloogiate kursuste kaudu – Dart, Angular. Kursused toimuvad regulaarselt väikestes rühmades, kus on 4-6 inimest, kus noored saavad töötada teadmiste omandamise ajal.

Kolme kuu jooksul kogume perioodiliselt tagasisidet junioridelt, nende mentoritelt ja juhtidelt ning kohandame protsessi individuaalselt. Kogu perioodi jooksul toimub 1-2 korda oskuste testimine, samasugune testimine toimub lõpus – nende põhjal koostatakse soovitused, mida tasub jätkuvalt arendada.

Kokkuvõte

Ettevõtte jaoks: Kas peaks investeerima junioridesse? Jah!

Juniorile: Otsige ettevõtteid, kes valivad kandidaate hoolikalt ja teavad, kuidas neid arendada.

Kolme kuu jooksul oleme läbi vaadanud 122 küsitlust, 54 testülesannet ja viinud läbi 21 tehnilist intervjuud. See tõi meile 3 toredat juniorit, kes on nüüdseks läbinud poole oma onboardingu ja aktseleratsiooni rooadmaapidest. Nad lahendavad juba reaalseid tootearenduse ülesandeid meie projektis, kus ainult frontendis on rohkem kui 2 000 000 koodire146 ja üle 400 hoidla.

Leidsime, et junioride värbamisprotsess võib ja peaks olema piisavalt keeruline, kuid lõpuks läbivad selle ainult need noored, kes on tõeliselt valmis palju tööd tegema ja investeerima oma arengusse.

Nüüd on meie peamine ülesanne lõpule viia iga noore arendaja kolme kuu arenguplaanid individuaalses koostöös mentoriga ja ühiste kursuste raames, koguda mõõdikud, tagasiside juhtidelt, mentoritelt ja noortelt endilt. Selle eksperimendi saab lugeda lõpetatuks, teha järeldusi, parandada protsessi ja alustada seda uuesti uute kandidaatide väljaselgitamiseks.

Allikas: habr.com