Hoe tem je een junior?

Hoe kom je in een groot bedrijf als je een junior bent? Hoe huur je een waardige junior in als je een groot bedrijf bent? Hieronder vertel ik ons verhaal over het aannemen van beginnende jongens voor frontend: hoe we testopdrachten hebben ontwikkeld, ons voorbereidden op het houden van sollicitatiegesprekken en een mentorprogramma opzetten voor de ontwikkeling en onboarding van nieuwkomers, en waarom standaardvragen voor interviews niet werken.

Ik probeer een junior te temmen

Hallo! Mijn naam is Pavel, ik werk aan de frontend in het team van Wrike. We creëren een systeem voor projectmanagement en samenwerking. Ik houd me sinds 2010 met webontwikkeling bezig, heb 3 jaar op buitenlandse afstand gewerkt, heb deelgenomen aan verschillende startups en heb een cursus over webtechnologieën op de universiteit gegeven. In het bedrijf draag ik bij aan de ontwikkeling van technische cursussen en het mentorprogramma van Wrike voor juniors, evenals aan hun directe recrutering.

Waarom we überhaupt over het aannemen van juniors dachten

Tot voor kort huurden we frontend developers van het niveau middle of senior in – genoeg zelfstandig om, na onboarding, productieve taken uit te voeren. Aan het begin van dit jaar realiseerden we ons dat we dit beleid wilden veranderen: het aantal van onze productteams is het afgelopen jaar bijna verdubbeld, het aantal frontend developers nadert honderd, en op korte termijn zou dit nog eens verdubbeld moeten worden. Er is veel werk, we hebben weinig vrije handen, en op de markt zijn er nog minder, dus besloten we ons te richten op jongens die net beginnen met hun reis in frontend en we realiseerden ons dat we bereid zijn in hun ontwikkeling te investeren.

Wie is een junior?

Dit is de allereerste vraag die we ons stelden. Er zijn verschillende criteria, maar het eenvoudigste en duidelijkste principe is als volgt:

Een junior moet uitleggen wat voor functie en hoe te implementeren. Een middle moet uitleggen welke functie nodig is, en hij zal zelf de implementatie begrijpen. Een senior zal je echter zelf uitleggen waarom deze functie helemaal niet nodig is.

Hoe dan ook, een junior is die ontwikkelaar die advies nodig heeft over hoe een bepaalde oplossing te implementeren. Waar we van uitgingen:

1. Een junior is iemand die wil groeien en daarvoor hard wil werken;
2. Hij weet niet altijd in welke richting hij precies wil groeien;
3. Hij heeft behoefte aan advies en zoekt hulp van buitenaf – of dat nu van zijn lead, mentor of in de community is.

We hadden nog enkele hypotheses:

1. Op de junior positie zal een storm van reacties komen.We moeten willekeurige reacties al in de fase van het verzenden van cv's filteren;
2. De primaire filter zal niet helpen. — we hebben ook nog testopdrachten nodig;
3. Testopdrachten zullen iedereen afschrikken. — ze zijn niet nodig.

En natuurlijk hadden we een doel: 4 junioren in 3 weken..

Met dit besef begonnen we te experimenteren. Het plan was eenvoudig: beginnen met een zo breed mogelijke funnel en deze geleidelijk te versmallen zodat we de stroom konden verwerken, maar niet beperken tot 1 kandidaat per week.

We plaatsen de vacature.

Voor het bedrijf:: Er zullen honderden reacties komen! Denk na over een filter.

Voor junioren:: Wees niet bang voor de vragenlijst voordat je je cv en testopdracht indient — dit is een teken dat het bedrijf om je geeft en het proces goed heeft ingesteld.

Op de eerste dag ontvingen we ongeveer 70 cv's van kandidaten 'met kennis van JavaScript'. En toen nog meer. We konden fysiek niet iedereen uitnodigen voor een interview op kantoor en kozen de jongens met de meest interessante pet-projecten, actieve GitHub-accounts of in ieder geval wat ervaring.

