Hvordan temme junioren?

Hvordan kan man komme inn i et stort selskap som junior? Hvordan ansette en dyktig junior hvis du er et stort selskap? Under her vil jeg dele vår historie om ansettelse av nybegynnere innen frontend: hvordan vi utarbeidet testoppgaver, forberedte oss til intervjuer og bygde et mentorprogram for utvikling og onboarding av nykommere, samt hvorfor standard spørsmål for intervjuer ikke fungerer.

Jeg prøver å temme en junior

Hei! Jeg heter Pavel, og jeg jobber med frontend i laget vårt hos Wrike. Vi lager et system for prosjektledelse og samarbeid. Jeg har jobbet med web siden 2010, jobbet i tre år på internasjonal fjernarbeid, deltatt i flere oppstarter og undervist i webteknologier på universitetet. I selskapet bidrar jeg til utviklingen av tekniske kurs og mentorprogrammet til Wrike for juniorer, samt rekrutteringen av dem.

Hvorfor begynte vi å vurdere ansettelse av juniorer

Inntil nylig rekrutterte vi frontend-utviklere på mid-level eller senior nivå — tilstrekkelig selvstendige til å håndtere produktoppgaver etter onboarding. Tidligere i år innså vi at vi ønsket å endre denne politikken: i løpet av året har antallet våre produktteam nesten doblet seg, antallet frontend-utviklere har nærmet seg hundre, og i nær fremtid skal alt dette dobles igjen. Det er mye arbeid, få hender tilgjengelig, og på markedet er de enda færre, så vi bestemte oss for å henvende oss til folk som nettopp har begynt sin ferd innen frontend og innså at vi var villige til å investere i deres utvikling.

Hva er en junior?

Dette var det første spørsmålet vi stilte oss selv. Det finnes ulike kriterier, men det enkleste og mest forståelige prinsippet er:

En junior trenger å få forklart hvilken funksjonalitet og hvordan den skal lages. En mid-level utvikler trenger å forstå hvilken funksjonalitet som kreves, og så finner han selv ut hvordan det skal implementeres. En senior vil selv forklare deg hvorfor denne funksjonaliteten ikke skal lages i det hele tatt.

Uansett, en junior er den utvikleren som trenger råd om hvordan man skal implementere ulike løsninger. Som vi besluttet å basere oss på:

1. En junior er en som ønsker å utvikle seg og er villig til å jobbe hardt for det;
2. Han vet ikke alltid hvilken retning han vil utvikle seg i;
3. Han trenger råd og søker hjelp utenfra — fra sin leder, mentor eller i fellesskapet.

I tillegg hadde vi flere hypoteser:

1. Det vil komme en storm av søknader til juniorstillingen. Vi må filtrere tilfeldige svar allerede på tidspunktet for innsending av CV;
2. Den første filtreringen vil ikke hjelpe — vi trenger flere testoppgaver;
3. Testoppgavene vil skremme bort alle — de er ikke nødvendige.

Og selvsagt hadde vi et mål: 4 juniorer på 3 uker.

Med denne forståelsen begynte vi å eksperimentere. Planen var enkel: starte med en så bred trakt som mulig og gradvis snevre den inn, slik at vi rakk å bearbeide strømmen, men ikke redusere den til 1 kandidat i uken.

Vi annonserer stillingen

For selskapet: Det vil komme hundrevis av søknader! Tenk på filtreringen.

For junioren: Ikke vær redd for spørreskjemaet før du sender CV og testoppgave — det er et tegn på at selskapet bryr seg om deg og har godt tilrettelagt prosessen.

På den første dagen fikk vi omtrent 70 CV-er fra kandidater «med kunnskap om JavaScript». Og så kom det flere. Vi hadde fysisk ikke mulighet til å kalle inn alle til intervju på kontoret, så vi valgte folk med de mest imponerende pet-prosjektene, aktiv GitHub eller ihvertfall erfaring.

