Hogyan lehet megszelídíteni egy juniort?

Hogyan kerülhetsz be egy nagy társaságba, ha junior vagy? Hogyan lehet tisztességes juniort felvenni, ha nagy cég vagy? A vágás alatt elmesélem a kezdők felvételének történetét: hogyan dolgoztunk a tesztfeladatokon, hogyan készültünk interjúk lefolytatására, és hogyan építettünk fel mentori programot az újonnan érkezők fejlesztésére és beiskolázására, valamint azt is, hogy miért nem a szokásos interjúkérdések. nem működik.

Próbálom megszelídíteni Juniort

Helló! A nevem Pavel, front-end munkát végzek a Wrike csapatában. Projektmenedzsment- és együttműködési rendszert hozunk létre. 2010 óta dolgozom a weben, 3 évet dolgoztam külföldön, több startupban is részt vettem és webtechnológiák kurzusát tanítottam az egyetemen. A cégnél részt veszek a junioroknak szóló műszaki tanfolyamok és a Wrike mentorprogram kidolgozásában, valamint közvetlen toborzásban.

Miért is gondoltunk arra, hogy juniorokat veszünk fel?

Egészen a közelmúltig közép- vagy felső szintű fejlesztőket toboroztunk a frontend számára – elég függetlenek ahhoz, hogy a beépítés után a termékfeladatokat elvégezzék. Az idei év elején rájöttünk, hogy ezen a politikán szeretnénk változtatni: az év során a termékcsapataink száma majdnem megduplázódott, a front-end fejlesztők száma megközelítette a százat, és a közeljövőben mindez ismét duplázni kell. Sok a munka, kevés a szabad kéz, és még kevesebb van belőlük a piacon, ezért úgy döntöttünk, hogy azokhoz a srácokhoz fordulunk, akik még csak most kezdik útjukat a front end-ben, és rájöttünk, hogy készek vagyunk befektetni az ő fejlesztésükbe. fejlesztés.

Ki a junior?

Ez az első kérdés, amit feltettünk magunknak. Különféle kritériumok léteznek, de a legegyszerűbb és legérthetőbb elv a következő:

Juniornak el kell magyarázni, hogy milyen funkciót és hogyan kell csinálni. A Középnek el kell magyarázni, hogy milyen funkcióra van szükség, és ő maga találja ki a megvalósítást. Az aláíró maga fogja elmagyarázni Önnek, hogy miért nem szükséges ezt a funkciót egyáltalán elvégezni.

Így vagy úgy, a junior egy fejlesztő, akinek tanácsra van szüksége egy ilyen vagy olyan megoldás megvalósításához. Amire úgy döntöttünk, hogy építünk:

1. Junior az, aki fejlődni akar, és kész keményen dolgozni ennek érdekében;
2. Nem mindig tudja, milyen irányba akar fejlődni;
3. Tanácsra van szüksége, és kívülről kér segítséget – vezetőjétől, mentorától vagy a közösségtől.

Több hipotézisünk is volt:

1. Június álláspontjára viharos válaszok fognak érkezni. Az önéletrajz elküldésének szakaszában szűrnie kell a véletlenszerű válaszokat;
2. Az elsődleges szűrő nem segít. — több tesztfeladatra van szükség;
3. A tesztfeladatok mindenkit elriasztanak - nincs rájuk szükség.

És persze volt egy célunk: 4 junior 3 hét alatt.

Ezzel a felismeréssel elkezdtünk kísérletezni. A terv egyszerű volt: kezdje a lehető legszélesebb tölcsérrel, és próbálja meg fokozatosan szűkíteni, hogy feldolgozza az áramlást, de ne csökkentse heti 1 jelöltre.

Üres állást hirdetünk

A cég számára: Több száz válasz lesz! Gondolj egy szűrőre.

Juniornak: Ne féljen a kérdőívtől, mielőtt elküldi önéletrajzát és tesztfeladatát – ez annak a jele, hogy a cég gondoskodott Önről, és jól beállította a folyamatot.

Az első napon körülbelül 70 önéletrajzot kaptunk olyan jelöltektől, akik „tudták a JavaScriptet”. Aztán újra. És tovább. Fizikailag nem tudtunk mindenkit meghívni az irodába egy interjúra, és közülük választottuk ki azokat a srácokat, akik a legmenőbb kisállat projektekkel, élő Githubbal vagy legalább tapasztalattal rendelkeznek.