Maar de belangrijkste conclusie die we op de eerste dag trokken — de storm was begonnen. Het was tijd om een vragenlijst toe te voegen vóór het indienen van cv's. Het doel was om kandidaten af te wijzen die niet bereid waren om minimale inspanningen te leveren voor het indienen van hun cv, en degenen die niet over de kennis en context beschikten om op zijn minst de juiste antwoorden te googelen.

Er waren standaardvragen over JS, HTML, web en Computer Science — die weet iedereen die begrijpt wat er wordt gevraagd in een front-end interview. Wat is het verschil tussen let/var/const? Hoe pas je stijlen alleen toe voor schermen smaller dan 600px? We wilden deze vragen niet stellen tijdens het technische interview — de ervaring toonde aan dat je dit kon beantwoorden na 2-3 interviews, zonder enige kennis van ontwikkeling. Maar ze konden ons in ieder geval in eerste instantie laten zien of de kandidaat de context begrijpt.

In elke categorie hadden we 3-5 vragen voorbereid en veranderden we dag na dag hun set in het aanvraagformulier, totdat we de meest eenvoudige en de meest complexe uitsloten. Dit stelde ons in staat om de stroom te verminderen — in 3 weken hebben we 122 kandidaten ontvangen., met wie verder gewerkt kon worden. Dit waren IT-studenten; jongens die de overstap van backend naar frontend wilden maken; arbeiders of ingenieurs van 25-35 jaar die radicaal van carrière wilden veranderen en verschillende inspanningen hebben geleverd voor self-education, cursussen en stages.

Laten we elkaar beter leren kennen

Voor het bedrijf:: De testopdracht schrikt kandidaten niet af, maar helpt om de funnel te verkorten.

Voor junioren:: Kopieer de tests niet — dat is merkbaar. En houd je GitHub in orde!

Als we iedereen voor een technisch interview zouden uitnodigen, zouden we ongeveer 40 interviews per week moeten houden, alleen voor junioren en alleen voor frontend. Daarom hebben we besloten om onze tweede hypothese te testen — over de testopdracht.

Wat voor ons belangrijk was in de test:

1. Een goede, schaalbare architectuur opbouwen, maar zonder over-engineering;
2. Het is beter om er langer over te doen, maar het goed te doen, dan het in één nacht te knutselen en te versturen met de opmerking ‘ik zal het zeker afmaken’;
3. De ontwikkelingsgeschiedenis in Git is engineeringcultuur, iteratieve ontwikkeling en dat de oplossingen helemaal niet van elkaar zijn gekopieerd.

We kwamen overeen dat we één algoritmische uitdaging en een klein webapplicatie wilden bekijken. De algoritmen waren voorbereid op het niveau van laboratoria in de beginjaren — binaire zoekopdrachten, sorteren, anagram controleren, werken met lijsten en bomen. Uiteindelijk hebben we gekozen voor de binaire zoekopdracht als eerste proefversie. De webapplicatie moest een simpel spelletje van morris (tic-tac-toe) zijn, met gebruik van welk framework dan ook (of zonder).

Bijna de helft van de resterende jongens voltooide de testopdracht — we ontvingen oplossingen van 54 kandidaten. Ongelooflijke inzicht — hoeveel implementaties van morris, klaar voor kopiëren, denk je dat er op internet zijn?

Hoeveel?Het lijkt erop dat er in werkelijkheid slechts 3 zijn. En in de overgrote meerderheid van de oplossingen waren het precies deze 3 opties.
Wat we niet leuk vonden:

• kopieerwerk, of ontwikkeling volgens dezelfde tutorial zonder eigen architectuur;
• beide taken in één repository in verschillende mappen, en natuurlijk zonder commitgeschiedenis;
• vuil code, schending van DRY-principes, gebrek aan opmaak;
• een mengeling van model, view en controller in één klasse van honderden regels code;
• gebrek aan begrip van unit testing;
• een rechttoe-rechtaan oplossing — harde codering van de winnende combinaties 3x3, wat vrij moeilijk zal zijn om uit te breiden naar 10x10, bijvoorbeeld.

We hebben ook gekeken naar aangrenzende repositories — geweldige pet-projecten waren winstgevend, terwijl een heleboel testopdrachten van andere bedrijven eerder een aanwijzing waren: waarom kon de kandidaat daar niet doorgaan?