Men den viktigste konklusjonen vi kom til den første dagen — stormen hadde begynt. Det var på tide å legge til et spørreskjema før innsending av CV. Målsetningen var å sile ut kandidater som ikke var villige til å legge ned minimum innsats for å sende inn CV, og de som ikke hadde kunnskapen og konteksten til å google de riktige svarene.

Det inneholdt standardspørsmål om JS, nettside-design, web, datavitenskap — disse kan alle som har en viss forståelse av hva som blir spurt om i frontend-intervjuer. Hva er forskjellen mellom let/var/const? Hvordan anvende stiler bare for skjermer som er mindre enn 600px i bredde? Vi ønsket ikke å stille disse spørsmålene på det tekniske intervjuet — erfaringen viste at man kunne svare på dem etter 2-3 intervjuer uten å ha noen som helst forståelse for utvikling. Men de kunne likevel gi oss en tidlig indikasjon på om kandidaten forstod konteksten.

I hver kategori forberedte vi 3-5 spørsmål og endret dag for dag settet med spørsmål i svarskjemaet, til vi hadde utelukket de mest trivielle og de mest krevende. Dette gjorde at vi kunne redusere strømmen — på 3 uker fikk vi 122 kandidater, som man kunne jobbe videre med. Dette var IT-studenter; folk som ønsket å gå fra backend til frontend; arbeidere eller ingeniører i alderen 25-35 år, som ønsket en radikal karriereskifte og som hadde lagt inn ulike mengder arbeid i selvstudier, kurs og praksisplasser.

Bli bedre kjent

For selskapet: Testoppgaven skremmer ikke kandidatene, men hjelper til med å kutte ned på utvelgelsesprosessen.

For junioren: Ikke kopier testoppgavene — det merkes. Og hold GitHub-profilen din ryddig!

Hvis vi hadde invitert alle til teknisk intervju, måtte vi ha gjennomført omtrent 40 intervjuer i uken bare for juniorer og kun for frontend. Derfor bestemte vi oss for å teste den andre hypotesen — om testoppgaven.

Hva som var viktig for oss med testen:

1. Bygge en god, skalerbar arkitektur, men uten overengineering;
2. Det er bedre å ta seg tid til å gjøre det bra, enn å smelle sammen noe på en natt og sende det med kommentaren «jeg skal absolutt fullføre dette»;
3. Historikken om utviklingen på Git – ingeniørkultur, iterativ utvikling, og at løsningen ikke er plagiat for å si det mildt.

Vi ble enige om at vi ønsket å se en algoritmisk oppgave samt en liten web-applikasjon. Algoritmene var designet på nivå med laboratorieoppgaver fra tidlige kurs — binærsøk, sortering, anagram-sjekking, arbeid med lister og trær. Til slutt bestemte vi oss for binærsøk som den første testoppgaven. Web-applikasjonen skulle bli kryss og nøtter ved bruk av valgfritt rammeverk (eller uten).

Testoppgaven ble løst av nesten halvparten av de resterende kandidatene — vi mottok løsninger fra 54 kandidater. Utrolig innsikt — hvor mange implementeringer av kryss og nøtter, klare til kopiering, tror du finnes på nettet?

Hvor mange?Faktisk ser det ut til at det bare er 3. Og i det overveldende flertallet av løsningene var det nettopp disse 3 alternativene.
Hva likte vi ikke:

• Kopiering, eller utvikling basert på samme tutorial uten egen arkitektur;
• Begge oppgavene i ett repositorium i forskjellige mapper, men det finnes selvfølgelig ingen commits-historikk;
• Rotete kode, brudd på DRY-prinsippet, mangel på formatering;
• Blanding av modell, visning og kontroller i en klasse som er hundrevis av linjer lang;
• Mangel på forståelse av enhetstesting;
• løsning «rett på sak» — hardkoding av vinnerkombinasjoner 3x3, noe som vil være ganske vanskelig å utvide til 10x10, for eksempel.

