Jak zkrotit juniory?

Jak se dostat do velké firmy, když jsi junior? Jak najít kvalitního juniora, když jsi velká firma? V tomto článku se podělím o náš příběh najímání začínajících lidí na frontend: o tom, jak jsme zpracovávali testovací úkoly, připravovali se na vedení pohovorů a vytvářeli mentorské programy pro rozvoj a onboardování nováčků, a také proč nefungují standardní otázky na pohovorech.

Snažím se zkrotit juniora

Ahoj! Jmenuji se Pavel, dělám frontend v týmu Wrike. Vytváříme systém pro řízení projektů a týmovou spolupráci. Věnuji se webu od roku 2010, 3 roky jsem pracoval na zahraniční remote pozici, účastnil jsem se několika startupů a vyučoval jsem kurz webových technologií na univerzitě. V naší společnosti se podílím na rozvoji technických kurzů a mentorské programu Wrike pro juniory, stejně jako na jejich recrutaci.

Proč jsme se vůbec rozhodli najmout juniory

Až do nedávné doby jsme nabírali frontend vývojáře úrovně middle nebo senior — dostatečně samostatné na to, aby po onboardingu řešili produktové úkoly. Na začátku tohoto roku jsme si uvědomili, že chceme změnit tuto politiku: za rok se počet našich produktových týmů téměř zdvojnásobil, počet frontend developerů se blíží stovce a v nedaleké perspektivě by se to mělo opět zdvojnásobit. Práce je hodně, volných rukou málo a na trhu jich je ještě méně, proto jsme se rozhodli obrátit na lidi, kteří teprve začínají svou cestu ve frontendu, a pochopili jsme, že jsme připraveni investovat do jejich rozvoje.

Kdo je junior?

To byla první otázka, kterou jsme si položili. Existují různé kritéria, ale nejjednodušší a nejsrozumitelnější princip je následující:

Juniorovi je potřeba vysvětlit, jakou funkci a jakudělat. Middle potřebuje vysvětlit, jaká funkce je potřeba, a on si s realizací poradí sám. Senior ti sám vysvětlí, proč tu funkci není potřeba dělat vůbec.

Tak či onak, junior je ten vývojář, který potřebuje radu, jak přesně realizovat to či ono řešení. Odkud jsme se rozhodli vycházet:

1. Junior je ten, kdo chce růst a je ochoten na tom hodně pracovat;
2. Ne vždy ví, kterým směrem chce růst;
3. Potřebuje radu a hledá pomoc zvenčí — od svého leadra, mentora nebo z komunity.

Měli jsme několik dalších hypotéz:

1. Na pozici juniora bude bouřka žádostí. Je nutné filtrovat náhodné přihlášky už na úrovni zasílání životopisů;
2. Prvotní filtr nepomůže — potřebujeme další testovací úkoly;
3. Testovací úkoly všechny odradí — nejsou potřeba.

Samozřejmě, naším cílem bylo: 4 juniory za 3 týdny.

S tímto uvědoměním jsme začali experimentovat. Plán byl jednoduchý: začít s co nejširšími možnostmi a postupně je zúžit, abychom stíhali zpracovávat příliv, ale abychom to nesnížili na 1 kandidáta za týden.

Oznamujeme pracovní nabídku

Pro společnost: Budou stovky žádostí! Zamyslete se nad filtrem.

Pro juniora: Nebojte se dotazníku před odesláním životopisu a testovacího úkolu — je to znak toho, že se o vás společnost stará a dobře nastavila proces.

Hned první den k nám přišlo asi 70 životopisů od kandidátů „s znalostí JavaScriptu“. A pak další. A další. Fyzicky jsme nemohli pozvat všechny na pohovor do kanceláře a vybrali jsme z nich lidi s nejzajímavějšími pet projekty, aktivním GitHubem nebo alespoň zkušenostmi.

Ale hlavní závěr, který jsme si udělali hned první den — bouřka začala. Nastal čas přidat formulář dotazníku před odesláním životopisu. Jeho úkolem bylo filtre kandidáty, kteří nejsou ochotni věnovat minimální úsilí k odeslání životopisu, a ty, kteří nemají znalosti a kontext alespoň v takové míře, aby si našli správné odpovědi.

Obsahoval standardní otázky o JS, frontend, web, počítačových vědách — ty zná každý, kdo ví, co se ptát na pohovoru na frontendu. Jaký je rozdíl mezi let/var/const? Jak aplikovat styly pouze na obrazovkách menších než 600px na šířku? Nechtěli jsme klást tyto otázky na technickém pohovoru — praxe ukázala, že na ně lze odpovědět po 2-3 pohovorech, aniž byste se vyznali v vývoji. Ale ukázaly nám, zda kandidát v zásadě rozumí kontextu.

V každé kategorii jsme připravili 3-5 otázek a den za dnem měnili jejich soubor ve formuláři žádosti, dokud jsme nevyloučili ty nejjednodušší a nejtvrdší. To umožnilo zkrátit tok — za 3 týdny jsme obdrželi 122 kandidátů, se kterými bylo možné dále pracovat. Byli to studenti IT; chlapci, kteří chtěli přejít z backendu na frontend; pracovníci nebo inženýři ve věku 25-35 let, kteří se rozhodli radikálně změnit svou kariéru a vložili různé úsilí do sebevzdělávání, kurzů a stáží.