De a fő következtetés, amit már az első napon levontunk magunknak, az volt, hogy elkezdődött a vihar. Itt az ideje, hogy önéletrajza elküldése előtt töltsön fel egy kérdőívet. Célja az volt, hogy kiszűrje azokat a jelölteket, akik nem hajlandók a minimális erőfeszítést megtenni az önéletrajz benyújtásáért, és azokat, akiknek nem volt megfelelő tudásuk és kontextusuk ahhoz, hogy legalább a Google-ben megtalálják a helyes válaszokat.

Normál kérdéseket tartalmazott a JS-ről, az elrendezésről, a webről, a számítástechnikáról – mindenki ismeri őket, aki elképzeli, mit kérdeznek egy front-end interjún. Mi a különbség a let/var/const között? Hogyan alkalmazhatok stílusokat csak a 600 képpontnál kisebb képernyőkre? Ezeket a kérdéseket nem egy technikai interjún akartuk feltenni – a gyakorlat azt mutatja, hogy 2-3 interjú után meg lehet válaszolni a fejlemények megértése nélkül. De először meg tudták mutatni, hogy a jelölt elvileg érti-e a szövegkörnyezetet.

Kategóriánként 3-5 kérdést készítettünk, és nap mint nap változtattuk a halmazukat a válaszlapon, amíg ki nem iktattuk a legmegfelelőbbet és a legnehezebbet. Ez lehetővé tette számunkra, hogy csökkentsük az áramlást - 3 hét alatt megkaptuk 122 jelölt, amellyel tovább dolgozhatnánk. Informatikus hallgatók voltak; srácok, akik a háttérből akartak előrébb lépni; 25-35 éves munkások vagy mérnökök, akik gyökeresen meg akarták változtatni a foglalkozásukat, és különböző erőfeszítéseket tettek az önképzésbe, tanfolyamokba és szakmai gyakorlatokba.

Jobban megismerni egymást

A cég számára: A tesztfeladat nem riasztja el a jelentkezőket, hanem segít lerövidíteni a tölcsért.

Juniornak: Ne másoljon és illesszen be teszteket – ez észrevehető. És tartsd rendben a githubot!

Ha mindenkit elhívnánk egy technikai interjúra, akkor hetente körülbelül 40 interjút kellene készítenünk csak a junioroknak és csak a front end-en. Ezért úgy döntöttünk, hogy teszteljük a második hipotézist - a tesztfeladatról.

Ami számunkra fontos volt a tesztben:

1. Építsen egy jó méretezhető architektúrát, de túltervezés nélkül;
2. Jobb, ha tovább tart, de jól csinálja, mint egyik napról a másikra összerakni egy mesterséget, és elküldeni a „mindenképpen befejezem” megjegyzéssel;
3. A Git fejlesztésének története a mérnöki kultúra, az iteratív fejlesztés és az a tény, hogy a megoldást nem másolták kirívóan.

Megállapodtunk, hogy egy algoritmikus problémát és egy kis webalkalmazást szeretnénk megvizsgálni. Az algoritmikusok elemi szintű laboratóriumok szintjén készültek - bináris keresés, rendezés, anagrammák ellenőrzése, listákkal és fákkal való munka. Végül a bináris keresés mellett döntöttünk, mint első próbalehetőséget. A webalkalmazásnak tic-tac-toe-nak kellett lennie bármilyen keretrendszerrel (vagy anélkül).

A megmaradt srácok majdnem fele teljesítette a tesztfeladatot – ők küldték el nekünk a megoldásokat 54 jelölt. Hihetetlen betekintés – mit gondol, hány tic-tac-toe implementációja létezik másolásra-beillesztésre készen az interneten?

Сколько?Valójában úgy tűnik, hogy csak 3 van. És a döntések túlnyomó többségében pontosan ez a 3 lehetőség szerepelt.
Ami nem tetszett:

• másolás-beillesztés, vagy ugyanazon az oktatóanyagon alapuló fejlesztés saját architektúrája nélkül;
• mindkét feladat ugyanabban a tárolóban van, különböző mappákban, természetesen nincs véglegesítési előzmény;
• piszkos kód, DRY megsértése, formázás hiánya;
• modell, nézet és vezérlő keveréke egy osztályba, több száz sornyi kódba;
• az egységtesztelés megértésének hiánya;
• a „head-on” megoldás a nyerő kombinációk 3x3-as mátrixának keménykódja, amelyet elég nehéz lesz például 10x10-re bővíteni.

