Hogyan szelídítsünk meg egy junior fejlesztőt?

Hogyan juthat el egy nagyobb céghez, ha te egy junior vagy? Hogyan lehet egy megfelelő junior fejlesztőt felvenni, ha te egy nagy cég vagy? A cikkben elmesélem a kezdő fejlesztők felvételének történetét a frontend csapatunkban: arról, hogyan dolgoztuk ki a tesztfeladatokat, hogyan készülünk az interjúkra, és hogyan alakítottuk ki a mentorprogramot a kezdők fejlődéséhez és beilleszkedéséhez, valamint arról, miért nem működnek a hagyományos interjúkérdések.

Hogyan szelídítsünk meg egy junior fejlesztőt?
Próbálom megnevelni a junior fejlesztőt.

Helló! A nevem Pavel, frontend fejlesztőként dolgozom a Wrike csapatában. Projektmenedzsment és együttműködési rendszert fejlesztünk. 2010 óta foglalkozom webfejlesztéssel, 3 évet dolgoztam külföldi távmunkásként, részt vettem néhány startupban, és webtechnológiákból tanítottam kurzust egyetemen. A cégnél részt veszek a Wrike technikai kurzusainak és a junioroknak szóló mentorprogram fejlesztésében, valamint közvetlenül a juniorok felvételében.

Miért gondoltunk egyáltalán juniorok felvételére?

Eddig frontend fejlesztőket kerestünk middle vagy senior szinten — elég önállóakat, akik a beilleszkedést követően képesek produktív feladatokat végezni. Az év elején rájöttünk, hogy szeretnénk megváltoztatni ezt a politikát: egy év alatt a termékcsapataink száma majdnem megduplázódott, a frontend fejlesztők száma elérte a százat, és a közeljövőben ezt ismét meg kell dupláznunk. Sok munka van, kevesen állnak rendelkezésre, a piacon pedig még kevesebben, ezért úgy döntöttünk, hogy foglalkozunk azokkal, akik éppen most kezdik el a frontend karrierjüket, és tisztában vagyunk vele, hogy hajlandók vagyunk befektetni a fejlődésükbe.

Ki az a junior?

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

A junior fejlesztőnek el kell magyarázni, hogy milyen funkciót és hogyan kell megvalósítani. A middle fejlesztőnek el kell mondani, hogy milyen funkcióra van szükség, és ő magától is tudni fogja, hogyan kell megvalósítani. A senior fejlesztő pedig önállóan megmondja, hogy miért nem érdemes az adott funkciót megvalósítani.

Így vagy úgy, a junior az a fejlesztő, akinek szüksége van tanácsra, hogy pontosan hogyan kell megvalósítani egy adott megoldást. Amit figyelembe vettünk:

  1. A junior az, aki fejlődni akar, és készen áll arra, hogy ezért keményen dolgozzon;
  2. Nem mindig tudja, hogy pontosan melyik irányba szeretne fejlődni;
  3. Tanácsra van szüksége, és külső segítséget keres — a vezetőjétől, mentoraiktól vagy a közösségtől.

További hipotéziseink is voltak:

  1. Az junior pozícióra özönleni fognak a jelentkezők.A véletlenszerű jelentkezéseket már a önéletrajzok benyújtásának szakaszában szűrni kell;
  2. Az első szűrő nem lesz elegendő. — még tesztfeladatok is szükségesek;
  3. A tesztfeladatok mindenkit elriasztanak. — ezek nem szükségesek.

Természetesen célunk is volt: 4 junior 3 hét alatt..

Ezzel az tudatossággal kezdtünk kísérletezni. A terv egyszerű volt: széles egyenest indítani, és fokozatosan szűkíteni, hogy elbírjuk a beérkező jelentkezéseket, de ne csökkentsük azt egy főre hetente.

Hirdessük meg a pozíciót.

A vállalat számára: Százával fognak érkezni a jelentkezések! Gondoljon a szűrőre.

A junior pozícióhoz: Ne féljen a kérdőív kitöltésétől az önéletrajz benyújtása előtt és a tesztfeladattól — ez azt jelzi, hogy a vállalat törődik Önnel, és jól beállította a folyamatot.

Az első napon körülbelül 70 önéletrajz érkezett a 'JavaScriptet ismerő' jelöltektől. Aztán még több. Fizikailag nem tudtuk mindet behívni interjúra az irodába, így a legjobb pet-projektjeik, aktív GitHub profiljuk, vagy legalább némi tapasztalat alapján választottuk ki őket.