Poznejme se blíže

Pro společnost: Testovací úkol neodradí kandidáty, ale pomáhá zkrátit náborový proces.

Pro juniora: Nekopírujte testovací úkoly - je to nápadné. A mějte svůj GitHub v pořádku!

Kdybychom pozvali všechny na technické pohovory, museli bychom uskutečnit asi 40 pohovorů týdně jen pro juniory a pouze na frontendu. Proto jsme se rozhodli ověřit druhou hypotézu - ohledně testovacího úkolu.

Co pro nás bylo v testovacím úkolu důležité:

1. Vytvořit dobré škálovatelné architektury, ale bez přehnaného inženýrství;
2. Lepší udělat to déle, ale udělat to dobře, než to udělat za noc a poslat to s komentářem 'určitě to dodělám';
3. Historie vývoje v Gitu - inženýrská kultura, iterativní vývoj a to, že řešení není naprosto bezostyšně okopírované.

Shodli jsme se, že chceme vidět jedno algoritmické zadání a malé webové aplikace. Algoritmické úkoly byly připraveny na úrovni laboratorních prací počátečních kurzů - binární vyhledávání, třídění, kontrola na anagramy, práce se seznamy a stromy. Nakonec jsme se rozhodli pro binární vyhledávání jako první zkušební variantu. Webovou aplikací měly být piškvorky s použitím jakéhokoli rámce (nebo bez něj).

Testovací úkol zvládlo téměř polovina zbylých chlapců - poslali nám řešení 54 kandidátů. Neuvěřitelný náhled - kolik implementací piškvorek, připravených k okopírování, je na internetu?

Kolik?Ve skutečnosti se zdá, že jen 3. A v převážné většině řešení byly právě tyto 3 varianty.
Co se mi nelíbilo:

• kopírování, nebo vývoj podle stejného tutoriálu bez vlastní architektury;
• oba úkoly v jednom repozitáři v různých složkách, historie commitů samozřejmě není;
• nečistý kód, porušení DRY, absence formátování;
• směs modelu, pohledu a kontroleru v jedné třídě dlouhé stovky řádků kódu;
• absence porozumění jednotkovému testování;
• řešení „přesně“ – hardcode matice vítězných kombinací 3x3, což bude dost obtížné rozšířit na 10x10, například.

A navíc jsme se zajímali o sousední repozitáře – skvělé pet projekty byly ziskové, zatímco spousta testovacích úloh od jiných společností byla spíše varovným signálem: proč nebyl kandidát schopen projít tam?

Nakonec jsme našli skvělé možnosti na React, Angular, Vanilla JS – jich bylo celkem 29. A dalšího kandidáta jsme se rozhodli pozvat bez testu za jeho velmi skvělé pet projekty. Naše hypotéza o užitečnosti testovacích úloh se potvrdila.

Technické interview

Pro společnost: K vám přišli nejen middle/senioři! Je potřeba více individuálního přístupu.

Pro juniora: Pamatujte, že to není zkouška – nesnažte se pouze mlčet na trojku nebo zavalit profesora záplavou všech svých možných znalostí, abychom ho zmátli a dostali „výborně“.

Co chceme pochopit na technickém interview? Jednoduchou věc – jak kandidát uvažuje. Pravděpodobně má nějaké hard skilly, pokud prošel prvními etapami výběru – zbývá zjistit, zda je umí uplatnit. Domluvili jsme se na 3 úlohách.

První – o algoritmech a datových strukturách. S tužkou, na papír, v pseudo-jazyce a pomocí obrázků jsme se zabývali tím, jak zkopírovat strom nebo jak odstranit prvek z jednosměrného seznamu. Nepříjemným zjištěním bylo, že ne všichni chápou rekurzi a jak fungují odkazy.

Druhá – live coding. Navštívili jsme codewars.com, vybrali jsme jednoduché úkoly jako třídění pole slov podle posledního písmene a během 30-40 minut jsme společně s kandidátem snažili projít všechny testy. Zdálo se, že by neměly být žádné překvapení od lidí, kteří zvládli piškvorky – ale praxí nebyli všichni schopni pochopit, že hodnotu je potřeba uložit do proměnné a funkce by měla něco vracet pomocí return. Ačkoliv upřímně doufám, že to byla nervozita a kluci se s těmito úkoly dokázali vyrovnat v příjemnějších podmínkách.

Nakonec třetí – trochu o architektuře. Diskutovali jsme o tom, jak udělat vyhledávací řádek, jak při tom funguje debounce, jak renderovat různé widgety v návrzích vyhledávání, jak frontend může komunikovat s backendem. Objevilo se mnoho zajímavých řešení, včetně server-side renderingu a webových socketů.

Provedli jsme 21 rozhovor v tomto formátu. Publikum bylo naprosto různorodé — vezměme si to na komiksech:

1. „Raketa“. Nikdy se neusazuje, všude se cpou, a na rozhovoru vás zaplaví proudem myšlenek, které nemají přímo souvislost s položenou otázkou. Kdyby to bylo na univerzitě, byla by to známá pokus o předvedení veškerých znalostí, když si při náhodné otázce pamatujete jen to, že jste se rozhodli ji včera večer nenaučit — stejně byste ji nevytáhli.
2. „Groot“. S ním je opravdu těžké navázat kontakt, protože on je Groot. Na rozhovoru je potřeba dlouho rozjíždět, vytahovat odpovědi slovo po slově. Je dobře, pokud jde jen o zmatek — jinak vám pak při každodenní práci bude velmi těžko.
3. „Drax“. Dřív se zabýval přepravou, a z programování se učil jen JS na Stackoverflow, takže občas vůbec nerozumí, o čem se při pohovoru mluví. Na druhou stranu je to dobrý člověk, má nejlepší úmysly a chce se stát skvělým front-end vývojářem.
4. No a asi „Star-Lord“. Obecně slušný kandidát, se kterým se dá dohodnout a vybudovat dialog.

Na konci našich zkoumání 7 kandidátů se dostalo do finále, potvrdili své hard skills skvělým testovacím úkolem a dobrými odpověďmi na pohovoru.

Kultura fit

Pro společnost: Budete s ním pracovat! Je kandidát ochoten pracovat extrémně mnoho pro svůj rozvoj? Skutečně zapadne do týmu?

Pro juniora: Budete s nimi pracovat! Je firma ochotná investovat do růstu juniorů, nebo si na vás jednoduše hodí všechnu špinavou práci za nízký plat?

Každý junior, kromě produktového týmu, jehož vedoucí musí souhlasit s jeho přijetím, dostane mentora. Úkolem mentora je provést ho tříměsíčním procesem onboardingu a zlepšení hard skills. Proto jsme na každé kulturní shodě přišli jako mentoři a ptali se sami sebe: „Vezmu si na sebe zodpovědnost rozvíjet kandidáta za 3 měsíce podle našeho plánu?“

Tato fáze proběhla bez zvláštností a nakonec nám přinesla 4 nabídky, z nichž 3 byly přijaty, a kluci nastoupili do týmů.

Život po nabídce

Pro společnost: Postarejte se o své juniory, nebo to udělají jiní!

Pro juniora: AAAAAAAAHHHHHHHH!!!

Když nový zaměstnanec nastoupí, je třeba ho onboardovat — seznámit ho s procesy, vysvětlit, jak to ve společnosti a týmu funguje a jak vůbec má pracovat. Když nastoupí junior, je potřeba pochopit, jak ho rozvíjet.

Když jsme na to mysleli, sestavili jsme seznam 26 dovedností, kterými by podle našeho názoru měl junior disponovat na konci tří měsíčního onboardingu. Zahrnuli jsme tam hard skills (podle našeho stacku), znalosti našich procesů, scrum, infrastrukturu a architekturu projektu. Spojili jsme je do roadmapy rozložené na 3 měsíce.

Například tato je roadmapa mého juniora.

K každému juniorovi přiřazujeme mentora, který s ním pracuje individuálně. V závislosti na mentorovi a aktuální úrovni kandidáta se setkání konají 1 až 5krát týdně po 1 hodině. Mentory se dobrovolně stávají iniciativní frontendisté, kteří chtějí dělat něco víc než jen psát kód.

Část zátěže z mentorů se snáší pomocí kurzů našeho stacku — Dart, Angular. Kurzy se pravidelně konají pro malé skupiny o 4-6 lidech, kde se účastníci učí bez přerušení práce.

Během 3 měsíců pravidelně sbíráme zpětnou vazbu od juniorů, jejich mentorů a leadů a korigujeme proces individuálně. 1-2krát během celého období se provádí kontrola zdokonalených dovedností, stejná kontrola se provádí na konci — na jejich základě se formulují doporučení, na čem je třeba zapracovat.

Závěr

Pro společnost: Má smysl investovat do juniorů? Ano!

Pro juniora: Hledejte společnosti, které pečlivě vybírají kandidáty a vědí, jak je rozvíjet.

Během 3 měsíců jsme prověřili 122 dotazníků, 54 testových úloh a provedli 21 technických pohovorů. To nám přineslo 3 skvělé juniory, kteří nyní prošli polovinou svých onboardingových a akcelerovaných roadmap. Již řeší skutečné produktové úkoly v našem projektu, kde na frontendu je více než 2 000 000 řádků kódu a více než 400 repozitářů.

Zjistili jsme, že proces pro juniory může a měl by být dost složitý, ale nakonec jím projdou pouze ti, kteří jsou skutečně připraveni hodně pracovat a investovat do svého rozvoje.

Naší aktuální prioritou je dokončit tří měsíční rozvojové plány pro každého juniora formou individuální práce s mentorem a společných kurzů, shromáždit metriky, zpětnou vazbu od leadů, mentorů a samotných účastníků. Po tomto prvním experimentu bychom mohli považovat za úspěšně dokončené, vyvodit závěry, vylepšit proces a znovu ho spustit pro výběr nových uchazečů.

Zdroj: habr.com