🥇Hur tämjer man en junior?

Hur kommer man in i ett stort företag om man är junior? Hur anställer man en anständig junior om man är ett stort företag? Nedanför snittet kommer jag att berätta vår historia om att anställa nybörjare i användargränssnittet: hur vi arbetade igenom testuppgifter, förberedde oss för att genomföra intervjuer och byggde ett mentorprogram för utveckling och introduktion av nykomlingar, och även varför standardintervjufrågor inte fungerar inte.

Jag försöker tämja Junior

Hallå! Jag heter Pavel, jag gör front-end-arbete i Wrike-teamet. Vi skapar ett system för projektledning och samverkan. Jag har arbetat på webben sedan 2010, arbetat 3 år utomlands, deltagit i flera startups och undervisat i en kurs om webbteknologier på universitetet. På företaget är jag delaktig i utvecklingen av tekniska kurser och Wrike mentorsprogram för juniorer samt direktrekryterar dessa.

Varför funderade vi ens på att anställa juniorer?

Tills nyligen rekryterade vi utvecklare på mellan- eller seniornivå för frontend - tillräckligt oberoende för att utföra produktuppgifter efter onboarding. I början av detta år insåg vi att vi ville ändra denna policy: under året har antalet av våra produktteam nästan fördubblats, antalet frontend-utvecklare har närmat sig hundra, och inom en snar framtid kommer allt detta att måste dubbla igen. Det finns mycket arbete, få fria händer, och det finns ännu färre av dem på marknaden, så vi bestämde oss för att vända oss till killarna som precis har börjat sin resa i frontend och insåg att vi är redo att investera i deras utveckling.

Vem är junior?

Det här är den allra första frågan vi ställde oss själva. Det finns olika kriterier, men den enklaste och mest begripliga principen är denna:

Junior behöver förklaras vilken funktion och hur man gör det. Mitten måste förklaras vilken funktion som behövs, och han kommer själv att räkna ut implementeringen. Undertecknaren kommer själv att förklara för dig varför den här funktionen inte alls behöver göras.

På ett eller annat sätt är en junior en utvecklare som behöver råd om hur man implementerar den eller den lösningen. Vad vi bestämde oss för att bygga vidare på:

Junior är någon som vill utvecklas och är redo att jobba hårt för detta;
Han vet inte alltid åt vilket håll han vill utvecklas;
Behöver råd och söker hjälp utifrån – från sin ledare, mentor eller i samhället.

Vi hade också flera hypoteser:

Det kommer att bli en storm av svar på Junes ståndpunkt. Du måste filtrera slumpmässiga svar när du skickar ditt CV;
Ett primärt filter hjälper inte. — Fler testuppgifter behövs.
Testuppgifter kommer att skrämma bort alla – de behövs inte.

Och naturligtvis hade vi ett mål: 4 juniorer på 3 veckor.

Med denna insikt började vi experimentera. Planen var enkel: börja med så bred tratt som möjligt och försök att gradvis minska den så att du kan bearbeta flödet, men inte minska det till 1 kandidat per vecka.

Vi lägger ut en ledig tjänst

För företaget: Det kommer hundratals svar! Tänk på ett filter.

För junior: Var inte rädd för frågeformuläret innan du skickar ditt CV och testuppgift - detta är ett tecken på att företaget har tagit hand om dig och har lagt upp processen väl.

Den första dagen fick vi cirka 70 CV från kandidater "med kunskap om JavaScript." Och sedan igen. Och vidare. Vi kunde fysiskt inte bjuda in alla till kontoret för en intervju och valde bland dem killarna med de coolaste husdjursprojekten, live Github eller åtminstone erfarenhet.

Men huvudslutsatsen som vi drog för oss själva redan första dagen var att stormen hade börjat. Nu är det dags att lägga till ett frågeformulär innan du skickar in ditt CV. Hennes mål var att rensa bort kandidater som inte var villiga att anstränga sig minsta möjliga för att skicka in ett CV, och de som inte hade kunskapen och sammanhanget för att åtminstone Google de rätta svaren.

Den innehöll standardfrågor om JS, layout, webb, datavetenskap – alla som föreställer sig vad de frågar vid en front-end-intervju känner till dem. Vad är skillnaden mellan let/var/const? Hur kan jag använda stilar endast på skärmar som är mindre än 600 pixlar breda? Vi ville inte ställa dessa frågor vid en teknisk intervju - praktiken har visat att de kan besvaras efter 2-3 intervjuer utan att förstå utvecklingen alls. Men de kunde initialt visa oss om kandidaten i princip förstår sammanhanget.

I varje kategori förberedde vi 3-5 frågor och dag efter dag ändrade vi deras uppsättning i svarsformuläret tills vi eliminerade de mest acceptabelt och de svåraste. Detta gjorde att vi kunde minska flödet - på 3 veckor fick vi 122 kandidater, som vi skulle kunna arbeta vidare med. Dessa var IT-studenter; killar som ville flytta till fronten från backend; arbetare eller ingenjörer, 25-35 år gamla, som radikalt ville byta yrke och lägga olika mycket kraft på egenutbildning, kurser och praktik.

Att lära känna varandra bättre

För företaget: Testuppgiften avskräcker inte kandidater, men hjälper till att förkorta tratten.

För junior: Kopiera och klistra inte in tester - det märks. Och håll ordning på din github!

Om vi kallade alla till en teknisk intervju skulle vi behöva genomföra cirka 40 intervjuer per vecka endast för juniorer och bara på fronten. Därför bestämde vi oss för att testa den andra hypotesen – om testuppgiften.

Vad var viktigt för oss i testet:

Bygg en bra skalbar arkitektur, men utan överteknik;
Det är bättre att ta längre tid, men gör det bra, än att sätta ihop ett hantverk över natten och skicka det med kommentaren "Jag kommer definitivt att avsluta det";
Utvecklingens historia i Git är ingenjörskulturen, iterativ utveckling och det faktum att lösningen inte uppenbart kopierades.

Vi kom överens om att vi ville titta på ett algoritmiskt problem och en liten webbapplikation. Algoritmiska sådana förbereddes på nivå med laboratorier på elementär nivå - binär sökning, sortering, sökning efter anagram, arbete med listor och träd. Till slut bestämde vi oss för binär sökning som ett första provalternativ. Webbapplikationen var tvungen att använda vilken ram som helst (eller utan den).

Nästan hälften av de återstående killarna genomförde testuppgiften – de skickade lösningarna till oss 54 kandidater. Otrolig insikt - hur många implementeringar av tic-tac-toe, redo för copy-paste, tror du att det finns på Internet?

Сколько?Det verkar faktiskt som att det bara finns 3. Och i de allra flesta beslut fanns det just dessa 3 alternativ.
Vad gillade inte:

copy-paste eller utveckling baserat på samma handledning utan din egen arkitektur;
båda uppgifterna finns i samma arkiv i olika mappar, naturligtvis finns det ingen commit-historik;
smutsig kod, DRY-överträdelse, brist på formatering;
en blandning av modell, vy och styrenhet i en klass hundratals rader kod lång;
bristande förståelse för enhetstestning;
en "head-on"-lösning är en hårdkod av en 3x3-matris av vinnande kombinationer, som till exempel kommer att vara ganska svår att utöka till 10x10.

Vi ägnade också uppmärksamhet åt närliggande förvar - coola husdjursprojekt var ett plus, och en massa testuppgifter från andra företag var mer av en väckarklocka: varför kunde inte kandidaten komma dit?

Som ett resultat hittade vi coola alternativ i React, Angular, Vanilla JS - det fanns 29. Och vi bestämde oss för att bjuda in ytterligare en kandidat utan att testa för hans väldigt coola husdjursprojekt. Vår hypotes om fördelarna med testuppgifter bekräftades.

Teknisk intervju

För företaget: Det är inte medel/seniorer som har kommit till dig! Vi behöver ett mer individuellt förhållningssätt.

För junior: Kom ihåg att detta inte är en tenta - försök inte tiga för ett C eller bombardera professorn med en ström av alla dina möjliga kunskaper så att han blir förvirrad och ger ett "utmärkt".

Vad vill vi förstå i en teknisk intervju? En enkel sak – hur kandidaten tänker. Han har förmodligen en del hårda färdigheter om han har klarat de första stegen i urvalet - det återstår att se om han vet hur man använder dem. Vi kom överens om 3 uppgifter.

Den första handlar om algoritmer och datastrukturer. Med en penna, på ett papper, på pseudospråk och med hjälp av ritningar, kom vi på hur man kopierar ett träd eller hur man tar bort ett element från en enkellänkad lista. Den obehagliga upptäckten var att inte alla förstår rekursion och hur referenser fungerar.

Den andra är livekodning. Vi gick till codewars.com, valde enkla saker som att sortera en rad ord efter den sista bokstaven och i 30-40 minuter försökte tillsammans med kandidaten få alla prov att bli godkända. Det verkade som att det inte borde komma några överraskningar från killarna som bemästrat tic-tac-toe – men i praktiken var det inte alla som kunde inse att värdet borde lagras i en variabel, och funktionen skulle returnera något via retur. Även om jag verkligen hoppas att det var ett darr, och killarna kunde hantera dessa uppgifter under lättare förhållanden.

Slutligen handlar den tredje lite om arkitektur. Vi diskuterade hur man gör ett sökfält, hur debounce fungerar, hur man renderar olika widgets i söktips, hur frontend kan interagera med backend. Det fanns många intressanta lösningar, inklusive rendering på serversidan och webbsockets.

Vi genomförde 21 intervjuer med denna design. Publiken var helt olika - låt oss titta på serier:

"Raket". Han lugnar sig aldrig, engagerar sig i allt och under en intervju kommer han att överväldiga dig med en ström av tankar som inte ens är direkt relaterade till frågan som ställs. Om det var på ett universitet skulle detta vara ett välbekant försök att visa, ja, all din kunskap, när allt du kommer ihåg om biljetten du stötte på är att du i går kväll bestämde dig för att inte studera den - du kan fortfarande inte få det ut.
"Groot". Det är ganska svårt att komma i kontakt med honom eftersom han är Groot. Under en intervju måste du lägga lång tid på att försöka få svar ord för ord. Det är bra om det bara är en dvala - annars blir det väldigt svårt för dig i ditt dagliga arbete.
"Drax". Jag arbetade tidigare med godstransport och programmeringsmässigt lärde jag mig bara JS på Stackoverflow, så jag förstår inte alltid vad som diskuteras på en intervju. Samtidigt är han en bra person, har de bästa avsikterna och vill bli en fantastisk front-end-utvecklare.
Tja, förmodligen "Star Lord". Sammantaget en bra kandidat som du kan förhandla och bygga en dialog med.

I slutet av vår forskning 7 kandidater nådde finalen och bekräftade sina hårda färdigheter med en stor testuppgift och bra svar på intervjun.

Kulturell passform

För företaget: Du jobbar med honom! Är kandidaten villig att arbeta extremt hårt för sin utveckling? Kommer han verkligen att passa in i laget?

För junior: Du jobbar med dem! Är företaget verkligen redo att investera i tillväxten av juniorer, eller kommer det helt enkelt att dumpa allt smutsigt arbete på dig för en låg lön?

Varje junior, förutom produktteamet, vars ledare måste gå med på att ta honom, får en mentor. Mentorns uppgift är att vägleda honom genom en tre månader lång process med introduktion och uppgradering av hårda färdigheter. Därför kom vi till varje kulturell passform som mentorer och svarade på frågan: "Kommer jag att ta ansvar för att utveckla en kandidat inom 3 månader enligt vår plan?"

Detta skede passerade utan några speciella egenskaper och förde oss till slut 4 erbjudanden3 av vilka antogs, och killarna kom in i lagen.

Livet efter erbjudandet

För företaget: Ta hand om dina juniorer eller andra!

För junior: AAAAAAAAAAAA!!!

När en ny medarbetare kommer ut behöver han onboardas – uppdateras med processerna, berättas om hur allt fungerar i företaget och i teamet och hur han ska arbeta i stort. När en junior kommer ut måste du förstå hur du ska utveckla honom.

När vi tänkte efter kom vi fram till en lista med 26 färdigheter som enligt vår mening en junior borde ha i slutet av den tre månader långa introduktionsperioden. Detta inkluderade hårda färdigheter (enligt vår stack), kunskap om våra processer, Scrum, infrastruktur och projektarkitektur. Vi kombinerade dem till en färdplan, fördelad över 3 månader.

Till exempel, här är färdplanen för min junior

Vi tilldelar en mentor till varje junior som arbetar med honom individuellt. Beroende på mentor och aktuell nivå på kandidaten kan möten äga rum från 1 till 5 gånger i veckan under 1 timme. Mentorer är frivilliga frontend-utvecklare som vill göra något mer än att bara skriva kod.

En del av bördan för mentorer tas bort av kurser på vår stack - Dart, Angular. Kurser hålls regelbundet för små grupper om 4-6 personer, där studenter studerar utan avbrott från arbetet.

Under loppet av 3 månader samlar vi med jämna mellanrum in feedback från juniorer, deras mentorer och leads och anpassar processen individuellt. De upppumpade färdigheterna kontrolleras 1-2 gånger under hela perioden, samma kontroll utförs i slutet - utifrån dem bildas rekommendationer om vad som exakt behöver förbättras.

Slutsats

För företaget: Är det värt att satsa på juniorer? Ja!

För junior: Leta efter företag som noggrant väljer ut kandidater och vet hur man utvecklar dem

Under 3 månader har vi granskat 122 frågeformulär, 54 testuppgifter och genomfört 21 tekniska intervjuer. Detta gav oss 3 fantastiska juniorer som nu har slutfört hälften av sina onboarding- och accelerationsplaner. De slutför redan riktiga produktuppgifter i vårt projekt, där det finns mer än 2 000 000 rader kod och mer än 400 repositories enbart på frontend.

Vi fick reda på att tratten för juniorer kan och borde vara ganska komplex, men i slutändan är det bara de killar som verkligen är redo att jobba väldigt hårt och investera i sin utveckling som passerar den.

Nu är vår huvuduppgift att färdigställa tre månader långa utvecklingsfärdplaner för varje junior i läget individuellt arbete med mentor och allmänna kurser, samla in mätetal, feedback från leads, mentorer och killarna själva. Vid denna tidpunkt kan det första experimentet anses avslutat, slutsatser kan dras, processen kan förbättras och den kan startas om för att välja ut nya kandidater.

Källa: will.com

Hur tämjer man en junior?