Jak se dostat do velké společnosti, když jste junior? Jak najmout slušného juniora, pokud jste velká společnost? Pod střihem vám řeknu náš příběh o najímání začátečníků na frontendu: jak jsme prošli testovacími úkoly, připravili se na vedení pohovorů a vybudovali mentorský program pro rozvoj a začleňování nováčků, a také proč se standardní otázky pohovoru nedají nefunguje.
Snažím se ochočit Juniora
Ahoj! Jmenuji se Pavel a dělám front-end v týmu Wrike. Vytváříme systém pro řízení projektů a spolupráci. Webu se věnuji od roku 2010, působil jsem 3 roky v zahraničí, podílel jsem se na několika startupech a vedl kurz webových technologií na univerzitě. Ve firmě se zabývám vývojem technických kurzů a mentoringového programu Wrike pro juniory a také jejich přímým náborem.
Proč jsme vůbec uvažovali o najímání juniorů?
Až donedávna jsme pro frontend najímali vývojáře na střední nebo vyšší úrovni – dostatečně nezávislé na to, aby po připojení dělali produktové úkoly. Na začátku letošního roku jsme si uvědomili, že chceme tuto politiku změnit: v průběhu roku se počet našich produktových týmů téměř zdvojnásobil, počet front-endových vývojářů se přiblížil stovce a v blízké budoucnosti to vše musí znovu 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 se na kluky, kteří svou cestu frontendem teprve začínají, a uvědomili jsme si, že jsme připraveni investovat do jejich rozvoj.
Kdo je junior?
To je úplně první otázka, kterou jsme si položili. Existují různá kritéria, ale nejjednodušší a nejsrozumitelnější princip je tento:
Juniorovi je třeba vysvětlit, jakou funkci a jak na to. Střednímu je třeba vysvětlit, jaká funkce je potřeba, a implementaci si vymyslí sám. Sám signor vám vysvětlí, proč se tato funkce vůbec nemusí provádět.
Tak či onak, junior je vývojář, který potřebuje poradit, jak implementovat to či ono řešení. Na čem jsme se rozhodli stavět:
- Junior je někdo, kdo se chce rozvíjet a je připraven pro to tvrdě pracovat;
- Ne vždy ví, kterým směrem se chce rozvíjet;
- Potřebuje radu a hledá pomoc zvenčí – u svého vedoucího, mentora nebo v komunitě.
Měli jsme také několik hypotéz:
- Na červnové stanovisko se strhne bouře ohlasů. Náhodné odpovědi musíte filtrovat ve fázi zasílání životopisu;
- Primární filtr nepomůže. — je zapotřebí více testovacích úloh;
- Testovací úkoly všechny vyděsí - nejsou potřeba.
A samozřejmě jsme měli cíl: 4 junioři za 3 týdny.
S tímto zjištěním jsme začali experimentovat. Plán byl jednoduchý: začít s co nejširším trychtýřem a pokusit se ho postupně zužovat, abyste tok zvládli zpracovat, ale nesnížit na 1 kandidáta za týden.
Zveřejňujeme volné pracovní místo
Pro firmu: Budou stovky odpovědí! Přemýšlejte o filtru.
Pro juniora: Nebojte se dotazníku před odesláním životopisu a zadání testu – je to známka toho, že se o vás společnost postarala a proces dobře nastavila.
První den jsme obdrželi asi 70 životopisů od kandidátů „se znalostí JavaScriptu“. A pak znovu. A dál. Fyzicky jsme nemohli pozvat všechny do kanceláře na pohovor a vybrali jsme z nich kluky s nejlepšími pet projekty, živým Githubem nebo alespoň zkušenostmi.
Ale hlavní závěr, který jsme si udělali hned první den, byl, že začala bouřka. Nyní je čas přidat dotazník před odesláním životopisu. Jejím cílem bylo vyřadit kandidáty, kteří nebyli ochotni vynaložit minimální úsilí na odeslání životopisu, a ty, kteří neměli znalosti a kontext, aby si správné odpovědi alespoň vygooglovali.
Obsahoval standardní otázky o JS, layoutu, webu, Computer Science – každý, kdo si představí, na co se ptá na front-end pohovoru, je zná. Jaký je rozdíl mezi let/var/const? Jak mohu použít styly pouze na obrazovky menší než 600 pixelů na šířku? Tyto otázky jsme nechtěli klást na technickém pohovoru – praxe ukázala, že na ně lze odpovědět po 2-3 pohovorech, aniž bychom vůbec rozuměli vývoji. Ale dokázali nám zpočátku ukázat, zda kandidát v zásadě rozumí kontextu.
V každé kategorii jsme připravili 3-5 otázek a den po dni jsme jejich sestavu měnili v odpovědním formuláři, dokud jsme nevyřadili tu nejschůdnější a nejobtížnější. To nám umožnilo snížit průtok - za 3 týdny jsme dostali 122 kandidátů, se kterými bychom mohli dále pracovat. Byli to studenti IT; kluci, kteří se chtěli posunout dopředu z backendu; dělníci nebo inženýři ve věku 25–35 let, kteří chtěli radikálně změnit své povolání a vložili různé úsilí do sebevzdělávání, kurzů a stáží.
Lepší vzájemné poznávání
Pro firmu: Testovací úloha kandidáty neodrazuje, ale pomáhá zkrátit cestu.
Pro juniora: Nekopírujte a nevkládejte testovací – je to patrné. A udržujte svůj github v pořádku!
Pokud bychom všechny pozvali na technický pohovor, museli bychom vést asi 40 pohovorů týdně jen pro juniory a pouze na frontendu. Proto jsme se rozhodli otestovat druhou hypotézu – o testovací úloze.
Co bylo pro nás v testu důležité:
- Vybudujte dobrou škálovatelnou architekturu, ale bez nadměrného inženýrství;
- Je lepší trvat déle, ale udělat to dobře, než složit řemeslo přes noc a poslat ho s komentářem „určitě to dokončím“;
- Historie vývoje v Gitu je inženýrská kultura, iterativní vývoj a skutečnost, že řešení nebylo nestydatě kopírováno.
Shodli jsme se, že se chceme podívat na jeden algoritmický problém a malou webovou aplikaci. Algoritmické byly připraveny na úrovni laboratoří základní úrovně - binární vyhledávání, třídění, kontrola přesmyček, práce se seznamy a stromy. Nakonec jsme se rozhodli pro binární vyhledávání jako první zkušební možnost. Webová aplikace musela být tic-tac-toe pomocí jakéhokoli frameworku (nebo bez něj).
Téměř polovina zbývajících kluků splnila testovací úkol - poslali nám řešení 54 kandidátů. Neuvěřitelný náhled – kolik si myslíte, že existuje na internetu implementací piškvorek připravených ke kopírování a vkládání?
Kolik?Ve skutečnosti se zdá, že jsou pouze 3. A v drtivé většině rozhodnutí byly právě tyto 3 možnosti.
Co se nelíbilo:
- copy-paste neboli vývoj založený na stejném tutoriálu bez vlastní architektury;
- obě úlohy jsou ve stejném úložišti v různých složkách, samozřejmě neexistuje žádná historie odevzdání;
- špinavý kód, porušení DRY, nedostatek formátování;
- směs modelu, pohledu a ovladače do jedné třídy dlouhé stovky řádků kódu;
- nedostatečné porozumění jednotkovému testování;
- „head-on“ řešení je pevný kód matice 3x3 výherních kombinací, kterou bude poměrně obtížné rozšířit například na 10x10.
Věnovali jsme pozornost také sousedním úložištím – skvělé projekty pro domácí mazlíčky byly plusem a spousta testovacích úkolů od jiných společností byla spíše probuzením: proč se tam kandidát nemohl dostat?
Výsledkem bylo, že jsme našli skvělé možnosti v React, Angular, Vanilla JS – bylo jich 29. A rozhodli jsme se pozvat ještě jednoho kandidáta bez testování pro jeho velmi cool pet projekty. Naše hypotéza o přínosu testovacích úloh se potvrdila.
Technický pohovor
Pro firmu: Nejsou to střední/senioři, kdo k vám přišel! Potřebujeme více individuální přístup.
Pro juniora: Pamatujte, že se nejedná o zkoušku – nesnažte se mlčet na C nebo bombardovat profesora proudem všech svých možných znalostí, aby se zmátl a dal „výborně“.
Co chceme pochopit v technickém rozhovoru? Jednoduchá věc – jak kandidát uvažuje. Pravděpodobně má nějaké tvrdé dovednosti, pokud prošel prvními fázemi výběru - teprve se uvidí, zda je ví, jak je používat. Dohodli jsme se na 3 úkolech.
První je o algoritmech a datových strukturách. Perem, na papíře, v pseudojazyku a pomocí nákresů jsme přišli na to, jak zkopírovat strom nebo jak odstranit prvek z jednoduše propojeného seznamu. Nepříjemným zjištěním bylo, že ne každý rozumí rekurzi a tomu, jak fungují reference.
Druhým je živé kódování. Jsme se vydali do , zvolili jednoduché věci, jako je řazení pole slov podle posledního písmene, a po dobu 30-40 minut se společně s kandidátem snažili, aby všechny testy prošly. Zdálo se, že od kluků, kteří ovládali piškvorky, by se nemělo čekat žádné překvapení – ale v praxi si ne každý dokázal uvědomit, že hodnota by měla být uložena v proměnné a funkce by měla něco vracet přes return. I když upřímně doufám, že to byla nervozita a kluci si s těmito úkoly poradili v lehčích podmínkách.
Konečně třetí je trochu o architektuře. Diskutovali jsme o tom, jak vytvořit vyhledávací lištu, jak funguje debounce, jak vykreslit různé widgety v tipech pro vyhledávání, jak může frontend interagovat s backendem. Bylo tam mnoho zajímavých řešení, včetně vykreslování na straně serveru a webových soketů.
Pomocí tohoto designu jsme provedli 21 rozhovorů. Publikum bylo naprosto rozmanité – podívejme se na komiksy:
- "Raketa". Nikdy se neuklidní, do všeho se zaplete a při rozhovoru vás zavalí proudem myšlenek, které ani přímo nesouvisí s položenou otázkou. Kdyby to bylo na univerzitě, byl by to známý pokus demonstrovat, no, všechny své znalosti, když si o lístku, na který jste narazili, pamatujete jen to, že jste se včera večer rozhodli, že ho nebudete studovat - stále nemůžete získat to ven.
- "Groot". Je docela těžké se s ním spojit, protože je Groot. Během pohovoru musíte strávit dlouhou dobu snahou získat odpovědi slovo od slova. Je dobré, když je to jen stupor - jinak to pro vás bude při každodenní práci velmi obtížné.
- "drax". Dříve jsem pracoval v nákladní dopravě a z hlediska programování jsem se naučil JS pouze na Stackoverflow, takže ne vždy rozumím tomu, o čem se na pohovoru diskutuje. Zároveň je to dobrý člověk, má ty nejlepší úmysly a chce se stát skvělým front-end vývojářem.
- No, pravděpodobně "Pán hvězd". Celkově dobrý kandidát, se kterým se dá vyjednávat a budovat dialog.
Na závěr našeho výzkumu 7 kandidátů se dostali do finále a potvrdili své tvrdé dovednosti skvělým testovacím úkolem a dobrými odpověďmi na pohovor.
Kulturní fit
Pro firmu: Pracuješ s ním! Je kandidát ochoten pro svůj rozvoj extrémně tvrdě pracovat? Opravdu zapadne do týmu?
Pro juniora: Pracuješ s nimi! Je firma skutečně připravena investovat do růstu juniorů, nebo na vás prostě za nízký plat hodí všechnu špinavou práci?
Každý junior kromě produktového týmu, jehož vedení musí souhlasit s jeho převzetím, dostane mentora. Úkolem mentora je provést ho tříměsíčním procesem začleňování a upgradování tvrdých dovedností. Proto jsme ke každému kulturnímu fitku přišli jako mentoři a odpověděli jsme na otázku: „Převezmu zodpovědnost za vývoj kandidáta do 3 měsíců podle našeho plánu?“
Tato etapa proběhla bez zvláštních rysů a nakonec nás přivedla 4 nabídky, z nichž 3 byly přijaty a kluci se přihlásili do týmů.
Život po nabídce
Pro firmu: Postarejte se o své juniory nebo ostatní!
Pro juniora: AAAAAAAAAAAA!!!
Když přijde nový zaměstnanec, je potřeba ho začlenit – seznámit s procesy, říct mu, jak vše ve firmě a v týmu funguje a jak by měl fungovat obecně. Když vyjde junior, musíte pochopit, jak ho rozvíjet.
Když jsme se nad tím zamysleli, vyšel nám seznam 26 dovedností, které by podle nás měl mít junior do konce tříměsíčního onboardingu. To zahrnovalo tvrdé dovednosti (podle našeho stacku), znalost našich procesů, Scrumu, infrastruktury a architektury projektu. Spojili jsme je do cestovní mapy, rozložené na 3 měsíce.
Tady je například plán mého juniora
Každému juniorovi přidělujeme mentora, který s ním individuálně pracuje. V závislosti na mentorovi a aktuální úrovni kandidáta se setkání mohou konat 1x až 5x týdně po 1 hodině. Mentoři jsou dobrovolní front-end vývojáři, kteří chtějí dělat něco víc než jen psát kód.
Část zátěže mentorů je odstraněna kurzy na našem stacku - Dart, Angular. Kurzy se konají pravidelně pro malé skupiny 4-6 osob, kde studenti studují 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 upravujeme proces individuálně. Napumpované dovednosti se kontrolují 1-2krát za celou dobu, stejná kontrola se provádí na konci - na základě nich se tvoří doporučení, co přesně je třeba zlepšit.
Závěr
Pro firmu: Vyplatí se 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 zkontrolovali 122 dotazníků, 54 testovacích úloh a provedli 21 technických rozhovorů. To nám přineslo 3 skvělé juniory, kteří nyní dokončili polovinu svých onboardových a akceleračních plánů. V našem projektu, kde je jen na frontendu více než 2 000 000 řádků kódu a více než 400 úložišť, již dokončují skutečné produktové úkoly.
Zjistili jsme, že trychtýř pro juniory může a měl by být poměrně složitý, ale nakonec jím projdou jen ti kluci, kteří jsou opravdu připraveni hodně pracovat a investovat do svého rozvoje.
Nyní je naším hlavním úkolem dokončit tříměsíční rozvojové roadmapy pro každého juniora v režimu individuální práce s mentorem a obecných kurzů, sbírat metriky, zpětnou vazbu od leadů, mentorů i samotných kluků. V tomto okamžiku lze považovat první experiment za dokončený, lze vyvozovat závěry, proces lze zlepšit a lze jej znovu zahájit pro výběr nových kandidátů.
Zdroj: www.habr.com