De a legfontosabb következtetés, amit az első napunkon levontunk — elkezdődött a vihar. Itt az ideje, hogy kérdőívet adjunk a önéletrajzok benyújtása előtt. Ennek az volt a célja, hogy kiszűrje azokat a jelölteket, akik nem hajlandók minimális erőfeszítést tenni az önéletrajz megküldésére, és azokat, akik nem rendelkeznek a tudással és a kontextussal, legalább annyira, hogy meg tudják találni a helyes válaszokat a Google-on.

A kérdések között alapvető témák voltak a JS-ről, a webfejlesztésről, az informatikáról — ezeket mindenki tudja, aki tudja, hogy mit kérdeznek a frontend interjún. Mi a különbség a let/var/const között? Hogyan lehet alkalmazni a stílusokat csak a 600px-nél kisebb képernyőkhöz? Nem akartuk ezeket a kérdéseket technikai interjún feltenni — a gyakorlat azt mutatta, hogy ezekre a válaszok a 2-3 interjú után is adhatóak, anélkül, hogy értenénk a fejlesztéshez. De ezek elsődlegesen meg tudták mutatni, hogy a jelölt általában érti-e a kontextust.

Minden kategóriában 3-5 kérdést készítettünk elő, és napról napra változtattuk azok kombinációját a válaszformanyomtatványban, amíg ki nem szűrtük a legegyszerűbb és legnehezebb kérdéseket. Ez lehetővé tette a beérkező jelentkezések csökkentését — 3 hét alatt összesen 122 jelöltet kaptunk., akikkel tovább lehetett dolgozni. IT hallgatók voltak; srácok, akik át akartak lépni a backendről a frontend világába; 25-35 éves dolgozók vagy mérnökök, akik radikálisan át akarták alakítani a szakmájukat, és különböző mennyiségű energiát fektettek az önképzésbe, tanfolyamokba és gyakornokságokba.

Ismerkedjünk meg közelebbről

A vállalat számára: A tesztfeladat nem riasztja el a jelölteket, de segít csökkenteni a kiválasztási folyamat hosszát.

A junior pozícióhoz: Ne másoljátok a tesztfeladatokat — ez észrevehető. És tartsátok rendben a GitHub-otokat!

Ha mindenkit meghívnánk a műszaki interjúkra, körülbelül heti 40 interjút kellene lebonyolítanunk csak junioroknak és csak a frontend területén. Ezért úgy döntöttünk, hogy teszteljük a második hipózist — a tesztfeladatot.

Mi volt számunkra fontos a tesztfeladatban:

  1. Jó, skálázható architektúra felépítése, de túlmérnökölés nélkül;
  2. Jobb hosszabb ideig dolgozni, de jól csinálni, mint egy éjszaka alatt összecsapni valamit, és elküldeni a megjegyzéssel: „feltétlenül befejezem”;
  3. A Git története — mérnöki kultúra, a fejlesztés iterativitása, és hogy a megoldás nem volt egyértelműen lemásolva.

Megállapodtunk abban, hogy szeretnénk látni egy algoritmusos feladatot és egy kis webalkalmazást. Az algoritmusos feladatokat az első éves laboratóriumi szintre készítették elő — 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 első mintavariánsként. A webalkalmazásnak a klasszikus körömrágó játéknak kellett lennie, bármilyen keretrendszer használatával (vagy anélkül).

A tesztfeladatot az itt maradt srácok közel fele megoldotta — 54 jelölt megoldását kaptuk. Hihetetlen betekintés — szerintetek hány megvalósítás található a körömrágó játékból, amely készen áll a másolásra az interneten?Hány?

Valójában úgy tűnik, hogy csak 3. A megoldások túlnyomó többségében valóban ezek a 3 változat szerepelt.másolás, vagy a ugyanazon oktatóanyag alapján történő fejlesztés, saját architektúra nélkül;
Ami nem tetszett:

  • két feladat egy repóban külön mappákban, a commit történet természetesen nincs;
  • piszkos kód, a DRY megsértése, formázás hiánya;
  • modell, nézet és vezérlő keverése egy 100 soros kódosztályban;
  • egységtesztelés megértésének hiánya;
  • a unit testing megértésének hiánya;
  • a megoldás "frontálisan" - a nyerő kombinációk 3x3-as mátrixának hardkódolása, ami elég nehézkes lenne a 10x10-es bővítéshez, például.

