Kako ukrotiti juniora?

Kako doći do velike kompanije ako si junior? Kako zaposliti kvalitetnog juniora ako si velika kompanija? Ispod ću ispričati našu priču o zapošljavanju početnika za frontend: kako smo radili na testnim zadacima, pripremali se za vođenje intervjua i uspostavljali mentorskih program za razvoj i on-boarding novih zaposlenih, kao i zašto standardna pitanja za intervjue ne funkcionišu.

Ja pokušavam ukrotiti juniora

Zdravo! Zovem se Pavel, radim frontend u timu Wrike. Stvaramo sistem za upravljanje projektima i saradnju. Bavim se web-om od 2010. godine, 3 godine sam radio na stranim udaljenim poslovima, učestvovao u nekoliko start-upova i predavao kurs o web-tehnologijama na univerzitetu. U kompaniji učestvujem u razvoju tehničkih kurseva i mentorskog programa Wrike za juniore, kao i u njihovom direktnom zapošljavanju.

Zašto smo se uopšte odlučili za zapošljavanje juniora

Do nedavno smo zapošljavali frontend programere srednjeg ili višeg nivoa — dovoljno samostalnih da nakon on-boardinga obavljaju produkcijske zadatke. Početkom ove godine shvatili smo da želimo promijeniti ovu politiku: u poslednjih godinu dana broj naših produkcijskih timova se skoro udvostručio, broj frontend desarrollera se približio stotki, a u bliskoj budućnosti sve to bi trebalo opet udvostrčiti. Posla ima mnogo, slobodnih ruku malo, a na tržištu ih je još manje, pa smo odlučili da se okrenemo mladim ljudima koji tek započinju svoj put u frontendu i shvatili smo da smo spremni uložiti u njihov razvoj.

Ko je junior?

To je prvo pitanje koje smo postavili. Postoje različiti kriterijumi, ali najjednostavnije i najjasnije pravilo je sledeće:

Junioru je potrebno objasniti koju funkcionalnost i kako treba implementirati. Midlu treba objasniti koja funkcionalnost je potrebna, a on će se sam snaći sa realizacijom. Senior će ti sam objasniti zašto tu funkcionalnost ne treba praviti uopšte.

U svakom slučaju, junior je onaj programer kojem je potreban savet o tome kako tačno implementirati određeno rešenje. Od čega smo odlučili da krenemo:

1. Junior je onaj ko želi da se razvija i spreman je da puno radi za to;
2. On ne zna u koju tačno stranu želi da se razvija;
3. Potreban mu je savet i traži pomoć spolja — od svog vodje, mentora ili iz zajednice.

Imeli smo še nekaj hipotez:

1. Na mesto junaka bo prišlo obilo prijav.Naključne prijave je treba filtrirati že v fazi pošiljanja življenjepisov;
2. Prvi filtr ne bo pomagal. — potrebna so še testna opravila;
3. Testna opravila bodo vse odvrnila. — niso potrebna.

In seveda, naš cilj je bil: 4 junake v 3 tednih..

S tem spoznanjem smo začeli eksperimente. Načrt je bil preprost: začeti z čim širšo odprtino in poskušati jo postopoma zožiti, da bomo uspeli obdelati tok, a ne zmanjšati na 1 kandidata na teden.

Objavljamo razpis.

Za podjetje: Pričakujte stotine prijav! Razmislite o filtriranju.

Za junaka: Ne bojte se ankete pred pošiljanjem življenjepisa in testnega opravila — to je znak, da vam podjetje posveča pozornost in da je dobro nastavljeno.

Že prvi dan smo prejeli okoli 70 življenjepisov od kandidatov z 'znanjem JavaScript'. In potem še. In še. Fizično nismo mogli povabiti vseh na razgovore v pisarno in smo izbrali tiste z najboljšimi projekti, aktivnim GitHubom ali vsaj izkušnjami.