Vi la også merke til naborepositorier — flotte pet-prosjekter gikk i pluss, men mange testoppgaver fra andre selskaper var mer et tegn på: hvorfor klarte ikke kandidaten å komme seg videre der?

Til slutt fant vi flotte kandidater på React, Angular, Vanilla JS — vi samlet opp 29. Og en annen kandidat bestemte vi oss for å invitere uten test basert på sine veldig imponerende pet-prosjekter. Hypotesen vår om nytten av testoppgaver ble bekreftet.

Teknisk intervju

For selskapet: De som kommer til deg er ikke midler/seniore! Det kreves mer individuell tilnærming.

For junioren: Husk at dette ikke er en eksamen — prøv ikke å bare holde deg til et trepoengs svar eller overvelde professoren med all din mulige kunnskap, slik at han blir forvirret og gir deg "utmerket".

Hva ønsker vi å forstå i det tekniske intervjuet? En enkel ting — hvordan kandidaten tenker. Han har sikkert noen hard skills hvis han har kommet seg gjennom de første utvelgelsene — nå gjenstår det å finne ut om han kan bruke dem. Vi ble enige om 3 oppgaver.

Første — om algoritmer og datastrukturer. Med penn og papir, på pseudokode og med tegninger, diskuterte vi hvordan man kan kopiere et tre eller hvordan man kan fjerne et element fra en enkelt lenket liste. En ubehagelig oppdagelse var at ikke alle forsto rekursjon og hvordan referanser fungerer.

Andre — live coding. Vi gikk inn på codewars.com, valgte enkle oppgaver som sortering av et array av ord etter den siste bokstaven og i løpet av 30-40 minutter forsøkte vi sammen med kandidaten å få alle tester til å gå igjennom. Det virket ikke som det skulle være noen overraskelser fra folk som mestret kryss og prikk — men i praksis klarte ikke alle å innse at verdien måtte lagres i en variabel, og at funksjonen måtte returnere noe via return. Jeg håper virkelig at dette var nervøsitet, og at de klarte å håndtere disse oppgavene under mer avslappede forhold.

Til slutt, tredje — litt om arkitektur. Vi diskuterte hvordan man kan lage en søkefelt, hvordan debounce fungerer, hvordan man kan rendre forskjellige widgets i søkeforslagene, og hvordan front-end kan interagere med back-end. Det ble funnet mange interessante løsninger, inkludert om server-side rendering og websockets.

Vi har gjennomført 21 intervjuer etter denne modellen. Publikum var helt variert – la oss bruke tegneserier som eksempel:

1. «Raket». Han roer seg aldri, blander seg inn overalt, og under intervjuene overvelder han deg med tankestrømmen sin, som sjelden henger sammen med det spørsmålet som stilles. Hvis det hadde vært i en universitetssetting, ville dette vært en velkjent måte å demonstrere alle kunnskapene sine på, når man bare husker at man i går kveld bestemte seg for ikke å lære seg om det — det hjelper lite.
2. «Groot». Det er vanskelig å få kontakt, fordi han er Groot. Under intervjuene må man ofte bruke tid på å dra ut svarene hans ord for ord. Det er greit hvis det bare er en dundrende blokkering – ellers vil det bli veldig vanskelig i det daglige arbeidet.
3. «Drax». Han har tidligere jobbet med frakt, og har bare lært programmering gjennom JS på Stackoverflow, så han forstår ikke alltid hva samtalen egentlig dreier seg om under intervjuet. Men han er en god person, har de beste intensjoner, og vil bli en flott frontend-utvikler.
4. Og kanskje, «Starlord». Generelt en god kandidat, som man kan forhandle med og føre en dialog.

Mot slutten av undersøkelsene våre 7 kandidater kom til finalen, og bekreftet sine hard skills med et flott testprosjekt og gode svar i intervjuene.

Kulturell tilpasning