Ezenkívül figyeltünk a szomszédos repozitóriumokra - a menő pet projektek pozitívan zárultak, míg más cégek tesztfeladatainak halmaza inkább arra utalt, hogy miért nem tudta a jelölt teljesíteni azokat?

Végül klassz lehetőségeket találtunk React, Angular, Vanilla JS terén - ezekből összesen 29-et gyűjtöttünk össze. Sőt, egy másik jelöltet döntöttünk úgy, hogy teszt nélkül hívunk be a nagyon szuper pet projektjei miatt. A tesztfeladatok hasznosságáról alkotott hipotézisenk bevált.

Technikai interjú

A vállalat számára: Nem középkategóriás vagy szenior jelöltek jöttek hozzád! Több egyéni megközelítés szükséges.

A junior pozícióhoz: Ne feledd, hogy ez nem vizsga - ne próbálj meg csendben lenni, hogy a hármasra megúszd, vagy zúdítsd a professzorra minden tudásodat, hogy összezavarodjon és "kitűnő" eredményt adjon.

Mit akarunk megérteni a technikai interjú során? Egy egyszerű dolgot - hogyan gondolkodik a jelölt. Valószínűleg rendelkezik bizonyos hard skillekkel, ha átlépte az első kiválasztási lépéseket - csak azt kell kiderítenünk, hogy tudja-e alkalmazni őket. Három feladatban állapodtunk meg.

Az első - algoritmusok és adatszerkezetek. Papíron, ceruzával, pszeudnyelven és rajzok segítségével azt elemeztük, hogyan lehet lemásolni egy fát vagy hogyan lehet eltávolítani egy elemet az egyszeresen láncolt listából. Csalódást keltett, hogy nem mindenki értette a rekurziót és azt, hogy működnek a hivatkozások.

A második - élő kódolás. Beléptünk a codewars.com, egyszerű dolgokat választottunk, például egy szóhalmaz utolsó betű szerinti rendezését, és 30-40 perc alatt megpróbáltuk a jelölttel együtt végigvinni az összes tesztet. Úgy tűnt, nem lehetnek meglepetések a srácoktól, akik átmentek a tic-tac-toe-on - de a gyakorlatban nem mindenki tudta felfogni, hogy az értéket egy változóban kell tárolni, és a funkciónak vissza kell térnie valamit a return segítségével. Remélem, hogy ez csak izgulás volt, és a srácok meg tudták oldani ezeket a feladatokat könnyebb körülmények között.

Végül a harmadik - kicsit az architektúrával. Megbeszéltük, hogyan lehet keresősávot készíteni, hogyan működik a debounce, hogyan lehet különböző widgeteket renderelni a keresési javaslatokban, hogyan tud a frontend interakcióba lépni a backend-del. Számos érdekes megoldást találtunk, beleértve a server-side renderelést és a webszervereket.

21 interjút végeztünk ebben a formátumban. A közönség teljesen vegyes volt — nézzük a képregényekkel:

  1. „Rakéta”. Soha nem nyugszik, mindenhová beleavatkozik, és az interjún eláraszt majd egy gondolatáradattal, amely közvetlenül még a feltett kérdéshez sem kapcsolódik. Ha az egyetemről lenne szó, ez sokak számára ismerős próbálkozás lenne, hogy minden tudását bemutassa, amikor csak annyira emlékszik a neki kisorsolt tételre, hogy tegnap este úgy döntött, nem tanulja meg — úgysem húzzák ki.
  2. „Groott”. Nehéz vele kapcsolatba lépni, mert ő Groot. Az interjún elég sokáig tart, amíg a válaszokat szó szerint elő tudjuk halászni. Jó, ha csak megakadt, mert különben a mindennapi munkában nagyon nehéz dolgunk lesz.
  3. „Drax”. Korábban áruszállítással foglalkozott, és programozásból csak JS-t tanult a Stackoverflow-n, ezért nem mindig érti, miről van szó az interjún. Közben jó ember, a legjobb szándékai vannak, és nagyszerű frontend fejlesztővé szeretne válni.
  4. Nos, valószínűleg „Csillagfiú”. Összességében nem rossz jelölt, akivel lehet tárgyalni és párbeszédet kialakítani.

A kutatásaink végére 7 jelölt a döntőbe jutott, megerősítve hard skilleiket egy klassz tesztfeladaton és jó válaszokkal az interjún.

Kulturális illeszkedés

A vállalat számára: Önnel kell dolgoznia! Készen áll a jelölt arra, hogy rendkívül sokat dolgozzon a fejlődése érdekében? Illeszkedik a csapatba?