A glavna ugotovitev, ki smo jo naredili že prvi dan — vihar se je začel. Prišel je čas, da dodamo vprašalnik pred pošiljanjem življenjepisa. Njegov cilj je bil odfiltrirati kandidate, ki niso pripravljeni vložiti minimalne truda za pošiljanje življenjepisa, ter tiste, ki ne obvladajo znanja in konteksta vsaj do mere, da lahko poiščejo pravilne odgovore.

Vsebuje standardna vprašanja o JS, kodiranju, spletu, računalniških znanostih — to ve vsak, ki se zaveda, kaj se vprašuje na razgovoru za front-end. Kakšna je razlika med let/var/const? Kako uporabiti stile samo za zaslone, manjše od 600px v širino? Nismo želeli postavljati teh vprašanj na tehničnem razgovoru — praksa je pokazala, da lahko na njih odgovorite po 2-3 razgovorih, brez pravega razumevanja razvoja. A so nam omogočila, da smo na začetku ugotovili, ali kandidat sploh razume kontekst.

V vsaki kategoriji smo pripravili 3-5 vprašanj in dan za dnem spreminjali njihov nabor v obrazcu za prijavo, dokler nismo izključili najlažjih in najtežjih. To je omogočilo zmanjšati tok — v 3 tednih smo prejeli 122 kandidatov., s katerimi smo lahko delali naprej. To so bili študenti računalništva; fantje, ki so želeli preiti s backend na frontend; delavci ali inženirji stari od 25 do 35 let, ki so želeli drastično spremeniti poklic in so vložili različno količino truda v samostojno učenje, tečaje in pripravništva.

Spoznajmo se bolje

Za podjetje: Testna naloga ne odvrne kandidatov, temveč pomaga skrajšati vrzel.

Za junaka: Ne kopirajte testnih nalog — to je opazno. In uredite svoj GitHub!

Če bi povabili vse na tehnični intervju, bi morali izvesti približno 40 intervjujev na teden samo za juniorske in samo za frontend. Zato smo se odločili preveriti drugo hipotezo — glede testne naloge.

Kaj je bilo za nas pomembno pri testni nalogi:

1. Zgraditi dobro razširljivo arhitekturo, vendar brez pretirane zapletenosti;
2. Bolje je delati dlje, a dobro, kot pa čez noč narediti izdelek in poslati z komentarjem 'zelo bom dokončal';
3. Zgodovina razvoja v Git-u — inženirska kultura, iterativni razvoj in to, da rešitev ni bila preprosto kopirana.

Dogovorili smo se, da želimo videti eno algoritemsko nalogo in majhno spletno aplikacijo. Algoritemske naloge so bile pripravljene na ravni osnovnih laboratorij, kot so binarno iskanje, razvrščanje, preverjanje anagramov, delo s seznami in drevesi. Na koncu smo se ustavili pri binarnem iskanju kot prvem poskusnem primeru. Spletna aplikacija naj bi bile človekova igra s katerim koli ogrodjem (ali brez njega).

Testno nalogo je uspešno opravila skoraj polovica preostalih fantov — prejeli smo rešitve 54 kandidatov. Neverjeten vpogled — koliko implementacij človekove igre, pripravljenih za kopiranje, mislite, da je na spletu?

Koliko?Dejansko se zdi, da le tri. In v prevladujočih rešitvah so bile ravno te tri različice.
Što mi se nije svidelo:

• kopiranje, ali razvoj po istem vodiču brez lastne arhitekture;
• obe nalogi v enem repozitoriju v različnih mapah, zgodovine commitov seveda ni;
• neurejen kod, kršenje pravila DRY, pomanjkanje oblikovanja;
• mešanica modela, pogledu in kontrolerja v en razred dolžine stotine vrstic;
• pomanjkanje razumevanja enotnih testov;
• rešitev „v živo“ — hardkodiranje matrike zmagovalnih kombinacij 3x3, kar bo precej težko razširiti na 10x10, na primer.