For selskapet: Det er deg de skal jobbe med! Er kandidaten virkelig klar for å jobbe ekstremt mye for egen utvikling? Vil han passe inn i teamet?

For junioren: Det er dere de skal jobbe med! Er selskapet virkelig klare til å investere i veksten av juniorene, eller vil de bare kaste alt skittent arbeid over på dere for en lav lønn?

Hver junior, i tillegg til produktteamet, hvis leder må godta å ta dem inn, får en mentor. Mentorens oppgave er å guide gjennom en tre måneders onboarding-prosess og utvikling av hard skills. Derfor møtte vi opp til hver kulturell tilpasning som mentorer og stilte oss selv spørsmålet: «Vil jeg ta ansvar for å utvikle kandidaten i løpet av 3 måneder etter planen vår?»

Denne fasen gikk uten spesielle forhold, og resulterte til slutt i 4 tilbud, hvorav 3 ble akseptert, og gutta ble en del av teamene.

Livet etter tilbudet

For selskapet: Ta vare på juniorene deres, eller så vil andre gjøre det!

For junioren: AAAAAAAAAAA!!!

Når en ny medarbeider begynner, må vedkommende onboardes – introduceres til prosessene, få vite hvordan alt fungerer i selskapet og teamet, og hvordan de generelt skal jobbe. Når en junior begynner, er det viktig å forstå hvordan vi kan utvikle vedkommende.

Når vi tenkte på dette, laget vi en liste med 26 ferdigheter som vi mener en junior bør ha når onboarding-perioden på tre måneder er over. Dette inkluderte hard skills (i henhold til vår tech stack), kunnskap om våre prosesser, scrum, infrastruktur og prosjektarkitektur. Vi samlet dem i en veikart som er fordelt over tid i løpet av tre måneder.

For eksempel, her er veikartet til min junior

Til hver junior knytter vi en mentor som jobber med vedkommende individuelt. Avhengig av mentoren og kandidatens nåværende nivå kan møtene foregå 1 til 5 ganger i uken, i en times tid hver gang. Mentoren tar frivillig på seg oppgaven, og er en initiativrik frontend-utvikler som ønsker å gjøre mer enn bare å skrive kode.

En del av arbeidsmengden fra mentorene lettes ved kurs i vår tech stack - Dart, Angular. Kursene gjennomføres regelmessig for små grupper på 4-6 personer, der deltakerne kan jobbe uten avbrudd fra jobben.

I løpet av de tre månedene samler vi jevnlig tilbakemeldinger fra juniorene, deres mentorer og ledere, og justerer prosessen individuelt. 1-2 ganger i løpet av perioden gjennomføres en evaluering av de tilegnede ferdighetene, og en lignende evaluering skjer på slutten – basert på denne utarbeides anbefalinger om hva som bør forbedres.

Konklusjon

For selskapet: Er det verdt å satse på juniorer? Ja!

For junioren: Se etter selskaper som nøye velger kandidater og vet hvordan de skal utvikles.

I løpet av tre måneder har vi gått gjennom 122 spørreskjemaer, 54 testoppgaver og hatt 21 tekniske intervjuer. Dette har gitt oss tre flotte juniorer som nå har fullført halvparten av sine onboarding- og akselererings veikart. De løser allerede reelle produktoppgaver i vårt prosjekt, hvor det bare på frontend er over 2 000 000 linjer med kode og mer enn 400 repositorier.

Vi har funnet ut at traktoren for juniorer kan og bør være ganske krevende, men til slutt er det bare de som virkelig er klare til å jobbe hardt og investere i sin egen utvikling som går gjennom den.

Nå er vår hovedoppgave å fullføre tre måneders utviklingsplaner for hver junior i individuell arbeid med en mentor og felles kurs, samle målinger, tilbakemeldinger fra ledere, mentorer og selve deltakerne. Dette vil markere slutten på det første eksperimentet, hvor vi kan trekke konklusjoner, forbedre prosessen og starte den på nytt for å velge nye kandidater.

Kilde: habr.com