Hvordan kommer man ind i et stort firma, hvis man er junior? Hvordan ansætter man en værdig junior, hvis man er et stort firma? Nedenfor vil jeg fortælle vores historie om ansætning af nybegyndere inden for frontend: hvordan vi arbejdede med testopgaver, forberedte os til at gennemføre interviews og opbyggede et mentorprogram til udvikling og onboarding af nybegyndere, samt hvorfor de standard spørgsmål til interviews ikke virker.
Jeg prøver at tæmme en junior
Hej! Mit navn er Pavel, jeg laver frontend i Wrike-teamet. Vi skaber et system til projektledelse og samarbejde. Jeg har arbejdet med web siden 2010, har arbejdet 3 år på international fjernarbejde, deltaget i flere opstartsvirksomheder og undervist i webteknologier på universitetet. I firmaet deltager jeg i udviklingen af tekniske kurser og mentorprogrammet for juniorer hos Wrike samt i deres rekruttering.
Hvorfor overvejede vi overhovedet at ansætte juniorer
Indtil for nylig havde vi ansat frontend-udviklere på mellem- eller seniorniveau — blevet tilstrækkeligt selvstændige til efter onboarding at kunne løse produktopgaver. I starten af året indså vi, at vi ville ændre denne politik: I løbet af et år er antallet af vores produkthold næsten fordoblet, antallet af frontend-udviklere nærmer sig hundrede, og i den nærmeste fremtid skal alt dette fordobles igen. Der er meget arbejde, få tilgængelige hænder, og på markedet er der endnu færre, derfor besluttede vi at henvende os til folk, der lige er startet deres rejse inden for frontend og indså, at vi var klar til at investere i deres udvikling.
Hvad er en junior?
Det er det første spørgsmål, vi stillede os selv. Der er forskellige kriterier, men den enkleste og mest forståelige tilgang er sådan her:
Man skal forklare en junior, hvilken funktion og hvordan man skal lave den. En mellem skal have forklaret, hvilken funktion der er nødvendig, og han klarer selv implementeringen. En senior vil selv forklare, hvorfor den funktion overhovedet ikke bør laves.
På en eller anden måde er en junior den udvikler, der har brug for råd om, hvordan man præcist implementerer en eller anden løsning. Ud fra dette baserede vi os på:
- En junior er en, der ønsker at udvikle sig og er villig til at arbejde hårdt for det;
- Han ved ikke altid, hvilken retning han vil udvikle sig i;
- Har brug for råd og søger hjælp udefra — fra sin leder, mentor eller i fællesskabet.
Vi havde også flere hypoteser:
- Til juniorstillingen vil der være en storm af ansøgninger; Vi skal filtrere tilfældige ansøgninger allerede på ansøgningsstadiet;
- Den primære udvælgelse hjælper ikke — der er brug 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 forståelse begyndte vi at eksperimentere. Planen var simpel: starte med en så bred som muligt tragt og gradvist prøve at indsnævre den, så vi kunne håndtere strømmen, men uden at reducere den til 1 kandidat om ugen.
Vi opslår stillingen
For virksomheden: Der vil komme hundredevis af ansøgninger! Tænk over filteret.
For junioren: Vær ikke bange for spørgeskemaet før du sender dit CV og testopgaven — det er et tegn på, at virksomheden har taget sig af dig og har godt styr på processen.
På den første dag modtog vi omkring 70 CV'er fra kandidater "med kendskab til JavaScript". Og derefter endnu flere. Vi kunne fysisk ikke kalde alle ind til interview i kontoret og valgte dem med de mest imponerende pet-projekter, en aktiv GitHub eller i det mindste lidt erfaring.
Men den vigtigste konklusion, vi nåede på den første dag — stormen var begyndt. Det var tid til at tilføje et spørgeskema før ansøgningen blev sendt. Dets opgave var at skille de kandidater fra, der ikke var villige til at lægge mindste anstrengelse i at sende et CV, og dem, der ikke besad viden og kontekst til at kunne Google de rigtige svar.
Det indeholdt standardspørgsmål om JS, HTML, web og computervidenskab — det ved enhver, der har en idé om, hvad der bliver spurgt om til en frontend-udvælgelse. Hvad er forskellen mellem let/var/const? Hvordan anvender man stilarter kun for skærme, der er mindre end 600px bredde? Vi ønskede ikke at stille disse spørgsmål ved den tekniske samtale — praksis har vist, at man kan svare på dem efter 2-3 interviews, uden at have en dyb forståelse for udvikling. Men de kunne i det mindste vise os, om kandidaten generelt forstod konteksten.
I hver kategori havde vi forberedt 3-5 spørgsmål og ændrede dag for dag deres sæt i ansøgningsformen, indtil vi havde udelukket de alt for lette og alt for svære. Dette gjorde det muligt at reducere strømmen — på 3 uger fik vi 122 kandidater, som kunne arbejde videre. Det var studerende inden for IT; fyre, der ønskede at skifte fra backend til frontend; arbejdere eller ingeniører mellem 25-35 år, som radikalt ønskede at skifte karriere og lagde forskellig indsats i selvuddannelse, kurser og praktikophold.
Lad os lære hinanden bedre at kende
For virksomheden: Testopgaven afskrækker ikke kandidaterne, men hjælper med at forkorte rekrutteringsprocessen.
For junioren: Kopier ikke testopgaverne — det kan ses. Og hold dit GitHub i orden!
Hvis vi havde inviteret alle til teknisk interview, ville vi skulle afholde cirka 40 interviews om ugen kun for juniorer og kun inden for frontend. Derfor besluttede vi at teste den anden hypotese — om testopgaven.
Hvad var vigtigt for os i testopgaven:
- At opbygge en god, skalerbar arkitektur, men uden overengineering;
- Det er bedre at tage sig tid til at gøre det godt, end at lave noget halvvejs og sende det med kommentaren 'jeg vil helt sikkert gøre det færdigt';
- Historien om udviklingen i git — ingeniørkultur, iterativ udvikling og at løsningen ikke er bare kopieret uden videre.
Vi blev enige om, at vi ville se en algoritmisk opgave og en lille webapplikation. De algoritmiske opgaver var forberedt på niveauet af laboratoriekurserne — binær søgning, sortering, tjek for anagrammer, arbejde med lister og træer. Til sidst besluttede vi os for binær søgning som den første testopgave. Webapplikationen skulle være kryds og bolle med brug af en hvilken som helst ramme (eller uden).
Testopgaven blev gennemført af næsten halvdelen af de tilbageværende fyre — vi modtog løsninger fra 54 kandidater.En utrolig indsigt — hvor mange implementeringer af kryds og bolle, klar til at blive kopieret, tror du der findes på nettet?
Hvor mange?Faktisk ser det ud til, at der kun er 3. Og i langt de fleste løsninger var det netop disse 3 varianter.
Hvad jeg ikke kunne lide:
- kopiering, eller udvikling baseret på den samme tutorial uden egen arkitektur;
- begge opgaver i det samme repository i forskellige mapper, men naturligvis uden commit-historie;
- rodede kode, brud på DRY, mangel på formatering;
- en blanding af model, view og controller i én klasse på hundrede linjer kode;
- mangel på forståelse for unit testing;
- Løsningen er "brutal" - en hardkodet matrix af vinderkombinationer 3x3, hvilket vil være ret svært at udvide til 10x10, for eksempel.
Vi lagde også mærke til de tilstødende repositoryer - flotte pet-projekter gik med overskud, mens en masse testopgaver fra andre virksomheder mere var et tegn på: hvorfor kunne kandidaten ikke komme videre derfra?
I sidste ende fandt vi fantastiske kandidater i React, Angular, Vanilla JS - vi havde 29 af dem. Og endnu en kandidat besluttede vi at invitere uden test på grund af hans virkelig imponerende pet-projekter. Vores hypotese om nyttigheden af testopgaver blev bekræftet.
Teknisk interview
For virksomheden: I kan ikke forvente mid-level/seniorer! Der kræves en mere individuel tilgang.
For junioren: Husk, at det ikke er en eksamen - prøv ikke at tie stille og score tre eller forvirre professoren med strømmen af al jeres mulige viden for at få en "udmærket".
Hvad ønsker vi at forstå ved det tekniske interview? En simpel ting - hvordan kandidaten tænker. Formentlig har han nogle hard skills, hvis han har klaret de første udvalgsfaser - det er bare tilbage at finde ud af, om han kan anvende dem. Vi blev enige om 3 opgaver.
Den første - om algoritmer og datastrukturer. Med pen og papir, på pseudokode og med diagrammer diskuterede vi, hvordan man kopierer et træ eller hvordan man fjerner et element fra en singly linked list. En ubehagelig opdagelse var, at ikke alle forstår rekursion og hvordan referencer fungerer.
Den anden - live coding. Vi gik ind på , valgte enkle opgaver som at sortere et array af ord efter den sidste bogstav og i løbet af 30-40 minutter forsøgte vi sammen med kandidaten at få alle tests til at bestå. Det burde ikke være overraskende for de fyre, der har klaret kryds og bolle - men i praksis kunne ikke alle forstå, at værdien skulle gemmes i en variabel, og at funktionen skal returnere noget via return. Selvom jeg håber oprigtigt, at det var nervøsitet, og at fyrene kunne finde ud af disse opgaver under lettere forhold.
Endelig den tredje - lidt om arkitektur. Vi diskuterede, hvordan man kan lave en søgefelt, hvordan debounce fungerer, hvordan man kan rendere forskellige widgets i søgeforeslåelser, og hvordan frontend kan interagere med backend. Der blev fundet mange interessante løsninger, herunder server-side rendering og websockets.
Vi har gennemført 21 interviews på denne måde. Publikum var helt forskelligartet — lad os tage det med tegneserier:
- «Raket». Den holder aldrig op med at være aktiv, blander sig overalt, og til interviewet vil den overdynge dig med en strøm af tanker, der direkte overhovedet ikke relaterer til det stillede spørgsmål. Hvis det var i universitetet, ville det være en velkendt forsøg for mange at demonstrere så mange af sine viden som muligt, når man kun husker, at man i går aften besluttede ikke at lære om det — uanset hvad, vil man ikke kunne trække det op.
- «Groot». Det er ret svært at komme i kontakt med ham, fordi han er Groot. Under interviewet skal man ofte bruge lang tid på at få svar ud af ham, ord for ord. Det er godt, hvis det bare er en blokering — ellers vil du have rigtig svært ved arbejdet efterfølgende.
- «Drax». Tidligere har han arbejdet med fragt, og han har kun lært JS gennem Stackoverflow, så han forstår ikke altid, hvad der overhovedet tales om under interviewet. Han er dog en god person, har de bedste intentioner og ønsker at blive en fantastisk frontend-udvikler.
- Og måske, «Star-Lord». Generelt en god kandidat, man kan forhandle med og bygge en dialog op.
Mod slutningen af vores undersøgelser 7 kandidater kom til finalen, bekræftede deres hårde færdigheder med et godt testprojekt og gode svar under interviewet.
Cultural fit
For virksomheden: Kan du arbejde sammen med ham! Er kandidaten virkelig klar til at arbejde ekstremt meget for sin udvikling? Passer han virkelig ind i teamet?
For junioren: Kan du arbejde sammen med dem! Er virksomheden virkelig klar til at investere i juniorers vækst, eller vil den bare lade dig tage alt det beskidte arbejde for en lav løn?
Hver junior, ud over produktteamet, hvor lederen skal acceptere at tage ham ind, får en mentor. Mentorens opgave er at guide ham gennem en tre-måneders onboarding- og hård-færdigheder-opbygningsproces. Derfor kom vi til hver cultural fit som mentorer og stillede os selv spørgsmålet: «Vil jeg tage ansvaret for at opbygge kandidaten i løbet af 3 måneder efter vores plan?»
Denne fase forløb uden særlige bemærkninger og bragte os til sidst 4 tilbud, hvoraf 3 blev accepteret, og drengene kom ud i teamene.
Livet efter tilbudet
For virksomheden: Tag dig af dine juniorer, eller vil andre gøre det!
For junioren: AAAAAGGGGHHHH!!!!
Når en ny medarbejder tiltræder, skal de onboardes – sættes ind i processerne, informeres om hvordan alt fungerer i virksomheden og i teamet, samt hvordan de generelt skal arbejde. Når en junior tiltræder, er det vigtigt at forstå, hvordan vedkommende kan udvikles.
Da vi overvejede dette, udarbejdede vi en liste med 26 færdigheder, som vi mener, at en junior bør have efter tre måneders onboarding. Denne inkluderede hard skills (i forhold til vores tech stack), kendskab til vores processer, Scrum, infrastruktur og projektets arkitektur. Vi har samlet dem i et roadmap fordelt over 3 måneder.
Her er for eksempel roadmappet for min junior.
Til hver junior knytter vi en mentor, som arbejder med dem individuelt. Afhængigt af mentoren og kandidatens nuværende niveau kan møderne finde sted 1 til 5 gange om ugen i en time. Mentorerne er frivillige, proaktive frontendudviklere, der ønsker at gøre mere end blot at skrive kode.
En del af byrden fra mentorerne lettes af kurser inden for vores stack – Dart, Angular. Kurserne afholdes regelmæssigt for små grupper på 4-6 personer, hvor deltagerne arbejder uden afbrydelse fra deres arbejde.
I løbet af de 3 måneder indsamler vi jævnligt feedback fra juniorerne, deres mentorer og leads, og vi justerer processen individuelt. 1-2 gange i hele perioden foretages en evaluering af de opnåede færdigheder, en tilsvarende evaluering gennemføres i slutningen – baseret på disse dannes der anbefalinger om, hvad der specifikt bør forbedres.
Konklusion
For virksomheden: Er det værd at investere i juniorer? Ja!
For junioren: Søg virksomheder, der nøje udvælger kandidaterne og ved, hvordan de skal udvikles.
I løbet af de 3 måneder har vi gennemgået 122 spørgeskemaer, 54 testopgaver og gennemført 21 tekniske interviews. Dette har givet os 3 fantastiske juniorer, som nu har gennemgået halvdelen af deres onboarding og accelerationsroadmaps. De løser allerede reelle produktopgaver i vores projekt, hvor der kun på frontend er mere end 2.000.000 linjer kode og over 400 repositories.
Vi har fundet ud af, at trappen for juniorer kan og skal være ret kompleks, men i sidste ende er det kun de mennesker, der virkelig er villige til at arbejde hårdt og investere i deres udvikling, der slipper igennem.
Vores primære opgave er nu at afslutte de tre måneders roadmap for udvikling for hver junior i individuel arbejde med en mentor og fælles kurser, samle målinger, feedback fra lederne, mentorer og de unge selv. Med dette kan vi betragte det første eksperiment som afsluttet, drage konklusioner, forbedre processen og genstarte den for at vælge nye kandidater.
Kilde: habr.com