Figyelmet fordítottunk a szomszédos repozitóriumokra is – a menő kisállat-projektek pluszt jelentettek, és egy rakás tesztfeladat más cégektől inkább ébresztő volt: miért nem juthatott el oda a jelölt?

Ennek eredményeként remek lehetőségeket találtunk a React, Angular, Vanilla JS-ben – volt belőlük 29. És úgy döntöttünk, hogy meghívunk még egy jelöltet anélkül, hogy tesztelnénk a nagyon klassz kisállat-projektjeit. A tesztfeladatok előnyeire vonatkozó hipotézisünk beigazolódott.

Technikai interjú

A cég számára: Nem középsők/idősek jöttek hozzád! Egyénibb megközelítésre van szükségünk.

Juniornak: Ne feledje, hogy ez nem vizsga – ne próbáljon hallgatni egy C-ért, és ne bombázza a professzort minden lehetséges tudásának folyamával, hogy összezavarodjon és „kiválót” adjon.

Mit akarunk megérteni egy technikai interjún? Egy egyszerű dolog – hogyan gondolkodik a jelölt. Valószínűleg van néhány kemény képessége, ha túljutott a kiválasztási első szakaszokon – majd kiderül, tudja-e használni ezeket. 3 feladatban állapodtunk meg.

Az első az algoritmusokról és az adatstruktúrákról szól. Tollal, papírlapon, álnyelven és rajzok segítségével kitaláltuk, hogyan másoljunk át egy fát, vagy hogyan távolítsunk el egy elemet egy külön linkelt listából. A kellemetlen felfedezés az volt, hogy nem mindenki érti a rekurziót és a hivatkozások működését.

A második az élő kódolás. Mentünk codewars.com, olyan egyszerű dolgokat választott, mint a szavak sorba rendezése az utolsó betűk szerint, és 30-40 percen keresztül a vizsgázóval együtt igyekezett minden vizsgát sikeresen teljesíteni. Úgy tűnt, nem érhetnek meglepetések a tic-tac-toe-t elsajátító srácok részéről – de a gyakorlatban nem mindenki tudta be, hogy az értéket egy változóban kell tárolni, és a függvénynek return útján kell visszaadnia valamit. Bár őszintén remélem, hogy ez egy izgalom volt, és a srácok könnyebb körülmények között is meg tudtak oldani ezeket a feladatokat.

Végül a harmadik egy kicsit az építészetről szól. Megbeszéltük, hogyan készítsünk keresősávot, hogyan működik a visszapattanás, hogyan jeleníthetünk meg különféle widgeteket a keresési tippekben, hogyan tud együttműködni a kezelőfelület a háttérrel. Rengeteg érdekes megoldás volt, köztük szerveroldali renderelés és web socket.

Ezzel a tervvel 21 interjút készítettünk. A közönség teljesen sokszínű volt – lássuk a képregényeket:

1. "Rakéta". Soha nem nyugszik meg, mindenbe belekeveredik, és egy interjú során olyan gondolatok sodrában áraszt el, amelyek nem is közvetlenül kapcsolódnak a feltett kérdéshez. Ha egy egyetemről lenne szó, ez egy ismerős kísérlet lenne az összes tudásod bemutatására, amikor csak arra emlékszel a jegyről, amivel találkoztál, hogy tegnap este úgy döntöttél, nem tanulod meg – még mindig nem tudod megszerezni. ki.
2. "Groot". Elég nehéz felvenni vele a kapcsolatot, mert ő Groot. Egy interjú során sok időt kell töltenie azzal, hogy szóról szóra választ kapjon. Jó, ha ez csak egy kábulat - különben nagyon nehéz lesz a mindennapi munkája során.
3. "Drax". Korábban teherszállításban dolgoztam, programozási szempontból pedig csak a Stackoverflow-n tanultam a JS-t, így nem mindig értem, miről beszélnek egy interjún. Ugyanakkor jó ember, a legjobb szándékai vannak, és nagyszerű front-end fejlesztő akar lenni.
4. Nos, valószínűleg "Csillag Úr". Összességében jó jelölt, akivel tárgyalhat és párbeszédet építhet.

Kutatásunk végén 7 jelölt bejutottak a döntőbe, remek tesztfeladattal és az interjúra adott jó válaszokkal megerősítve kemény tudásukat.

Kulturális illeszkedés