A junior pozícióhoz: Önnel kell dolgozniuk! Készen áll a cég arra, hogy befektessen a juniorok fejlődésébe, vagy csak rátolják az összes piszkos munkát alacsony fizetésért?

Minden junior a termékcsapat mellett, akinek a vezetője beleegyezett, hogy felvegye, kap egy mentort. A mentori feladat az, hogy végigvezesse három hónapos onboarding folyamaton és a hard skillek fejlesztésén. Ezért minden kulturális illeszkedés alkalmával mentorként jöttünk és azon gondolkodtunk: „Vállalni fogom a felelősséget, hogy 3 hónap alatt felkészítsem a jelöltet a tervünk szerint?”

Ez a szakasz különösebb események nélkül zajlott, és végül összesen 4 ajánlatot, ebből 3-t elfogadtak, és a srácok csapatba kerültek.

Az ajánlat utáni élet

A vállalat számára: Vigyázzon a juniorjaira, vagy ezt mások megteszik helyette!

A junior pozícióhoz: AAAA!!!

Amikor új munkatárs érkezik, be kell őt avatni – tájékoztatni kell a folyamatokról, elmondani, hogyan működik a cég és a csapat, valamint hogyan végezheti a munkáját. Amikor egy junior munkatárs érkezik, meg kell érteni, hogyan tudjuk fejleszteni őt.

Amikor ezt átgondoltuk, összeállítottunk egy listát 26 készségről, amelyeket a véleményünk szerint a juniornak el kell sajátítania a három hónapos onboard folyamat végére. Ezek közé tartoznak a hard skillek (a mi technológiai stackünkben), ismeretek a folyamatainkról, Scrumról, az infrastruktúráról és a projekt architektúrájáról. Összeállítottuk őket egy ütemtervbe, amely három hónapra van ütemezve.

Hogyan szelídítsünk meg egy junior fejlesztőt?

Például, itt van a juniorom ütemterve.

Minden juniorhoz mentort rendelünk, aki egyéni megközelítéssel dolgozik vele. A mentorok és a jelölt aktuális szintje függvényében a találkozók hetente 1-5 alkalommal, 1 órás időtartamban zajlanak. A mentorok önként jelentkeznek, rendszerint kezdeményező frontend fejlesztők, akik többre vágynak, mint egyszerűen kódot írni.

A mentorok terheit egyes kurzusok enyhítik a mi stackünkről – Dart, Angular. Ezeket a kurzusokat rendszeresen tartják kicsi, 4-6 fős csoportok számára, ahol a fiatalok dolgozhatnak a munka mellett.

A három hónap során időszakonként visszajelzést gyűjtünk a júnioroktól, mentoraiktól és a csapatvezetőktől, és egyénre szabottan módosítjuk a folyamatot. A teljes időszak alatt 1-2 alkalommal végzünk készségellenőrzést, amely a végén is megtörténik – ezek alapján ajánlásokat fogalmazunk meg arra vonatkozóan, hogy mit érdemes még fejleszteni.

Zárás

A vállalat számára: Érdemes-e befektetni a júniorokba? Igen!

A junior pozícióhoz: Keressen olyan cégeket, amelyek alaposan válogatják meg a jelölteket, és tudják, hogyan tudják őket fejleszteni.

Három hónap alatt 122 kérdőívet néztünk át, 54 tesztfeladatot és 21 technikai interjút tartottunk. Ez 3 nagyszerű junior munkatársat hozott, akik mostanra a onboarding és akcelerációs ütemtervük felénél tartanak. Már valós termékfeladatokat zárnak le a projektünkben, ahol csak a frontendben több mint 2 000 000 sor kód található, és több mint 400 repozitórium van.

Kiderült, hogy a júniorok számára a toborzási folyamat elég összetett lehet és kell is, de végül csak azok jutnak át rajta, akik valóban készen állnak arra, hogy sokat dolgozzanak és befektessenek a fejlődésükbe.

Jelenleg a legfőbb feladatunk, hogy befejezzük a három hónapos fejlesztési ütemterveket minden junior számára mentorral való egyéni munkavégzés keretében és közös tanfolyamokon, összegyűjtsük a metrikákat, a vezetők, mentoraik és maguk a fiatalok visszajelzéseit. Ezen a ponton az első kísérletet befejezettnek tekinthetjük, következtetéseket vonhatunk le, javíthatjuk a folyamatot, és újraindíthatjuk azt új jelöltek kiválasztására.

Forrás: habr.com

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster