Kā pieradināt junioru?

Kā iekļūt lielā uzņēmumā, ja esi juniors? Kā pieņemt darbā cienīgu junioru, ja tu esi liels uzņēmums? Zemāk pastāstīšu mūsu pieredzi, pieņemot darbā jaunus cilvēkus frontend jomā: kā mēs izstrādājām testēšanas uzdevumus, gatavojāmies intervijām un veidojām mentorēšanas programmu, lai attīstītu un ieviestu jaunpienācējus, kā arī kāpēc standartizētie interviju jautājumi nedarbojas.

Es mēģinu pieradināt junioru

Sveiki! Mani sauc Pāvels, es strādāju frontend komandā uzņēmumā Wrike. Mēs izstrādājam sistēmu projektu vadībai un sadarbībai. Es nodarbojos ar tīmekli kopš 2010. gada, trīs gadus strādāju attālināti ārpus valsts, piedalījos vairākos jaunuzņēmumos un pasniedzu kursu par tīmekļa tehnoloģijām universitātē. Uzņēmumā es piedalos tehnisko kursu un Wrike mentorēšanas programmas attīstībā junioriem, kā arī to pieņemšanā darbā.

Kāpēc mēs vispār sāka domāt par junioru pieņemšanu darbā

Līdz nesenam laikam mēs pieņēmām darbā frontend izstrādātājus ar middle vai senior līmeni — pietiekami patstāvīgus, lai pēc iepazīšanās varētu veikt produktu uzdevumus. Šī gada sākumā sapratām, ka vēlamies mainīt šo politiku: gada laikā mūsu produktu komandu skaits palielinājās gandrīz divas reizes, frontend attīstītāju skaits tuvojas simtam, un tuvākajā nākotnē tas visam vajadzētu vēlreiz dubultoties. Darba ir daudz, brīvo roku maz, bet tirgū ir vēl mazāk, tāpēc nolēmām pievērsties jaunajiem, kas tikai sāk savu ceļu frontend jomā, un sapratām, ka esam gatavi investēt viņu attīstībā.

Kas ir juniors?

Tas ir pirmais jautājums, ko uzdevām sev. Ir dažādi kritēriji, bet pats vienkāršākais un saprotamākais princips ir šāds:

Juniors ir nepieciešams paskaidrot, kāda funkcija un kādā veidā jāizstrādā. Middels ir jāizskaidro, kāda funkcija nepieciešama, un viņš pats noskaidros, kā to ieviest. Senioram pašam būs jāizskaidro, kāpēc šo funkciju nevajadzētu veikt vispār.

Tā vai citādi, juniors ir tas izstrādātājs, kuram nepieciešama vadlīnija, kā īstenot attiecīgo risinājumu. No kā mēs nolēmām balstīties:

1. Juniors ir tas, kurš vēlas attīstīties un ir gatavs daudz strādāt;
2. Viņš ne vienmēr zina, kādā tieši virzienā vēlas attīstīties;
3. Viņam vajadzīga palīdzība un viņš meklē atbalstu no ārpuses — no sava līdera, mentora vai kopienas.

Mums bija vēl dažas hipotēzes:

1. Uz juniora pozīciju būs straume ar pieteikumiem. Ir nepieciešams filtrēt nejaušos pieteikumus jau pie atsūtītajiem CV;
2. Primārais filtrs nepalīdzēs — nepieciešami vēl testi;
3. Testi visus baidīs — tie nav nepieciešami.

Nu, protams, mums bija mērķis: 4 juniorus 3 nedēļu laikā.

Ar šo apziņu mēs sākām eksperimentēt. Plāns bija vienkāršs: sākt ar pēc iespējas plašāku krātu un pakāpeniski to sašaurināt, lai varētu apstrādāt plūsmu, bet neradīt situāciju, ka paliek tikai 1 kandidāts nedēļā.

Izvietojam sludinājumu

Uz uzņēmumu: Būs simtiem pieteikumu! Apsveriet filtru.

Uz junioru: Nebaidieties no anketas pirms CV nosūtīšanas un testa — tas ir zīme, ka uzņēmums rūpējas par jums un labi organizējis procesu.

Jau pirmajā dienā mēs saņēmām apmēram 70 CV no kandidātiem "ar JavaScript zināšanām". Un tad vēl. Un vēl. Mēs fiziski nevarējām visus uzaicināt uz interviju un izvēlējāmies tos, kuriem bija visinteresantākie pet-projekti, aktīvs GitHub vai vismaz pieredze.