Uiteindelijk vonden we geweldige opties op React, Angular, Vanilla JS — we verzamelden er 29. En we besloten nog een kandidaat uit te nodigen zonder test vanwege zijn geweldige pet-projecten. Onze hypothese over het nut van testopdrachten werd bevestigd.

Technisch interview

Voor het bedrijf:: Er kwamen geen medior/senior kandidaten! We hebben een meer persoonlijke benadering nodig.

Voor junioren:: Vergeet niet dat dit geen examen is — probeer niet stil te blijven om een voldoende te halen of de professor met een stroom van al je mogelijke kennis te overweldigen, zodat hij in de war raakt en "uitstekend" geeft.

Wat willen we begrijpen tijdens het technische interview? Een eenvoudige zaak — hoe de kandidaat denkt. Waarschijnlijk heeft hij enige hard skills, als hij de eerste selectiestappen heeft doorlopen — we moeten alleen ontdekken of hij ze kan toepassen. We kwamen uit op 3 opdrachten.

De eerste — over algoritmes en datastructuren. Met pen en papier, in pseudocode en met behulp van tekeningen gingen we na hoe we een boom konden kopiëren of een element uit een enkelvoudige lijst konden verwijderen. Het was een onaangename ontdekking dat niet iedereen recursie en hoe verwijzingen werken begrijpt.

De tweede — live coding. We gingen naar codewars.com, kozen voor eenvoudige dingen zoals het sorteren van een lijst met woorden op de laatste letter en probeerden binnen 30-40 minuten samen met de kandidaat alle tests te laten slagen. Het leek er niet op dat er verrassingen zouden zijn van jongens die tic-tac-toe hadden volbracht — maar in de praktijk kon niet iedereen begrijpen dat de waarde in een variabele moest worden opgeslagen en dat de functie iets moest retourneren via return. Hoewel ik hoop dat het een zenuwenkwestie was en de jongens in staat waren om deze taken onder lichtere omstandigheden op te lossen.

Ten slotte, de derde — een beetje over architectuur. We bespraken hoe we een zoekbalk konden maken, hoe debounce werkt, hoe verschillende widgets in de zoeksuggesties gerenderd kunnen worden, en hoe de frontend kan communiceren met de backend. Er kwamen verschillende interessante oplossingen naar voren, inclusief server-side rendering en websockets.

We hebben 21 interviews volgens dit schema afgenomen. Het publiek was heel divers - laten we het hebben over stripboeken:

1. ‘Raket’. Rust nooit, zoekt overal aandacht en tijdens het interview overvalt hij je met een stroom van gedachten die niet eens direct verband houden met de gestelde vraag. Als het een universitaire situatie was, zou het voor velen een bekende poging zijn om eigenlijk al je kennis te tonen, wanneer je je van het betreffende onderwerp alleen herinnert dat je gisteravond besloot om het niet te leren - alsnog kom je er niet mee weg.
2. ‘Groot’. Het is moeilijk om contact te maken, omdat hij Groot is. Tijdens het interview duurt het een tijdje voordat je antwoorden kunt krijgen, woord voor woord. Het is goed als het gewoon een blokkade is - anders zal het later in je dagelijkse werk heel moeilijk voor je worden.
3. ‘Drax’. Heeft eerder vrachtvervoer gedaan en heeft alleen JS geleerd via Stackoverflow, dus begrijpt niet altijd waar het gesprek tijdens het interview over gaat. Toch is het een goed persoon, met goede bedoelingen, en hij wil een geweldige frontend ontwikkelaar worden.
4. En waarschijnlijk, ‘Star-Lord’. In het algemeen, een redelijke kandidaat, met wie je een overeenkomst kunt bereiken en een gesprek kunt voeren.

Aan het einde van onze onderzoeken 7 kandidaten gingen door naar de finale, waarbij ze hun hard skills bevestigden met een geweldig testproject en goede antwoorden tijdens het interview.

Culturele fit

Voor het bedrijf:: Het is fijn om met hem samen te werken! Is de kandidaat echt bereid om extreem veel te werken voor zijn ontwikkeling? Zal hij echt in het team passen?

