Hur man kommer in i ett stort företag som junior? Hur anstÀller man en vÀrdig junior om man Àr ett stort företag? Under inlÀgget delar jag vÄr historia om att rekrytera nybörjare till frontend: om hur vi utformade testuppgifter, förberedde intervjuer och byggde ett mentorskapsprogram för att utveckla och integrera nykomlingar, samt varför standardfrÄgor för intervjuer inte fungerar.
Jag försöker trÀna en junior
Hej! Jag heter Pavel, jag jobbar med frontend i teamet pÄ Wrike. Vi skapar ett system för projektledning och samarbete. Jag har hÄllit pÄ med webben sedan 2010, arbetade i tre Är pÄ utlÀndska distansjobb, deltog i flera startups och undervisade i webteknologier pÄ universitetet. PÄ företaget deltar jag i utvecklingen av tekniska kurser och Wrikes mentorskapsprogram för juniorer, samt i sjÀlva rekryteringen av dem.
Varför vi överhuvudtaget började tÀnka pÄ att anstÀlla juniorer
Tidigare anstĂ€llde vi frontendutvecklare pĂ„ mellan- eller seniornivĂ„ â tillrĂ€ckligt sjĂ€lvstĂ€ndiga för att efter onboarding kunna arbete med produktuppgifter. I början av detta Ă„r insĂ„g vi att vi ville Ă€ndra denna politik: under det gĂ„ngna Ă„ret har antalet av vĂ„ra produktteam nĂ€stan fördubblats, antalet frontendutvecklare har nĂ€rmat sig hundra, och pĂ„ kort sikt förvĂ€ntas detta fördubblas igen. Det finns mycket arbete och fĂ„ tillgĂ€ngliga hĂ€nder, och pĂ„ marknaden finns det Ă€nnu fĂ€rre, sĂ„ vi bestĂ€mde oss för att vĂ€nda oss till personer som just har pĂ„börjat sin resa inom frontend och insĂ„g att vi Ă€r beredda att investera i deras utveckling.
Vad Àr en junior?
Detta Àr den första frÄgan vi stÀllde oss. Det finns olika kriterier, men det enklaste och mest förstÄeliga principen Àr följande:
En junior behöver förklaras vilken funktion och hur den ska göras. En medelutvecklare behöver fÄ veta vilken funktion som behövs, och han kommer sjÀlv att lösa implementeringen. En senior kommer Ä sin sida sjÀlv att förklara varför den funktionen överhuvudtaget inte behöver göras.
PÄ ett eller annat sÀtt Àr en junior den utvecklare som behöver rÄd om hur man ska implementera en viss lösning. FrÄn vilket vi beslutade att utgÄ ifrÄn:
- En junior Àr nÄgon som vill utvecklas och Àr beredd att arbeta hÄrt för det.
- Han vet inte alltid vilken riktning han vill utvecklas i.
- Han behöver rĂ„d och söker hjĂ€lp utifrĂ„n â frĂ„n sin ledare, mentor eller frĂ„n gemenskapen.
Vi hade ocksÄ nÄgra hypoteser:
- För juniorpositionen kommer det att bli ett storm av ansökningar.Vi behöver filtrera bort slumpmÀssiga svar redan i ansökningssteget.
- Det första filtret kommer inte att hjĂ€lpa. â vi behöver fler provuppgifter;
- Provuppgifter skrĂ€mmer 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 en sÄ bred funnel som möjligt och successivt försöka snÀva den sÄ att vi klarade av att hantera flödet utan att reducera det till 1 kandidat per vecka.
Vi publicerar jobbanonsen
För företaget: Det kommer att bli hundratals ansökningar! TÀnk pÄ att ha ett filter.
För juniorer: Tveka inte att anvĂ€nda en enkĂ€t innan du skickar in ditt CV och provuppgifter â det Ă€r ett tecken pĂ„ att företaget bryr sig om dig och har stĂ€llt in processen vĂ€l.
Redan första dagen fick vi omkring 70 CV frÄn kandidater "med kunskaper i JavaScript". Och sedan kom flera. Vi kunde fysiskt inte bjuda in alla till intervju pÄ kontoret och valde istÀllet de som hade de mest imponerande pet-projekten, levande GitHub-konton eller Ätminstone erfarenhet.
Men den viktigaste insikten vi hade redan första dagen var att stormen hade börjat. Det var dags att lÀgga till en enkÀtformulÀr innan vi skickade ivÀg ansökningarna. Syftet var att sortera bort kandidater som inte var villiga att lÀgga ner minimiinsats för att skicka in sina CV och de som inte hade kunskap och kontext för att googla fram rÀtt svar.
I den fanns standardfrĂ„gor om JS, markup, webben, datavetenskap â sĂ„dana som alla vet frĂ„ga om pĂ„ en frontendintervju. Vad Ă€r skillnaden mellan let/var/const? Hur applicerar man stilar bara för skĂ€rmar som Ă€r mindre Ă€n 600px i bredd? Vi ville inte stĂ€lla dessa frĂ„gor under tekniska intervjuer â erfarenheten visade att man kan svara pĂ„ dem efter 2-3 intervjuer utan att egentligen förstĂ„ utveckling. Men de kunde ge oss en första idĂ© om kandidaten förstod kontexten.
I varje kategori förberedde vi 3-5 frĂ„gor och Ă€ndrade deras uppsĂ€ttning i svarformulĂ€ret dag för dag, tills vi uteslöt de enklaste och de mest komplicerade. Det gjorde att vi kunde minska flödet â under 3 veckor fick vi 122 kandidater., som man kunde arbeta vidare med. Det var IT-studenter; killar som ville byta frĂ„n backend till frontend; arbetare eller ingenjörer i Ă„ldrarna 25-35 som radikalt ville Ă€ndra yrkesbana och lagt ner olika mycket tid pĂ„ sjĂ€lvstudier, kurser och praktik.
LÄt oss lÀra kÀnna varandra bÀttre
För företaget: Testuppgiften avskrÀcker inte kandidater, utan hjÀlper till att förkorta urvalet.
För juniorer: Kopiera inte testuppgifterna â det mĂ€rks. Och hĂ„ll ditt GitHub i ordning!
Om vi hade kallat alla till teknisk intervju, skulle vi ha behövt genomföra omkring 40 intervjuer i veckan bara för juniorer och endast inom frontend. DĂ€rför bestĂ€mde vi oss för att testa den andra hypotesen â om testuppgiften.
Vad som var viktigt för oss i testet:
- Bygga en bra, skalbar arkitektur, men utan överdesign;
- BÀttre att ta lite lÀngre tid och göra det bra, Àn att pÄ en natt slÀnga ihop nÄgot och skicka med kommentaren 'jag kommer definitivt att slutföra det';
- Historik om utvecklingen i Git â ingenjörskultur, iterativ utveckling och att lösningen inte Ă€r plagiat pĂ„ ett helt uppenbart sĂ€tt.
Vi kom överens om att vi ville se en algoritmisk uppgift och en liten webbapplikation. De algoritmiska uppgifterna var förberedda i stil med labbar frĂ„n grundkurser â binĂ€r sökning, sortering, kontroll av anagram, arbete med listor och trĂ€d. Slutligen bestĂ€mde vi oss för binĂ€r sökning som det första testalternativet. Webbapplikationen skulle vara kors och tvĂ€rs med vilken ram som helst (eller utan en).
NĂ€stan hĂ€lften av de kvarstĂ„ende killarna klarade testuppgiften â vi fick in lösningar 54 kandidater. Otrolig insikt â hur mĂ„nga implementationer av kors och tvĂ€rs tror ni finns pĂ„ nĂ€tet redo att kopieras?
Hur mÄnga?Faktum Àr att det verkar som att det bara finns 3. Och i de övervÀgande delarna av lösningarna var just dessa 3 varianter.
Vad jag inte gillade:
- plagiat, eller utveckling baserad pÄ samma tutorial utan egen arkitektur;
- bÄda uppgifterna i samma repository i olika mappar, commit-historik finns förstÄs inte;
- smutsig kod, brott mot DRY, avsaknad av formatering;
- blandning av modell, vy och controller i en klass med hundratals rader kod;
- brist pÄ förstÄelse för enhetstestning;
- lösning "rakt pĂ„" â hĂ„rdkodning av en 3x3 vinstkombinationsmatris, vilket blir ganska svĂ„rt att utvidga till 10x10, till exempel.
Och vi har ocksĂ„ uppmĂ€rksammat nĂ€rliggande arkiv â fina pet-projekt gick med vinst, medan en massa testuppgifter frĂ„n andra företag snarare var ett tecken pĂ„: varför kunde kandidaten inte gĂ„ vidare dĂ€r?
Till slut hittade vi fina alternativ pĂ„ React, Angular, Vanilla JS â det blev totalt 29. Och en kandidat beslöt vi att bjuda in utan test för sina vĂ€ldigt coola pet-projekt. VĂ„r hypotes om nyttan av testuppgifter bekrĂ€ftades.
Tekniskt intervju
För företaget: Ni fick inte medel- eller senior-kandidater! Det krÀvs en mer individuell lösning.
För juniorer: Kom ihĂ„g att det hĂ€r inte Ă€r ett prov â försök inte att bara hĂ„lla tyst för att klara dig med ett godkĂ€nt, eller övervĂ€ldiga professorn med all din kunskap sĂ„ att han blir förvirrad och ger dig "utmĂ€rkt".
Vad vill vi förstĂ„ under den tekniska intervjun? En enkel sak â hur kandidaten tĂ€nker. Antagligen har han vissa hĂ„rda fĂ€rdigheter om han har tagit sig igenom de första urvalsstegen â det kvarstĂ„r att ta reda pĂ„ om han kan anvĂ€nda dem. Vi kom överens om 3 uppgifter.
Den första â om algoritmer och datastrukturer. Med penna, pĂ„ ett papper, i pseudokod och med hjĂ€lp av bilder gick vi igenom hur man kopierar ett trĂ€d eller hur man tar bort ett element frĂ„n en enkel lĂ€nkad lista. En obehaglig upptĂ€ckte var att inte alla förstod rekursion och hur lĂ€nkar fungerar.
Den andra â livekodning. Vi gick in pĂ„ , valde inte svĂ„ra saker som att sortera en array av ord pĂ„ sista bokstaven och under 30-40 minuter försökte vi tillsammans med kandidaten fĂ„ alla tester att gĂ„ igenom. Det borde inte ha funnits nĂ„gra överraskningar frĂ„n killarna som klarade av kryss och nollor â men i praktiken kunde inte alla förstĂ„ att vĂ€rdet mĂ„ste sparas i en variabel, och funktionen mĂ„ste returnera nĂ„got genom return. Men jag hoppas verkligen att det var nervositet, och killarna kunde reda ut dessa uppgifter i mer avslappnade förhĂ„llanden.
Till sist, den tredje â lite om arkitektur. Vi diskuterade hur man kan skapa en sökfĂ€lt, hur debounce fungerar, hur man renderar olika widgets i sökförslagen, och hur frontend kan interagera med backend. Det fanns mĂ„nga intressanta lösningar, inklusive server-side rendering och websockets.
Vi genomförde 21 intervjuer enligt den hĂ€r modellen. Publiken var helt blandad â lĂ„t oss ta komikserien:
- «Raket». Den lugnar sig aldrig, den Ă€r överallt, och under intervjun kommer den att överösa dig med tankeström, som direkt inte ens Ă€r relaterade till den stĂ€llda frĂ„gan. Om det handlade om ett universitet, skulle det vara en vĂ€lkĂ€nd försök att demonstrera verkligen alla sina kunskaper, dĂ€r du nĂ€r det gĂ€ller det fĂ„ngade Ă€mnet bara kommer ihĂ„g att du igĂ„r kvĂ€ll bestĂ€mde dig för att inte studera det â det spelar ingen roll, du kommer Ă€ndĂ„ inte att klara det.
- «Groot». Det Ă€r ganska svĂ„rt att komma i kontakt med honom, eftersom han Ă€r Groot. Under intervjun mĂ„ste man lĂ€nge fĂ„ igĂ„ng honom, trycka ut svar ord för ord. Det Ă€r bra om det bara Ă€r en blockering â annars kommer det att bli vĂ€ldigt svĂ„rt för dig i det dagliga arbetet senare.
- «Drax». Han har tidigare arbetat med frakt, och han lÀrde sig bara JS genom Stackoverflow, sÄ han förstÄr inte alltid vad som egentligen diskuteras under intervjun. Samtidigt Àr han en bra person, har de bÀsta avsikterna och vill bli en fantastisk frontendutvecklare.
- Och kanske «Star-Lord». Ăverlag Ă€r han en ganska bra kandidat, som man kan nĂ„ en överenskommelse med och bygga en dialog.
I slutet av vÄra undersökningar 7 kandidater kom till finalen, vilket bekrÀftade sina hÄrda fÀrdigheter med en bra testuppgift och bra svar under intervjun.
Kulturell passform
För företaget: Kommer du att arbeta med honom! Ăr kandidaten verkligen beredd att arbeta extremt hĂ„rt för sin utveckling? Kommer han verkligen att passa in i teamet?
För juniorer: Kommer du att arbeta med dem! Ăr företaget verkligen redo att investera i juniorers utveckling, eller kommer de bara att lĂ€gga all 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, hamnar hos en mentor. Mentorns uppgift Àr att leda honom genom en tre mÄnaders onboarding-process och utveckling av hÄrda fÀrdigheter. DÀrför kom vi till varje kulturell passform som mentorer och stÀllde oss sjÀlva frÄgan: "Tar jag pÄ mig ansvaret att utveckla kandidaten under 3 mÄnader enligt vÄr plan?"
Detta steg genomfördes utan nÄgra sÀrskilda hÀndelser och resulterade i slutÀndan i 4 erbjudanden, 3 av dem accepterades, och killarna kom in i teamen.
Livet efter erbjudandet
För företaget: Ta hand om dina juniorer, eller sÄ kommer andra att göra det!
För juniorer: AAAAAAAAAAAA!!!
NĂ€r en ny medarbetare börjar mĂ„ste de onboardas â introduceras till processerna, fĂ„ en förstĂ„else för hur allt fungerar i företaget och teamet och hur de överhuvudtaget ska arbeta. NĂ€r en junior börjar Ă€r det viktigt att förstĂ„ hur man kan utveckla dem.
NÀr vi började tÀnka pÄ detta skapade vi en lista med 26 fÀrdigheter som vi anser att en junior bör ha vid slutet av en tre mÄnaders onboardingperiod. Detta inkluderade hÄrd-kunskaper (enligt vÄr techstack), kunskaper om vÄra processer, Scrum, infrastruktur och projektarkitektur. Vi sammanstÀllde dem i en roadmap, fördelad över tre mÄnader.
Till exempel, hÀr Àr roadmappen för min junior.
Vi tilldelar varje junior en mentor som arbetar med dem individuellt. Beroende pÄ mentorn och kandidatens nuvarande nivÄ kan möten Àga rum 1 till 5 gÄnger i veckan i en timme. Mentorer Àr frivilliga engagerade front-end-utvecklare som vill göra mer Àn bara skriva kod.
En del av arbetsbördan för mentorerna lĂ€ttas upp av kurser i vĂ„r techstack â Dart, Angular. Kurser hĂ„lls regelbundet för smĂ„ grupper om 4-6 personer, dĂ€r deltagarna kan lĂ€ra sig utan att avbryta sitt arbete.
Under de tre mĂ„naderna samlar vi regelbundet in feedback frĂ„n juniorer, deras mentorer och ledare och justerar processen individuellt. 1-2 gĂ„nger under hela perioden görs en bedömning av utvecklade fĂ€rdigheter, och en liknande bedömning görs i slutet â baserat pĂ„ detta skapas rekommendationer om vad som bör förbĂ€ttras.
Slutsats
För företaget: Bör man investera i juniorer? Ja!
För juniorer: Sök efter företag som noggrant vÀljer kandidater och vet hur man utvecklar dem.
Under tre mÄnader granskade vi 122 enkÀter, 54 provuppgifter och genomförde 21 tekniska intervjuer. Detta gav oss tre fantastiska juniorer som nu har genomfört hÀlften av sina roadmaps för onboarding och acceleration. De löser redan verkliga produktuppgifter i vÄrt projekt, dÀr det bara i front-end finns mer Àn 2 000 000 rader kod och över 400 arkiv.
Vi har upptÀckt att urvalet för juniorer kan och bör vara ganska omfattande, men i slutÀnden gÄr det bara igenom de som verkligen Àr beredda att arbeta mycket och investera i sin utveckling.
Just nu Àr vÄrt huvudsakliga mÄl att avsluta tre mÄnaders utvecklingsplaner för varje junior i individuell samverkan med en mentor och gemensamma kurser, samla in mÀtvÀrden, feedback frÄn ledarna, mentorerna och deltagarna sjÀlva. NÀr detta första experiment Àr avslutat kan vi dra slutsatser, förbÀttra processen och starta om den för att vÀlja nya kandidater.
KĂ€lla: habr.com