Bet galvenais secinājums, ko mēs izdarījām pirmajā dienā — vētra sākās. Ir pienācis laiks pievienot anketas formu pirms CV nosūtīšanas. Tās uzdevums bija izslēgt kandidātus, kuri nav gatavi veikt minimālas pūles, lai nosūtītu CV, un tos, kuri neorientējas vismaz tik daudz, lai varētu sameklēt pareizās atbildes.

Tajā bija standarta jautājumi par JS, izstrādi, tīmekli, datorzinātnēm — tos zina katrs, kurš saprot, ko jautā intervijā uz frontend. Kāda ir atšķirība starp let/var/const? Kā piemērot stilus tikai ekrāniem, kas ir mazāki par 600px platumā? Mēs nevēlējāmies uzdot šos jautājumus tehniskajā intervijā — prakse parādīja, ka uz tiem var atbildēt pēc 2-3 intervijām, pilnīgi neraksturojot izstrādi. Bet tie varēja sākotnēji parādīt, vai kandidāts vispār izprot kontekstu.

Katram jautājumam mēs sagatavojām 3-5 jautājumus un katru dienu mainījām to komplektu atbildē, kamēr izslēdzām visus vieglos un visgrūtākos. Tas ļāva samazināt plūsmu — 3 nedēļu laikā mēs saņēmām 122 kandidātus, ar kuriem turpināt strādāt. Tie bija IT studenti; puikas, kuri vēlējās pāriet no aizmugures uz priekšpusi; darbinieki vai inženieri vecumā no 25 līdz 35 gadiem, kuri radikāli vēlējās mainīt savu nodarbošanos un pielika dažādas pūles pie pašizglītības, kursiem un praksēm.

Iepazīsimies tuvāk

Uz uzņēmumu: Testa uzdevums neaizbaida kandidātus, bet palīdz saīsināt personāla atlases procesu.

Uz junioru: Nepārrakstiet testus — tas ir redzams. Un sakārtojiet savu GitHub!

Ja mēs aicinātu visus uz tehnisko interviju, mums būtu jārīko apmēram 40 intervijas nedēļā tikai junioriem un tikai frontendā. Tāpēc mēs izlemām pārbaudīt otro hipotēzi — par testu uzdevumiem.

Kas bija svarīgi mūsu testā:

1. Izveidot labu, mērogojamu arhitektūru, bet bez pārlieku sarežģītas pieejas;
2. Labāk darīt ilgāk, bet izdarīt labi, nekā nakti saskaldīt celtniecības priekšmetu un nosūtīt ar komentāru «noteikti pabeigšu»;
3. Izstrādes vēsture Gitā — inženieru kultūra, izstrādes iterativitāte un tas, ka risinājums nav vienkārši nokopēts.

Mēs vienojāmies, ka vēlamies apskatīt vienu algoritmisko uzdevumu un nelielu tīmekļa lietojumprogrammu. Algoritmiskie uzdevumi bija sagatavoti sākotnējo kursu līmenī — binārais meklējums, šķirošana, anagrammu pārbaude, darbs ar sarakstiem un kokiem. Galu galā mēs apstājāmies pie binārā meklējuma kā pirmā izmēģinājuma varianta. Tīmekļa lietojumprogrammai vajadzēja būt krustojumiem ar nullēm, izmantojot jebkuru ietvaru (vai bez tā).

Testa uzdevumu izpildīja gandrīz puse no palikušajiem dalībniekiem — mums nosūtīja risinājumus 54 kandidāti. Neticams ieskats — ko domājat, cik realizāciju krustojumiem ar nullēm, kas gatavi kopēšanai, ir pieejami internetā?

Cik?Patiesībā izrādās, ka tikai 3. Un lielākajā daļā risinājumu bija tieši šie 3 varianti.
Kas nepatika:

• kopēšana vai izstrāde pēc viena un tā paša pamācības bez savas arhitektūras;
• abas uzdevumu izpildes vienā repozitorijā dažādās mapēs ar, protams, neesošu izmaiņu vēsturi;
• netīrs kods, DRY pārkāpumi, formatēšanas trūkums;
• modeļa, skata un kontroliera sajaukšana vienā klasē ar simtiem rindiņu koda;
• sapratnes trūkums par vienību testēšanu;
• risinājums «neaugt» — grūti maināms 3x3 uzvarējošo kombināciju matricas hardkods, ko būs grūti paplašināt līdz 10x10, piemēram.

