Hvordan komme inn i et stort selskap hvis du er junior? Hvordan ansette en anstendig junior hvis du er et stort selskap? Under snittet vil jeg fortelle deg historien vår om å ansette nybegynnere på frontend: hvordan vi jobbet gjennom testoppgaver, forberedte oss på å gjennomføre intervjuer og bygde et mentorprogram for utvikling og introduksjon av nykommere, og også hvorfor standard intervjuspørsmål ikke fungerer ikke.
Jeg prøver å temme Junior
Hallo! Jeg heter Pavel, jeg gjør front-end-arbeid på Wrike-teamet. Vi lager et system for prosjektledelse og samarbeid. Jeg har jobbet med web siden 2010, jobbet 3 år i utlandet, deltatt i flere startups og undervist i et kurs om webteknologier ved universitetet. I bedriften er jeg involvert i utvikling av tekniske kurs og Wrike mentorprogram for juniorer, samt direkte rekruttering av disse.
Hvorfor tenkte vi i det hele tatt på å ansette juniorer?
Inntil nylig rekrutterte vi utviklere på mellom- eller seniornivå for frontend - uavhengige nok til å utføre produktoppgaver etter onboarding. I begynnelsen av dette året innså vi at vi ønsket å endre denne policyen: i løpet av året har antallet produktteam nesten doblet seg, antallet frontend-utviklere har nærmet seg hundre, og i nær fremtid vil alt dette må doble igjen. Det er mye arbeid, få ledige hender, og det er enda færre av dem på markedet, så vi bestemte oss for å henvende oss til gutta som nettopp har startet sin reise i frontend og innså at vi er klare til å investere i deres utvikling.
Hvem er junior?
Dette er det aller første spørsmålet vi stilte oss selv. Det er forskjellige kriterier, men det enkleste og mest forståelige prinsippet er dette:
Junior må forklares hvilken funksjon og hvordan den skal gjøres. The Middle må forklares hvilken funksjon som trengs, og han vil finne ut implementeringen selv. Signoren vil selv forklare deg hvorfor denne funksjonen ikke trenger å gjøres i det hele tatt.
På en eller annen måte er en junior en utvikler som trenger råd om hvordan man implementerer denne eller den løsningen. Hva vi bestemte oss for å bygge videre på:
- Junior er en som ønsker å utvikle seg og er klar til å jobbe hardt for dette;
- Han vet ikke alltid i hvilken retning han vil utvikle seg;
- Trenger råd og søker hjelp utenfra - fra sin leder, mentor eller i samfunnet.
Vi hadde også flere hypoteser:
- Det kommer en storm av svar på Junes standpunkt. Du må filtrere tilfeldige svar når du sender CV-en din;
- Et primærfilter hjelper ikke. — det trengs flere testoppgaver;
- Testoppgaver vil skremme bort alle – de trengs ikke.
Og selvfølgelig hadde vi et mål: 4 juniorer på 3 uker.
Med denne erkjennelsen begynte vi å eksperimentere. Planen var enkel: start med en bredest mulig trakt og prøv å gradvis begrense den slik at du kan behandle flyten, men ikke redusere den til 1 kandidat per uke.
Vi legger ut en ledig stilling
For selskapet: Det kommer hundrevis av svar! Tenk på et filter.
For junior: Ikke vær redd for spørreskjemaet før du sender din CV og testoppgave - dette er et tegn på at selskapet har tatt vare på deg og har lagt opp prosessen godt.
Den første dagen mottok vi rundt 70 CVer fra kandidater "med kunnskap om JavaScript." Og så igjen. Og videre. Vi kunne fysisk ikke invitere alle til kontoret for et intervju og valgte fra dem gutta med de kuleste kjæledyrprosjektene, live Github eller i det minste erfaring.
Men hovedkonklusjonen vi gjorde for oss selv allerede den første dagen var at uværet hadde begynt. Nå er det på tide å legge til et spørreskjema før du sender inn CV-en. Målet hennes var å luke ut kandidater som ikke var villige til å anstrenge seg minst mulig for å sende inn en CV, og de som ikke hadde kunnskapen og konteksten til i det minste å Google de riktige svarene.
Den inneholdt standardspørsmål om JS, layout, web, informatikk – alle som forestiller seg hva de spør på et front-end-intervju kjenner dem. Hva er forskjellen mellom let/var/const? Hvordan kan jeg bruke stiler bare på skjermer som er mindre enn 600 piksler brede? Vi ønsket ikke å stille disse spørsmålene på et teknisk intervju - praksis har vist at de kan besvares etter 2-3 intervjuer uten å forstå utviklingen i det hele tatt. Men de kunne i utgangspunktet vise oss om kandidaten i prinsippet forstår konteksten.
I hver kategori forberedte vi 3-5 spørsmål og dag etter dag endret vi deres sett i svarskjemaet til vi eliminerte de mest farbare og vanskeligste. Dette gjorde at vi kunne redusere flyten - på 3 uker fikk vi 122 kandidater, som vi kunne jobbe videre med. Dette var IT-studenter; gutter som ønsket å gå foran fra bakenden; arbeidere eller ingeniører, 25-35 år, som radikalt ønsket å endre yrke og satset varierende mye på egenutdanning, kurs og praksis.
La oss bli bedre kjent med hverandre
For selskapet: Testoppgaven avskrekker ikke kandidater, men bidrar til å forkorte trakten.
For junior: Ikke kopier og lim inn tester - det er merkbart. Og hold githuben i orden!
Hvis vi innkalte alle til et teknisk intervju, ville vi måtte gjennomføre ca. 40 intervjuer per uke kun for juniorer og kun i frontenden. Derfor bestemte vi oss for å teste den andre hypotesen – om testoppgaven.
Hva var viktig for oss i testen:
- Bygg en god skalerbar arkitektur, men uten overteknikk;
- Det er bedre å ta lengre tid, men gjøre det bra, enn å sette sammen et håndverk over natten og sende det med kommentaren "Jeg vil definitivt fullføre det";
- Utviklingshistorien i Git er ingeniørkulturen, iterativ utvikling og det faktum at løsningen ikke ble blankt kopiert.
Vi ble enige om at vi ville se på ett algoritmisk problem og en liten nettapplikasjon. Algoritmiske ble utarbeidet på nivå med laboratorier på elementært nivå - binært søk, sortering, se etter anagrammer, arbeid med lister og trær. Til slutt bestemte vi oss for binært søk som et første prøvealternativ. Nettapplikasjonen måtte være tjukk ved å bruke et hvilket som helst rammeverk (eller uten det).
Nesten halvparten av de gjenværende gutta fullførte testoppgaven – de sendte oss løsningene 54 kandidater. Utrolig innsikt - hvor mange implementeringer av tic-tac-toe, klare for copy-paste, tror du det er på Internett?
Hvor mange?Faktisk ser det ut til at det bare er 3. Og i de aller fleste vedtak var det nettopp disse 3 alternativene.
Det jeg ikke likte:
- copy-paste, eller utvikling basert på den samme opplæringen uten din egen arkitektur;
- begge oppgavene er i samme depot i forskjellige mapper, selvfølgelig er det ingen forpliktelseshistorikk;
- skitten kode, DRY-brudd, mangel på formatering;
- en blanding av modell, visning og kontroller i én klasse hundrevis av linjer med kode lang;
- mangel på forståelse av enhetstesting;
- en "head-on"-løsning er en hardkode av en 3x3-matrise av vinnende kombinasjoner, som vil være ganske vanskelig å utvide til for eksempel 10x10.
Vi tok også hensyn til nærliggende depoter - kule kjæledyrprosjekter var et pluss, og en haug med testoppgaver fra andre selskaper var mer en vekker: hvorfor kunne ikke kandidaten komme dit?
Som et resultat fant vi kule alternativer i React, Angular, Vanilla JS - det var 29. Og vi bestemte oss for å invitere en kandidat til uten å teste for hans veldig kule kjæledyrprosjekter. Vår hypotese om fordelene med testoppgaver ble bekreftet.
Teknisk intervju
For selskapet: Det er ikke mellomstore/seniorer som har kommet til deg! Vi trenger en mer individuell tilnærming.
For junior: Husk at dette ikke er en eksamen - ikke prøv å tie for en C eller bombarder professoren med en strøm av all mulig kunnskap slik at han blir forvirret og gir en "utmerket".
Hva ønsker vi å forstå i et teknisk intervju? En enkel ting - hvordan kandidaten tenker. Han har nok noen harde ferdigheter hvis han har bestått de første stadiene av utvelgelsen - det gjenstår å se om han vet hvordan han skal bruke dem. Vi ble enige om 3 oppgaver.
Den første handler om algoritmer og datastrukturer. Med en penn, på et stykke papir, på pseudospråk og ved hjelp av tegninger, fant vi ut hvordan vi kopierer et tre eller fjerner et element fra en enkeltlenket liste. Den ubehagelige oppdagelsen var at ikke alle forstår rekursjon og hvordan referanser fungerer.
Den andre er live koding. Vi gikk til , valgte enkle ting som å sortere en rekke ord etter siste bokstav og i 30-40 minutter sammen med kandidaten forsøkte å få alle prøvene til å bestå. Det så ut til at det ikke skulle komme noen overraskelser fra gutta som hadde mestret tic-tac-toe – men i praksis var det ikke alle som klarte å innse at verdien skulle lagres i en variabel, og funksjonen skulle returnere noe via retur. Selv om jeg håper inderlig at det var en jitter, og gutta var i stand til å takle disse oppgavene under lettere forhold.
Til slutt handler den tredje litt om arkitektur. Vi diskuterte hvordan man lager en søkefelt, hvordan debounce fungerer, hvordan man gjengir ulike widgets i søketips, hvordan frontenden kan samhandle med bakenden. Det var mange interessante løsninger, inkludert gjengivelse på serversiden og web-sockets.
Vi gjennomførte 21 intervjuer med dette designet. Publikum var helt mangfoldig - la oss se på tegneserier:
- "Rakett". Han roer seg aldri, blir involvert i alt, og under et intervju vil han overvelde deg med en strøm av tanker som ikke engang er direkte relatert til spørsmålet som stilles. Hvis det var på et universitet, ville dette vært et kjent forsøk på å demonstrere, vel, all kunnskapen din, når alt du husker om billetten du kom over er at du i går kveld bestemte deg for å ikke studere den - du kan fortsatt ikke få det ut.
- "Groot". Det er ganske vanskelig å komme i kontakt med ham fordi han er Groot. Under et intervju må du bruke lang tid på å prøve å få svar ord for ord. Det er bra hvis det bare er en stupor - ellers vil det være veldig vanskelig for deg i ditt daglige arbeid.
- "Drax". Jeg pleide å jobbe med godstransport, og i form av programmering lærte jeg bare JS på Stackoverflow, så jeg forstår ikke alltid hva som diskuteres på et intervju. Samtidig er han et godt menneske, har de beste intensjonene og ønsker å bli en god front-end-utvikler.
- Vel, sannsynligvis "Star Lord". Totalt sett en god kandidat som du kan forhandle og bygge dialog med.
På slutten av vår forskning 7 kandidater nådde finalen, og bekreftet sine harde ferdigheter med en flott testoppgave og gode svar på intervjuet.
Kulturell passform
For selskapet: Du jobber med ham! Er kandidaten villig til å jobbe ekstremt hardt for sin utvikling? Vil han virkelig passe inn i laget?
For junior: Du jobber med dem! Er selskapet virkelig klar til å investere i vekst av juniorer, eller vil den rett og slett dumpe alt det skitne arbeidet på deg for en lav lønn?
Hver junior, i tillegg til produktteamet, hvis leder må gå med på å ta ham, får en mentor. Mentorens oppgave er å veilede ham gjennom en tremåneders prosess med introduksjon og oppgradering av harde ferdigheter. Derfor kom vi til hver kulturell passform som mentorer og svarte på spørsmålet: "Vil jeg ta ansvar for å utvikle en kandidat om 3 måneder i henhold til planen vår?"
Dette stadiet gikk uten noen spesielle funksjoner og brakte oss til slutt 4 tilbud3 av disse ble akseptert, og gutta meldte seg på lagene.
Livet etter tilbudet
For selskapet: Ta vare på juniorene dine eller andre vil!
For junior: AAAAAAAAAAAA!!!
Når en ny medarbeider kommer ut, må han være ombord - holdes oppdatert på prosessene, fortelle hvordan alt fungerer i bedriften og i teamet, og hvordan han skal jobbe generelt. Når en junior kommer ut, må du forstå hvordan du kan utvikle ham.
Når vi tenkte på det, kom vi opp med en liste med 26 ferdigheter som, etter vår mening, en junior bør ha innen utgangen av den tre måneder lange ombordstigningsperioden. Dette inkluderte harde ferdigheter (i henhold til stabelen vår), kunnskap om prosessene våre, Scrum, infrastruktur og prosjektarkitektur. Vi kombinerte dem til et veikart, fordelt over 3 måneder.
Her er for eksempel veikartet til min junior
Vi tildeler en mentor til hver junior som jobber med ham individuelt. Avhengig av mentor og aktuelle nivå på kandidaten, kan møter finne sted fra 1 til 5 ganger i uken i 1 time. Mentorer er frivillige front-end-utviklere som ønsker å gjøre noe mer enn bare å skrive kode.
Noe av byrden på mentorer tas av kurs på stabelen vår – Dart, Angular. Det holdes jevnlig kurs for små grupper på 4-6 personer, hvor studentene studerer uten avbrudd fra jobben.
I løpet av 3 måneder samler vi med jevne mellomrom tilbakemeldinger fra juniorer, deres mentorer og ledere og justerer prosessen individuelt. De opppumpede ferdighetene sjekkes 1-2 ganger over hele perioden, den samme kontrollen utføres på slutten - basert på dem dannes anbefalinger om hva som må forbedres.
Konklusjon
For selskapet: Er det verdt å investere i juniorer? Ja!
For junior: Se etter selskaper som nøye velger ut kandidater og vet hvordan de skal utvikles
I løpet av 3 måneder har vi gjennomgått 122 spørreskjemaer, 54 testoppgaver og gjennomført 21 tekniske intervjuer. Dette brakte oss 3 flotte juniorer som nå har fullført halvparten av sine onboarding- og akselerasjonsveikart. De fullfører allerede virkelige produktoppgaver i prosjektet vårt, der det er mer enn 2 000 000 linjer med kode og mer enn 400 repositories på frontend alene.
Vi fant ut at trakten for juniorer kan og bør være ganske kompleks, men til syvende og sist er det bare de gutta som virkelig er klare til å jobbe hardt og investere i utviklingen deres som går gjennom den.
Nå er hovedoppgaven vår å fullføre tre måneders utviklingsveikart for hver junior i modus for individuelt arbeid med en mentor og generelle kurs, samle inn beregninger, tilbakemeldinger fra ledere, mentorer og gutta selv. På dette tidspunktet kan det første eksperimentet anses som fullført, konklusjoner kan trekkes, prosessen kan forbedres og det kan startes på nytt for å velge nye kandidater.
Kilde: www.habr.com