Poleg tega smo spremljali sosednje repozitorije — odlični pet-projekti so bili v pozitivni coni, veliki številni testni projekti od drugih podjetij pa so bili znak: zakaj kandidat tam ni uspel.

Na koncu smo našli odlične možnosti na React, Angular, Vanilla JS — teh je bilo 29. In še enega kandidata smo se odločili povabiti brez testa zaradi njegovih izjemnih pet-projektov. Naša hipoteza o koristnosti testnih nalog je bila potrjena.

Tehnični intervju

Za podjetje: K vam niso prišli srednji/senior kandidati! Potreben je bolj individualen pristop.

Za junaka: Zapomnite si, da to ni izpit — ne poskušajte molčati na trojko ali preplaviti profesorja s tokom vseh vaših možnih znanj, da bi se zmedel in dal „odlično“.

Kaj želimo razumeti na tehničnem intervjuju? Preprosto stvar — kako kandidat razmišlja. Verjetno ima določene trde veščine, če je prestal prve faze selekcije — ostalo je ugotoviti, ali jih zna uporabiti. Strinjali smo se o treh nalogah.

Prva — o algoritmih in podatkovnih strukturah. Z roko, na listu papirja, v psevdokodu in s pomočjo risb smo ugotavljali, kako kopirati drevo ali kako odstraniti element iz enoslinkednega seznama. Neprijetno presenečenje je bilo, da ne vsi razumejo rekurzije in kako delujejo povezave.

Druga — live coding. Obiskali smo codewars.com, izbrali preproste stvari, kot je razvrščanje seznama besed po zadnji črki, in v 30-40 minutah skupaj s kandidatom poskusili opraviti vse teste. Zdelo se je, da ne bi smelo biti presenečenj od fantov, ki so obvladali križce-nuli — a v praksi niso vsi uspeli razumeti, da je treba vrednost shraniti v spremenljivko in da mora funkcija nekaj vrniti preko return. Čeprav iskreno upam, da je šlo za tremo in so se fantje s temi nalogami uspeli spoprijeti v bolj lahkih pogojih.

Nazadnje, tretja — malo o arhitekturi. Pogovarjali smo se, kako lahko naredimo iskalno vrstico, kako deluje debounce, kako renderirati različne vidžete v iskalnih predlogah, kako frontend lahko sodeluje z backendom. Našli smo kar nekaj zanimivih rešitev, vključno s server-side renderiranjem in spletnimi vtičnicami.

Opravili smo 21 intervju po tej shemi. Publika je bila popolnoma raznolika — recimo na stripih:

1. «Raketa». Nikoli se ne ustavi, povsod se pritisne, na intervjuju pa vas zasuje s Tokom misli, ki ni neposredno povezan z zastavljenim vprašanjem. Če bi to bilo na univerzi, bi to bila mnogim znana poskus pokazati prav vse svoje znanje, ko se o vstopnem vprašanju spomniš le to, da si ga prejšnjo noč odločil, da se ga ne učiš — tako ali tako ga ne boš potegnil.
2. «Groot». Z njim je precej težko vzpostaviti stik, ker je Groot. Na intervjuju se je potrebno dolgo ustavljati, izsiljevati odgovore besedo za besedo. Dobro je, če gre le za zastoje — sicer vam bo kasneje v vsakdanjem delu zelo težko.
3. «Drax». Pred tem se je ukvarjal s prevozom blaga, programiranja pa se je učil samo JS po Stackoverflow, zato ne razume vedno, o čem se pravzaprav govori na razgovoru. Je pa dober človek, ima najboljše namene in si želi postati odličen frontend razvijalec.
4. In verjetno, «Zvezdni lord». Na splošno dober kandidat, s katerim se da dogovoriti in zgraditi dialog.

Na koncu naših raziskovanj 7 kandidatov je prišlo v finale, potrdili so svoje trde spretnosti s fantastičnimi nalogami in dobrimi odgovori pri intervjuju.

Kulturna prileganje