Vēl mēs pievērsām uzmanību blakus esošajiem repozitorijiem — lieliski petprojekti devās uz augšu, bet kaudze testēšanas uzdevumu no citām kompānijām drīzāk bija signāls: kāpēc kandidāts tur neizturēja?

Beigās mēs atradām lieliskus variantus uz React, Angular, Vanilla JS — tādu bija 29. Un vēl vienu kandidātu mēs nolēmām uzaicināt bez testiem, jo viņam bija ļoti forši petprojekti. Mūsu hipotēze par testēšanas uzdevumu izmantošanu apstiprinājās.

Tehniskais intervijs

Uz uzņēmumu: Pie jums nav atnākuši vidējie/seniori! Nepieciešama individuālā pieeja.

Uz junioru: Atcerieties, ka tā nav eksāmens — nepērciet uz trijnieku vai nesabojājiet profesoru ar visiem saviem iespējamajiem zināšanām, lai viņš apjukt un ieliktu «izcili».

Ko mēs vēlamies saprast tehniskajā intervijā? Vienu vienkāršu lietu — kā kandidāts domā. Pārdomājam, viņam noteikti ir kādas cietās prasmes, ja viņš izturēja pirmos atlases etapus — atliek tikai noskaidrot, vai viņš spēj tās piemērot. Mēs nonācām pie trim uzdevumiem.

Pirmais — par algoritmiem un datu struktūrām. Ar zīmuli, uz lapas, uz pseido valodas un ar zīmējumiem mēs skaidrojām, kā kopēt koku vai kā dzēst elementu no vienvirziena saraksta. Nepatīkams atklājums bija tas, ka ne visi saprot rekursiju un to, kā darbojas norādījumi.

Otrā — tiešs kodēšana. Mēs devāmies uz codewars.com, izvēlējāmies ne pārāk sarežģītas lietas, piemēram, vārdu masīvu šķirošanu pēc pēdējās burta, un 30-40 minūšu laikā kopā ar kandidātu mēģinājām izpildīt visus testus. Izskatījās, ka nenotiks nekādas pārsteigumi no cilvēkiem, kas apguvuši krustvārdu spēles — bet praksē ne visi spēja saprast, ka vērtība jāuztur mainīgajā, un funkcijai kaut kas jādod atpakaļ ar return. Lai gan es sirsnīgi ceru, ka tas bija satraukums, un cilvēki spēja tikt galā ar šiem uzdevumiem vieglākā vidē.

Visbeidzot, trešais — nedaudz par arhitektūru. Apspriedām, kā var izveidot meklēšanas joslu, kā darbojas debounce, kā attēlot dažādus logrīkus meklēšanas piedāvājumos, kā frontend var mijiedarboties ar backend. Atradās daudz interesantu risinājumu, tostarp par servera puses attēlošanu un tīmekļa soketiem.

Mēs veicām 21 interviju pēc šādas shēmas. Publika bija pilnīgi dažāda — ņemsim komiksus:

1. «Raketa». Nikad neapstājas, visur iesaistās, bet intervijā jūs apdāvinās ar domu plūdiem, tieši pat ne saistītiem ar uzdoto jautājumu. Ja tas būtu universitātē, tas būtu pazīstams daudziem mēģinājums demonstrēt visus savus zināšanas, kad par izlozēto biļeti atceraties tikai to, ka vakar vakarā izlēmāt to nemācīties — tomēr neizdosies to izvilkt.
2. «Gruut». Ar viņu pietiekami grūti kontaktēties, jo viņš ir Gruut. Intervijā jāatceras ilgi iesildīties, izvilkt atbildes vārds pa vārdam. Labi, ja tas ir tikai stumbrs — citādi vēlāk ikdienas darbā jums būs ļoti grūti.
3. «Draxis». Agrāk nodarbojās ar kravu pārvadājumiem, bet no programmēšanas mācījās tikai JS no Stackoverflow, tāpēc ne vienmēr saprot, par ko tieši runa intervijā. Tomēr ir labs cilvēks, ar labām nodomiem un vēlas kļūt par lielisku front-end izstrādātāju.
4. Un, iespējams, «Zvaigžņu kungs». Kopumā, labs kandidāts, ar kuru var vienoties un veidot dialogu.

Beidzot mūsu pētījumi 7 kandidāti nokļuva finālā, apstiprinot savas hard skills ar lielisku testu uzdevumu un labām atbildēm intervijā.

Kulturālā atbilstība

Uz uzņēmumu: Jums ar viņu strādāt! Vai kandidāts tiešām ir gatavs strādāt ārkārtīgi daudz sava attīstības labad? Vai viņš tiešām iederēsies komandā?