A cég számára: Dolgozz vele! Hajlandó-e a jelölt rendkívül keményen dolgozni a fejlődéséért? Tényleg beilleszkedik a csapatba?

Juniornak: Dolgozz velük! Valóban készen áll a cég arra, hogy befektessen a juniorok növekedésébe, vagy egyszerűen csak rád rakja az összes piszkos munkát alacsony fizetésért?

Minden junior, a termékcsapaton kívül, amelynek vezetőjének bele kell egyeznie, hogy felvegye őt, kap egy mentort. A mentor feladata, hogy végigvezesse őt egy három hónapig tartó folyamaton, amelyen a beépítés és a kemény készségek fejlesztése folyik. Ezért mentorként érkeztünk minden kulturális alkalomhoz, és a következő kérdésre válaszoltunk: „Vállalom-e a felelősséget azért, hogy terveink szerint 3 hónapon belül kifejlesztek egy jelöltet?”

Ez a szakasz minden különlegesség nélkül telt el, és végül elhozott minket 4 ajánlat, ebből 3-at elfogadtak, és a srácok bekerültek a csapatokba.

Élet az ajánlat után

A cég számára: Vigyázz az ifjaidra, különben mások megteszik!

Juniornak: ÁÁÁÁÁÁÁÁÁ!!!

Amikor egy új alkalmazott jön ki, be kell vonni – naprakészen kell hozni a folyamatokat, elmondani, hogyan működik minden a cégben és a csapatban, és általában hogyan kell dolgoznia. Amikor egy junior kijön, meg kell értened, hogyan fejlesztheted.

Amikor belegondoltunk, összeállítottunk egy 26 képességet tartalmazó listát, amellyel véleményünk szerint egy juniornak rendelkeznie kell a három hónapos beiskolázási időszak végére. Ez magában foglalta a kemény készségeket (a veremünk szerint), a folyamataink, a Scrum, az infrastruktúra és a projektarchitektúra ismerete. Ezeket összevontuk egy ütemtervben, amelyet 3 hónapra osztottak szét.

Például itt van a juniorom ütemterve

Minden juniorhoz kijelölünk egy mentort, aki egyénileg dolgozik vele. A mentortól és a jelentkező aktuális szintjétől függően heti 1-5 alkalommal 1 órás találkozóra kerülhet sor. A mentorok önkéntes front-end fejlesztők, akik többet akarnak tenni, mint csak kódot írni.

A mentorokra nehezedő terhek egy részét a stackünkön lévő tanfolyamok veszik le – Dart, Angular. Rendszeresen tartanak kurzusokat 4-6 fős kis csoportokban, ahol a hallgatók munkamegszakítás nélkül tanulnak.

A 3 hónap során időszakonként visszajelzéseket gyűjtünk a junioroktól, mentoraiktól és vezetőiktől, és egyénileg igazítjuk a folyamatot. A felpumpált képességeket a teljes időszak során 1-2 alkalommal ellenőrzik, a végén ugyanazt az ellenőrzést végzik el - ezek alapján ajánlásokat fogalmaznak meg, hogy pontosan mit kell fejleszteni.

Következtetés

A cég számára: Megéri befektetni a juniorokba? Igen!

Juniornak: Keressen olyan cégeket, amelyek gondosan választják ki a jelölteket, és tudják, hogyan fejleszthetik őket

3 hónap alatt 122 kérdőívet, 54 tesztfeladatot néztünk át és 21 technikai interjút készítettünk. Ez hozott nekünk 3 nagyszerű juniort, akik mostanra teljesítették a beszállási és gyorsulási ütemtervük felét. Már valós termékfeladatokat hajtanak végre projektünkben, ahol több mint 2 000 000 kódsor és több mint 400 repository található csak a front end-en.

Megtudtuk, hogy a juniorok tölcsére meglehetősen összetett lehet és kell is, de végül csak azok jutnak át rajta, akik valóban készek nagyon keményen dolgozni és befektetni a fejlődésükbe.

Most az a fő feladatunk, hogy minden junior számára három hónapos fejlesztési ütemtervet készítsünk mentorral végzett egyéni munka és általános tanfolyamok formájában, mérőszámokat, visszajelzéseket gyűjtsünk a vezetőktől, mentoroktól és maguktól a srácoktól. Ezen a ponton már az első kísérlet befejezettnek tekinthető, következtetések vonhatók le, a folyamat továbbfejleszthető és újrakezdhető az új jelöltek kiválasztása.

Forrás: will.com