Za podjetje: S njim ali njo boste delali! Je kandidat pripravljen delati izjemno veliko za svoj razvoj? Se bo zagotovo vključil v ekipo?

Za junaka: Z njimi boste delali! Je podjetje pripravljeno vlagati v rast juniorjev ali pa vas bo preprosto obremenilo s celotnim umazanim delom za nizko plačo?

Vsak junior se poleg produktne ekipe, katere vodja ga mora sprejeti, sreča s mentorjem. Naloga mentorja je, da ga vodi skozi trimesečni proces uvajanja in izboljšanja trdih veščin. Zato smo na vsakem kulturnem usklajevanju prišli kot mentorji in si postavili vprašanje: 'Ali bom prevzel odgovornost za napredovanje kandidata v treh mesecih po našem načrtu?'

Ta korak je potekal brez posebnosti in nam je na koncu prinesel 4 ponudbe, od katerih so bile 3 sprejete in so fantje stopili v ekipe.

Življenje po ponudbi

Za podjetje: Poskrbite za svoje juniorje ali pa to storijo drugi!

Za junaka: AAAAAAA!!!

Ko pride nov delavec, ga je treba vključiti — seznaniti z načini dela, razložiti, kako je vse urejeno v podjetju in timu ter kako naj sploh dela. Ko pride junior, je treba razumeti, kako ga razvijati.

Ko smo o tem razmišljali, smo oblikovali seznam 26 veščin, ki jih, po našem mnenju, mora imeti junior ob koncu tridomesečne vpeljave. Na seznamu so hardskills (po našem sklopu), znanje o naših procesih, scrumu, infrastrukturi in arhitekturi projekta. Združili smo jih v načrt, razdeljen po času na 3 mesece.

Na primer, tukaj je načrt mojega juniorja.

Vsakemu juniorju pripnemo mentorja, ki z njim dela individualno. Glede na mentorja in trenutno raven kandidata se srečanja lahko izvajajo od 1 do 5-krat na teden po 1 uro. Mentorji so prostovoljno postali proaktivni frontend razvijalci, ki želijo delati nekaj več kot zgolj pisati kodo.

Del bremena z mentorjev odstranijo tečaji o našem sklopu — Dart, Angular. Tečaji se redno izvajajo za majhne skupine od 4 do 6 oseb, kjer fantje delajo brez prekinitve od dela.

V dneh 3 mesecev občasno zbiramo povratne informacije od juniorjev, njihovih mentorjev in liderjev ter prilagajamo proces individualno. 1-2 krat v celotnem obdobju se izvede preverjanje razvitega znanja, podobno preverjanje pa se izvede na koncu — na njihovi podlagi se oblikujejo priporočila, kaj točno je treba izboljšati.

Zaključek

Za podjetje: Ali se splača vlagati v junarje? Da!

Za junaka: Iščite podjetja, ki natančno izbirajo kandidate in vedo, kako jih razvijati.

V treh mesecih smo pregledali 122 anket, 54 testnih nalog in izvedli 21 tehničnih intervjujev. To nam je prineslo 3 odlične junarje, ki so trenutno prešli polovico svojih načrtov za vpeljavo in pospeševanje. Že rešujejo dejanske naloge v našem projektu, kjer je samo na frontend več kot 2.000.000 vrstic kode in več kot 400 repozitorijev.

Ugotovili smo, da je proces za junarje lahko in mora biti dovolj zapleten, ampak na koncu skozi njega preidejo le tisti fantje, ki so res pripravljeni zelo delati in vlagati v svoj razvoj.

Sedaj je naš glavni cilj zaključiti trid mesečne načrte za razvoj za vsakega juniora v okviru individualnega dela z mentorjem in skupnih tečajev, zbrati metrike, povratne informacije vodij, mentorjev in samih mladih. Na tem mestu lahko prvi poskus šteti za zaključen, izvleči zaključke, izboljšati proces in ga ponovno zagnati za selekcijo novih kandidatov.

Izvor: habr.com