Uz junioru: Jums ar viņiem strādāt! Vai uzņēmums tiešām ir gatavs ieguldīt junioru izaugsmē, vai vienkārši novirzīs uz jums visu netīro darbu par zemu algu?

Katrs juniors, papildus produktu komandai, kuras līderim jāpiekrīt viņu uzņemt, nokļūst pie mentora. Mentora uzdevums ir vesti viņu caur trīs mēnešu onboardinga un hard skills attīstības procesu. Tāpēc uz katru kulturālo atbilstību mēs ieradāmies kā mentori un uzdevām sev jautājumu: «Vai es uzņemšos atbildību attīstīt kandidātu 3 mēnešu laikā pēc mūsu plāna?»

Šis posms notika bez īpašībām un galu galā mums deva 4 piedāvājumus, no kuriem 3 tika pieņemti, un puisi piedalījās komandās.

Dzīve pēc piedāvājuma

Uz uzņēmumu: Rūpējieties par saviem juniors vai to izdarīs citi!

Uz junioru: AAAAAAAAAAAAAA!!!

Kad jaunais darbinieks ienāk, viņu ir jāievada procesā – jāiepazīstina ar uzņēmuma un komandas darbību, jāpastāsta, kā vispār strādāt. Kad pievienojas juniors, ir nepieciešams saprast, kā viņu attīstīt.

Kad par to aizdomājāmies, izveidojām sarakstu ar 26 prasmēm, kurām, pēc mūsu domām, junioram vajadzētu būt līdz trīs mēnešu onboardinga beigām. Tajā iekļāvām hard skills (saskaņā ar mūsu steku), zināšanas par mūsu procesiem, scrumu, infrastruktūru un projekta arhitektūru. Mēs tās apvienojām ceļa kartē, kas sadalīta laikā uz 3 mēnešiem.

Piemēram, šī ir mana juniora ceļa karte.

Katram junioram piešķiram mentoru, kurš strādā ar viņu individuālā režīmā. Atkarībā no mentora un kandidāta pašreizējā līmeņa tikšanās var notikt no 1 līdz 5 reizēm nedēļā pa 1 stundai. Par mentoriem brīvprātīgi kļūst iniciatīvi front-end izstrādātāji, kuri vēlas darīt ko vairāk nekā tikai rakstīt kodu.

Daļu slodzē no mentoriem uzņem mūsu steka kursi — Dart, Angular. Kursi tiek organizēti regulāri mazām grupām no 4-6 cilvēkiem, kur dalībnieki nodarbojas bez darba pārtraukuma.

Trīs mēnešu laikā periodiski vācam atsauksmes no junioriem, viņu mentoriem un līderiem, un individuāli koriģējam procesu. 1-2 reizes visā periodā tiek veikta prasmju pārbaude, tāda pati pārbaude tiek veikta beigās — uz tās pamata tiek izstrādātas rekomendācijas, kādas prasmes būtu jāuzlabo.

Secinājums

Uz uzņēmumu: Vai ir vērts investēt juniors? Jā!

Uz junioru: Meklējiet uzņēmumus, kas rūpīgi izvēlas kandidātus un zina, kā viņus attīstīt.

Trīs mēnešu laikā mēs apskatījām 122 aptaujas, 54 testu uzdevumus un veicām 21 tehnisko interviju. Tas deva mums 3 lieliskus juniorus, kuri tagad ir pārvarējuši pusi no savām onboardinga un akselerācijas ceļa kartēm. Viņi jau risina reālas produktu problēmas mūsu projektā, kurā tikai front-end ir vairāk nekā 2 000 000 koda rindu un vairāk nekā 400 repozitoriju.

Mēs noskaidrojām, ka junioru atlases process var un tam jābūt pietiekami sarežģītam, bet, galu galā, caur to iziet tikai tie, kuri patiešām ir gatavi daudz strādāt un investēt savā attīstībā.

Šobrīd mūsu galvenais uzdevums ir pabeigt trīs mēnešu attīstības ceļvežus katram jaunajam speciālistam individuālā darba režīmā ar mentoru un kopējo kursu palīdzību, vākšot metriku, atsauksmes no vadītājiem, mentoriem un pašiem jaunajiem speciālistiem. Šajā posmā pirmo eksperimentu var uzskatīt par pabeigtu, izdarīt secinājumus, uzlabot procesu un vēlreiz to īstenot jauno kandidātu atlasei.

Avots: habr.com