Voor junioren:: Het is fijn om met hen samen te werken! Is het bedrijf echt bereid om te investeren in de groei van juniors, of zullen ze je gewoon alle vuile werk overdracht met een laag salaris?

Elke junior, naast het productteam, wiens leider moet instemmen met zijn opname, krijgt een mentor toegewezen. De taak van de mentor is om hem door het drie maanden durende onboarding-proces en het ontwikkelen van hard skills te begeleiden. Dus voor elke culturele fit kwamen we als mentoren en stelden we onszelf de vraag: 'Neem ik de verantwoordelijkheid om de kandidaat in drie maanden volgens ons plan te ontwikkelen?'

Deze fase verliep zonder bijzonderheden en bracht ons uiteindelijk 4 aanbiedingen, waarvan er 3 zijn geaccepteerd en de jongens in de teams zijn gekomen.

Leven na de aanbieding

Voor het bedrijf:: Zorg voor je juniors, anders doen anderen dat!

Voor junioren:: AAAAAAAAAAAAAA!!!

Als er een nieuwe werknemer binnenkomt, moet hij worden onboarded — hij moet worden ingelicht over de processen, verteld worden hoe alles in het bedrijf en in het team werkt, en hoe hij eigenlijk moet werken. Wanneer er een junior binnenkomt, moet worden begrepen hoe hij zich kan ontwikkelen.

Toen we hierover nadachten, hebben we een lijst samengesteld van 26 vaardigheden die, naar onze mening, een junior aan het eind van de drie maanden onboarding moet bezitten. Dit omvatte hard skills (volgens onze stack), kennis van onze processen, scrum, infrastructuur en projectarchitectuur. We hebben ze samengevoegd in een roadmap, verspreid over 3 maanden.

Bijvoorbeeld, hier is de roadmap van mijn junior

Aan elke junior koppelen we een mentor die individueel met hem werkt. Afhankelijk van de mentor en het huidige niveau van de kandidaat, kunnen de ontmoetingen 1 tot 5 keer per week plaatsvinden, elk gedurende 1 uur. Mentoren zijn vrijwillig initiatiefnemende frontend-ontwikkelaars die meer willen doen dan alleen code schrijven.

De belastingen van de mentoren worden verlicht door cursussen over onze stack — Dart, Angular. De cursussen worden regelmatig gegeven voor kleine groepen van 4-6 personen, waar de jongens werken zonder onderbreking.

Gedurende 3 maanden verzamelen we regelmatig feedback van junioren, hun mentoren en leads en passen we het proces individueel aan. 1-2 keer gedurende de hele periode wordt er een evaluatie van de verworven vaardigheden uitgevoerd, en aan het einde wordt een soortgelijke evaluatie uitgevoerd — op basis daarvan worden aanbevelingen gedaan over wat precies verbeterd moet worden.

Conclusie

Voor het bedrijf:: Moet je investeren in junioren? Ja!

Voor junioren:: Zoek bedrijven die zorgvuldig kandidaten selecteren en weten hoe ze hen moeten ontwikkelen.

In 3 maanden hebben we 122 vragenlijsten, 54 testopdrachten bekeken en 21 technische interviews afgenomen. Dit heeft ons 3 geweldige junioren opgeleverd, die nu de helft van hun onboarding- en acceleratie-roadmaps hebben doorlopen. Ze sluiten al echte producttaken af in ons project, waar maar liefst 2.000.000 regels code op de frontend staan en meer dan 400 repositories zijn.

We hebben ontdekt dat de funnel voor junioren vrij complex kan en moet zijn, maar uiteindelijk passeren daar alleen die jongens die echt bereid zijn om heel hard te werken en in hun ontwikkeling te investeren.

Momenteel is onze belangrijkste taak om drie maanden lange roadmapontwikkelingen voor elke junior af te ronden in een individuele werkomgeving met een mentor en gezamenlijke cursussen, metrics te verzamelen, feedback van teamleiders, mentoren en de juniors zelf. Op basis van deze gegevens kan het eerste experiment als afgerond worden beschouwd, conclusies worden getrokken, het proces worden verbeterd en opnieuw worden opgestart voor de selectie van nieuwe kandidaten.

Bron: habr.com