Hvordan kommer man ind i en stor virksomhed, hvis man er junior? Hvordan ansætter man en anstændig junior, hvis man er en stor virksomhed? Under snittet vil jeg fortælle dig vores historie om at ansætte begyndere på frontend: hvordan vi arbejdede gennem testopgaver, forberedte os på at gennemføre interviews og byggede et mentorprogram til udvikling og onboarding af nytilkomne, og også hvorfor standard interviewspørgsmål ikke virker ikke.
Jeg prøver at tæmme Junior
Hej! Mit navn er Pavel, jeg udfører front-end arbejde på Wrike-holdet. Vi laver et system til projektledelse og samarbejde. Jeg har arbejdet på nettet siden 2010, arbejdet 3 år i udlandet, deltaget i flere startups og undervist i et kursus om webteknologier på universitetet. I virksomheden er jeg involveret i udvikling af tekniske kurser og Wrike mentorprogrammet for juniorer, samt direkte rekruttering af dem.
Hvorfor tænkte vi overhovedet på at ansætte juniorer?
Indtil for nylig rekrutterede vi udviklere på mellem- eller seniorniveau til frontend - uafhængige nok til at udføre produktopgaver efter onboarding. I begyndelsen af dette år indså vi, at vi ønskede at ændre denne politik: i løbet af året er antallet af vores produktteams næsten fordoblet, antallet af frontend-udviklere har nærmet sig hundrede, og i den nærmeste fremtid vil alt dette skal fordoble igen. Der er meget arbejde, få frie hænder, og der er endnu færre af dem på markedet, så vi besluttede at henvende os til de fyre, der lige er begyndt deres rejse i frontend og indså, at vi er klar til at investere i deres udvikling.
Hvem er junior?
Dette er det allerførste spørgsmål, vi stillede os selv. Der er forskellige kriterier, men det enkleste og mest forståelige princip er dette:
Junior skal forklares hvilken funktion og hvordan man gør det. Midten skal forklares, hvilken funktion der er nødvendig, og han vil selv finde ud af implementeringen. Signoren vil selv forklare dig, hvorfor denne funktion slet ikke skal udføres.
På den ene eller anden måde er en junior en udvikler, der har brug for råd om, hvordan man implementerer denne eller hin løsning. Hvad vi besluttede at bygge videre på:
- Junior er en, der vil udvikle sig og er klar til at arbejde hårdt for dette;
- Han ved ikke altid, i hvilken retning han vil udvikle sig;
- Har brug for rådgivning og søger hjælp udefra – hos sin leder, mentor eller i samfundet.
Vi havde også flere hypoteser:
- Der vil være en storm af svar på Junes holdning. Du skal filtrere tilfældige svar på tidspunktet for afsendelse af dit CV;
- Et primært filter hjælper ikke. — der er behov for flere testopgaver;
- Testopgaver vil skræmme alle væk - de er ikke nødvendige.
Og selvfølgelig havde vi et mål: 4 juniorer på 3 uger.
Med denne erkendelse begyndte vi at eksperimentere. Planen var enkel: Start med den bredest mulige tragt og forsøg gradvist at indsnævre den, så du kan behandle flowet, men ikke reducere den til 1 kandidat om ugen.
Vi opslår en ledig stilling
For virksomheden: Der vil være hundredvis af svar! Tænk på et filter.
Til junior: Vær ikke bange for spørgeskemaet, før du sender dit CV og testopgave - det er et tegn på, at virksomheden har taget hånd om dig og har sat processen godt op.
På den første dag modtog vi omkring 70 CV'er fra kandidater "med kendskab til JavaScript." Og så igen. Og videre. Vi kunne fysisk ikke invitere alle til kontoret til et interview og valgte blandt dem fyrene med de fedeste kæledyrsprojekter, live Github eller i det mindste erfaring.
Men hovedkonklusionen, som vi gjorde for os selv på den allerførste dag, var, at stormen var begyndt. Nu er det tid til at tilføje en spørgeskemaformular, før du indsender dit CV. Hendes mål var at luge ud af kandidater, der ikke var villige til at yde den mindste indsats for at indsende et CV, og dem, der ikke havde viden og kontekst til i det mindste at Google de rigtige svar.
Den indeholdt standardspørgsmål om JS, layout, web, datalogi – alle, der forestiller sig, hvad de spørger til et frontend-interview, kender dem. Hvad er forskellen mellem let/var/const? Hvordan kan jeg kun anvende stilarter på skærme, der er mindre end 600px brede? Vi ønskede ikke at stille disse spørgsmål ved en teknisk samtale - praksis har vist, at de kan besvares efter 2-3 interviews uden overhovedet at forstå udviklingen. Men de kunne i første omgang vise os, om kandidaten i princippet forstår sammenhængen.
I hver kategori forberedte vi 3-5 spørgsmål, og dag efter dag ændrede vi deres sæt i svarformularen, indtil vi eliminerede de mest acceptable og de sværeste. Dette gjorde det muligt for os at reducere flowet - på 3 uger fik vi 122 kandidater, som vi kunne arbejde videre med. Det var it-studerende; fyre, der ønskede at flytte til fronten fra bagenden; arbejdere eller ingeniører, 25-35 år, som radikalt ønskede at ændre deres erhverv og satte forskellige kræfter i selvuddannelse, kurser og praktik.
At lære hinanden bedre at kende
For virksomheden: Testopgaven afskrækker ikke kandidater, men er med til at forkorte tragten.
Til junior: Undlad at kopiere og indsætte test - det er mærkbart. Og hold din github i orden!
Hvis vi indkaldte alle til en teknisk samtale, ville vi skulle gennemføre omkring 40 samtaler om ugen kun for juniorer og kun i frontenden. Derfor besluttede vi at teste den anden hypotese – om testopgaven.
Hvad var vigtigt for os i testen:
- Byg en god skalerbar arkitektur, men uden overengineering;
- Det er bedre at tage længere tid, men gør det godt, end at sammensætte et håndværk natten over og sende det med kommentaren "Jeg bliver helt sikkert færdig med det";
- Udviklingshistorien i Git er ingeniørkulturen, iterativ udvikling og det faktum, at løsningen ikke åbenlyst blev kopieret.
Vi blev enige om, at vi ville se på ét algoritmisk problem og en lille webapplikation. Algoritmiske blev udarbejdet på niveau med laboratorier på elementært niveau - binær søgning, sortering, kontrol af anagrammer, arbejde med lister og træer. Til sidst besluttede vi os for binær søgning som en første prøvemulighed. Webapplikationen skulle være tic-tac-toe ved at bruge en hvilken som helst ramme (eller uden den).
Næsten halvdelen af de resterende fyre gennemførte testopgaven - de sendte os løsningerne 54 kandidater. Utrolig indsigt - hvor mange implementeringer af tic-tac-toe, klar til copy-paste, tror du, der er på internettet?
Hvor mange?Faktisk ser det ud til, at der kun er 3. Og i langt de fleste beslutninger var der netop disse 3 muligheder.
Hvad jeg ikke kunne lide:
- copy-paste eller udvikling baseret på den samme tutorial uden din egen arkitektur;
- begge opgaver er i det samme lager i forskellige mapper, selvfølgelig er der ingen commit-historik;
- beskidt kode, DRY-overtrædelse, manglende formatering;
- en blanding af model, visning og controller i én klasse hundredvis af linjer med kode lang;
- manglende forståelse af enhedstestning;
- en "head-on" løsning er en hardcode af en 3x3 matrix af vindende kombinationer, som vil være ret svær at udvide til for eksempel 10x10.
Vi var også opmærksomme på nabodepoter - seje kæledyrsprojekter var et plus, og en masse testopgaver fra andre virksomheder var mere et wake-up call: hvorfor kunne kandidaten ikke nå dertil?
Som et resultat fandt vi fede muligheder i React, Angular, Vanilla JS - dem var der 29. Og vi besluttede at invitere en kandidat mere uden at teste til hans meget seje kæledyrsprojekter. Vores hypotese om fordelene ved testopgaver blev bekræftet.
Teknisk interview
For virksomheden: Det er ikke mellemfolk/seniorer, der er kommet til dig! Vi har brug for en mere individuel tilgang.
Til junior: Husk at dette ikke er en eksamen - prøv ikke at tie for et C eller bombarder professoren med en strøm af al din mulige viden, så han bliver forvirret og giver et "fremragende".
Hvad vil vi forstå i et teknisk interview? En simpel ting - hvordan kandidaten tænker. Han har formentlig nogle hårde færdigheder, hvis han har bestået de første trin i udvælgelsen - det skal vise sig, om han forstår at bruge dem. Vi blev enige om 3 opgaver.
Den første handler om algoritmer og datastrukturer. Med en pen, på et stykke papir, på pseudosprog og ved hjælp af tegninger fandt vi ud af, hvordan man kopierer et træ, eller hvordan man fjerner et element fra en enkelt-linket liste. Den ubehagelige opdagelse var, at ikke alle forstår rekursion, og hvordan referencer fungerer.
Den anden er live kodning. Vi gik til , valgte simple ting som at sortere en række ord efter det sidste bogstav og i 30-40 minutter sammen med kandidaten forsøgte at få alle prøverne til at bestå. Det så ud til, at der ikke skulle komme overraskelser fra de fyre, der havde mestret tic-tac-toe - men i praksis var det ikke alle, der kunne indse, at værdien skulle gemmes i en variabel, og funktionen skulle returnere noget via return. Selvom jeg inderligt håber, at det var en rystelse, og fyrene var i stand til at håndtere disse opgaver under lettere forhold.
Til sidst handler den tredje lidt om arkitektur. Vi diskuterede, hvordan man laver en søgelinje, hvordan debounce fungerer, hvordan man gengiver forskellige widgets i søgetips, hvordan frontenden kan interagere med bagenden. Der var en masse interessante løsninger, herunder gengivelse på serversiden og web-sockets.
Vi gennemførte 21 interviews med dette design. Publikum var fuldstændig forskelligartet - lad os se på tegneserier:
- "Raket". Han falder aldrig til ro, blander sig i alt, og under et interview vil han overvælde dig med en strøm af tanker, der ikke engang er direkte relateret til det stillede spørgsmål. Hvis det var på et universitet, ville dette være et velkendt forsøg på at demonstrere, ja, al din viden, når alt du husker om den billet, du stødte på, er, at du i aftes besluttede ikke at studere den - du kan stadig ikke få det ud.
- "Groot". Det er ret svært at komme i kontakt med ham, fordi han er Groot. Under et interview skal du bruge lang tid på at forsøge at få svar ord for ord. Det er godt, hvis det bare er en dvale - ellers vil det være meget svært for dig i dit daglige arbejde.
- "Drax". Jeg plejede at arbejde med godstransport, og programmeringsmæssigt lærte jeg kun JS på Stackoverflow, så jeg forstår ikke altid, hvad der bliver diskuteret ved et interview. Samtidig er han et godt menneske, har de bedste intentioner og ønsker at blive en fantastisk frontend-udvikler.
- Nå, sandsynligvis "Star Lord". Samlet set en god kandidat, som du kan forhandle og bygge dialog med.
I slutningen af vores forskning 7 kandidater nået finalen og bekræftede deres hårde færdigheder med en stor testopgave og gode svar på interviewet.
Kulturel pasform
For virksomheden: Du arbejder med ham! Er kandidaten villig til at arbejde ekstremt hårdt for sin udvikling? Vil han virkelig passe ind på holdet?
Til junior: Du arbejder med dem! Er virksomheden virkelig klar til at investere i væksten af juniorer, eller vil den simpelthen dumpe alt det beskidte arbejde på dig til en lav løn?
Hver junior får udover produktteamet, hvis leder skal acceptere at tage ham, en mentor. Mentorens opgave er at guide ham gennem en tre-måneders proces med onboarding og opgradering af hårde færdigheder. Derfor kom vi til hver kulturel pasform som mentorer og besvarede spørgsmålet: "Vil jeg tage ansvar for at udvikle en kandidat om 3 måneder i henhold til vores plan?"
Denne fase forløb uden særlige træk og bragte os i sidste ende 4 tilbud, hvoraf 3 blev accepteret, og gutterne kom med på holdene.
Livet efter tilbuddet
For virksomheden: Pas på dine juniorer eller andre vil!
Til junior: AAAAAAAAAAAA!!!
Når en ny medarbejder kommer ud, skal han onboardes – holdes ajour med processerne, fortælles, hvordan alt fungerer i virksomheden og i teamet, og hvordan han generelt skal arbejde. Når en junior kommer ud, skal du forstå, hvordan du udvikler ham.
Da vi tænkte over det, kom vi frem til en liste med 26 færdigheder, som en junior efter vores mening burde have ved udgangen af den tre måneder lange onboarding-periode. Dette omfattede hårde færdigheder (i henhold til vores stack), viden om vores processer, Scrum, infrastruktur og projektarkitektur. Vi kombinerede dem til en køreplan, fordelt over 3 måneder.
Her er for eksempel køreplanen for min junior
Vi tildeler en mentor til hver junior, som arbejder med ham individuelt. Afhængig af mentor og kandidatens aktuelle niveau, kan møder foregå fra 1 til 5 gange om ugen i 1 time. Mentorer er frivillige frontend-udviklere, der ønsker at gøre noget mere end bare at skrive kode.
Noget af byrden på mentorer fjernes af kurser på vores stak - Dart, Angular. Der afholdes løbende kurser for mindre grupper på 4-6 personer, hvor eleverne studerer uden afbrydelse fra arbejdet.
I løbet af 3 måneder indsamler vi med jævne mellemrum feedback fra juniorer, deres mentorer og leads og tilpasser processen individuelt. De oppumpede færdigheder tjekkes 1-2 gange over hele perioden, samme kontrol udføres til sidst - ud fra dem dannes anbefalinger til, hvad der præcist skal forbedres.
Konklusion
For virksomheden: Kan det betale sig at investere i juniorer? Ja!
Til junior: Se efter virksomheder, der nøje udvælger kandidater og ved, hvordan man udvikler dem
I løbet af 3 måneder har vi gennemgået 122 spørgeskemaer, 54 testopgaver og gennemført 21 tekniske interviews. Dette bragte os 3 store juniorer, som nu har gennemført halvdelen af deres onboarding og acceleration roadmaps. De er allerede ved at udføre rigtige produktopgaver i vores projekt, hvor der er mere end 2 linjer kode og mere end 000 repositories alene på frontend.
Vi fandt ud af, at tragten for juniorer kan og bør være ret kompleks, men i sidste ende er det kun de fyre, der virkelig er klar til at arbejde meget hårdt og investere i deres udvikling, der går igennem den.
Nu er vores hovedopgave at færdiggøre tre måneders udviklings-køreplaner for hver junior i form af individuelt arbejde med en mentor og generelle kurser, indsamle metrics, feedback fra leads, mentorer og fyrene selv. På dette tidspunkt kan det første eksperiment betragtes som afsluttet, konklusioner kan drages, processen kan forbedres og den kan startes igen for at udvælge nye kandidater.
Kilde: www.habr.com