Hoe een junior temmen?

Hoe kom je bij een groot bedrijf terecht als je junior bent? Hoe huur je een fatsoenlijke junior in als je een groot bedrijf bent? Hieronder vertel ik je ons verhaal over het aannemen van beginners aan de voorkant: hoe we testtaken hebben doorlopen, ons hebben voorbereid om interviews af te nemen en een mentorprogramma hebben opgezet voor de ontwikkeling en onboarding van nieuwkomers, en ook waarom standaard interviewvragen niet werken. 't werkt.

Ik probeer Junior te temmen

Hallo! Mijn naam is Pavel, ik doe front-end werk voor het Wrike-team. Wij creëren een systeem voor projectmanagement en samenwerking. Ik werk sinds 2010 op internet, heb 3 jaar in het buitenland gewerkt, heb deelgenomen aan verschillende startups en heb een cursus webtechnologieën gegeven aan de universiteit. Bij het bedrijf ben ik betrokken bij de ontwikkeling van technische cursussen en het Wrike-mentorprogramma voor junioren, en bij de directe rekrutering ervan.

Waarom hebben we überhaupt aan het aannemen van junioren gedacht?

Tot voor kort rekruteerden we ontwikkelaars op midden- of seniorniveau voor de frontend - onafhankelijk genoeg om producttaken uit te voeren na de onboarding. Begin dit jaar beseften we dat we dit beleid wilden veranderen: in de loop van het jaar is het aantal van onze productteams bijna verdubbeld, het aantal front-end-ontwikkelaars nadert de honderd, en in de nabije toekomst zal dit alles moet nog een keer verdubbelen. Er is veel werk, weinig vrije handen, en er zijn er zelfs nog minder op de markt, dus besloten we ons te wenden tot de jongens die net aan hun reis aan de voorkant zijn begonnen en beseften we dat we klaar zijn om in hun te investeren ontwikkeling.

Wie is junior?

Dit is de allereerste vraag die we onszelf stelden. Er zijn verschillende criteria, maar het eenvoudigste en meest begrijpelijke principe is dit:

Junior moet uitgelegd worden welke functie dit is en hoe hij dit moet doen. Aan het midden moet worden uitgelegd welke functie nodig is, en hij zal zelf de implementatie uitzoeken. De ondertekenaar zelf zal u uitleggen waarom deze functie helemaal niet nodig is.

Op de een of andere manier is een junior een ontwikkelaar die advies nodig heeft over hoe hij een of andere oplossing kan implementeren. Waar we besloten op voort te bouwen:

1. Junior is iemand die zich wil ontwikkelen en bereid is hier hard voor te werken;
2. Hij weet niet altijd in welke richting hij zich wil ontwikkelen;
3. Heeft advies nodig en zoekt hulp van buitenaf - van zijn leidinggevende, mentor of in de gemeenschap.

We hadden ook verschillende hypothesen:

1. Er zal een storm van reacties komen op het standpunt van June. U moet willekeurige reacties filteren tijdens het verzenden van uw cv;
2. Een primair filter helpt niet. — er zijn meer testtaken nodig;
3. Testtaken 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 simpel: begin met een zo breed mogelijke trechter en probeer deze geleidelijk te verkleinen zodat je de stroom kunt verwerken, maar niet terugbrengen tot 1 kandidaat per week.

Wij plaatsen een vacature

Voor het bedrijf: Er zullen honderden reacties zijn! Denk eens aan een filter.

Voor junioren: Wees niet bang voor de vragenlijst voordat u uw cv en testopdracht verzendt - dit is een teken dat het bedrijf voor u heeft gezorgd en het proces goed heeft opgezet.

Op de eerste dag ontvingen we zo’n 70 cv’s van kandidaten “met kennis van JavaScript.” En dan nog een keer. En verder. We konden fysiek niet iedereen op kantoor uitnodigen voor een interview en kozen uit hen de jongens met de coolste huisdierprojecten, live Github, of op zijn minst ervaring.

Maar de belangrijkste conclusie die we op de allereerste dag voor onszelf trokken, was dat de storm was begonnen. Dit is het moment om een ​​vragenlijstformulier toe te voegen voordat u uw cv indient. Haar doel was om kandidaten uit de weg te ruimen die niet bereid waren de minimale inspanning te leveren om een ​​cv in te dienen, en degenen die niet over de kennis en context beschikten om op zijn minst de juiste antwoorden te googlen.

Het bevatte standaardvragen over JS, lay-out, web, informatica - iedereen die zich voorstelt wat ze vragen tijdens een front-end interview kent ze. Wat is het verschil tussen let/var/const? Hoe kan ik stijlen alleen toepassen op schermen die kleiner zijn dan 600 px breed? We wilden deze vragen niet stellen tijdens een technisch interview; de praktijk leert dat ze na 2-3 interviews beantwoord kunnen worden zonder ook maar iets van de ontwikkeling te begrijpen. Maar ze konden ons in eerste instantie laten zien of de kandidaat de context in principe begrijpt.

In elke categorie hebben we 3 tot 5 vragen voorbereid en dag na dag hebben we hun reeks in het antwoordformulier gewijzigd totdat we de meest redelijke en de moeilijkste hadden geëlimineerd. Hierdoor konden we de stroom verminderen - binnen 3 weken ontvingen we 122 kandidaten, waarmee we verder konden werken. Dit waren IT-studenten; jongens die vanaf de backend naar voren wilden gaan; arbeiders of ingenieurs, 25-35 jaar oud, die radicaal hun beroep wilden veranderen en wisselende hoeveelheden energie wilden steken in zelfstudie, cursussen en stages.

Elkaar beter leren kennen

Voor het bedrijf: De testtaak schrikt kandidaten niet af, maar helpt de trechter te verkorten.

Voor junioren: Kopieer en plak geen testexemplaren - het valt op. En houd je github op orde!

Als we iedereen zouden bellen voor een technisch interview, zouden we ongeveer 40 interviews per week moeten afnemen, alleen voor junioren en alleen aan de voorkant. Daarom hebben we besloten om de tweede hypothese te testen: over de testtaak.

Wat voor ons belangrijk was in de test:

1. Bouw een goede schaalbare architectuur, maar zonder overengineering;
2. Het is beter om er langer over te doen, maar het goed te doen, dan van de ene op de andere dag een knutselwerkje in elkaar te zetten en het op te sturen met de opmerking “Ik ga het zeker afmaken”;
3. De geschiedenis van de ontwikkeling in Git is de engineeringcultuur, iteratieve ontwikkeling en het feit dat de oplossing niet schaamteloos werd gekopieerd.

We waren het erover eens dat we naar één algoritmisch probleem en een kleine webapplicatie wilden kijken. Algoritmische werden voorbereid op het niveau van laboratoria op elementair niveau: binair zoeken, sorteren, controleren op anagrammen, werken met lijsten en bomen. Uiteindelijk hebben we gekozen voor binair zoeken als eerste proefoptie. De webapplicatie moest boter-kaas-en-eieren zijn, met welk raamwerk dan ook (of zonder).

Bijna de helft van de overgebleven jongens voltooide de testtaak - zij stuurden ons de oplossingen 54 kandidaten. Ongelofelijk inzicht - hoeveel implementaties van boter-kaas-en-eieren, klaar om te kopiëren en plakken, denk je dat er op internet staan?

Сколько;In feite lijkt het erop dat er maar drie zijn. En bij de overgrote meerderheid van de beslissingen waren er precies deze drie opties.
Wat niet leuk vond:

• kopiëren-plakken, of ontwikkelen op basis van dezelfde tutorial zonder je eigen architectuur;
• beide taken bevinden zich in dezelfde repository in verschillende mappen, uiteraard is er geen commitgeschiedenis;
• vuile code, DRY-overtreding, gebrek aan opmaak;
• een combinatie van model, weergave en controller in één klasse, honderden regels code lang;
• gebrek aan begrip van unit-testen;
• een “frontale” oplossing is een hardcode van een 3x3 matrix van winnende combinaties, die vrij moeilijk uit te breiden zal zijn naar bijvoorbeeld 10x10.

We hebben ook aandacht besteed aan aangrenzende repository's - coole huisdierprojecten waren een pluspunt, en een heleboel testtaken van andere bedrijven waren meer een wake-up call: waarom kon de kandidaat daar niet komen?

Als resultaat vonden we coole opties in React, Angular, Vanilla JS - er waren er 29. En we besloten nog een kandidaat uit te nodigen zonder te testen voor zijn zeer coole huisdierenprojecten. Onze hypothese over de voordelen van testtaken werd bevestigd.

Technisch interview

Voor het bedrijf: Het zijn niet de middens/senioren die naar jou toe zijn gekomen! We hebben een meer individuele aanpak nodig.

Voor junioren: Onthoud dat dit geen examen is - probeer niet te zwijgen voor een C of de professor te bombarderen met een stroom van al je mogelijke kennis, zodat hij in de war raakt en een “uitstekend” geeft.

Wat willen we begrijpen in een technisch interview? Een simpel ding: hoe de kandidaat denkt. Hij beschikt waarschijnlijk over een aantal harde vaardigheden als hij de eerste selectiefasen heeft doorstaan ​​- het valt nog te bezien of hij weet hoe hij ze moet gebruiken. We hebben 3 taken afgesproken.

De eerste gaat over algoritmen en datastructuren. Met een pen, op een stuk papier, in pseudo-taal en met behulp van tekeningen, hebben we uitgezocht hoe we een boom kunnen kopiëren of hoe we een element uit een enkelvoudig gekoppelde lijst kunnen verwijderen. De onaangename ontdekking was dat niet iedereen recursie begrijpt en hoe verwijzingen werken.

De tweede is live coderen. Wij gingen naar codewars.com, koos eenvoudige dingen zoals het sorteren van een reeks woorden op de laatste letter en probeerde gedurende 30-40 minuten samen met de kandidaat alle tests te laten slagen. Het leek erop dat er geen verrassingen zouden komen voor de jongens die boter-kaas-en-eieren onder de knie hadden - maar in de praktijk kon niet iedereen zich realiseren dat de waarde in een variabele moest worden opgeslagen en dat de functie via return iets moest retourneren. Hoewel ik oprecht hoop dat het kriebels waren, en de jongens deze taken onder lichtere omstandigheden konden uitvoeren.

Ten slotte gaat de derde een beetje over architectuur. We bespraken hoe je een zoekbalk maakt, hoe debounce werkt, hoe je verschillende widgets in zoektips kunt weergeven en hoe de front-end kan communiceren met de back-end. Er waren veel interessante oplossingen, waaronder server-side rendering en websockets.

Met dit ontwerp hebben we 21 interviews afgenomen. Het publiek was compleet divers - laten we naar strips kijken:

1. "Raket". Hij kalmeert nooit, bemoeit zich met alles, en tijdens een sollicitatiegesprek zal hij je overweldigen met een stroom van gedachten die niet eens direct verband houden met de gestelde vraag. Als het op een universiteit zou zijn, zou dit een bekende poging zijn om al je kennis te demonstreren, terwijl het enige wat je je herinnert van het kaartje dat je tegenkwam, was dat je gisteravond besloot het niet te bestuderen - je kunt het nog steeds niet krijgen het eruit.
2. "Groot". Het is best lastig om met hem in contact te komen omdat hij Groot is. Tijdens een sollicitatiegesprek ben je lang bezig om woord voor woord antwoorden te krijgen. Het is goed als het maar een verdoving is, anders zal het heel moeilijk voor je zijn in je dagelijkse werk.
3. "Drax". Ik heb vroeger in het vrachtvervoer gewerkt en qua programmeren heb ik alleen JS geleerd op Stackoverflow, dus ik begrijp niet altijd wat er tijdens een interview wordt besproken. Tegelijkertijd is hij een goed mens, heeft hij de beste bedoelingen en wil hij een geweldige front-end developer worden.
4. We zullen waarschijnlijk "Ster Heer". Kortom een ​​goede kandidaat met wie je kunt onderhandelen en een dialoog kunt opbouwen.

Aan het einde van ons onderzoek 7 kandidaten bereikten de finale en bevestigden hun harde vaardigheden met een geweldige testtaak en goede antwoorden op het interview.

culturele fit

Voor het bedrijf: Jij werkt met hem! Is de kandidaat bereid om keihard te werken aan zijn ontwikkeling? Zal hij echt in het team passen?

Voor junioren: Jij werkt met ze samen! Is het bedrijf echt bereid om te investeren in de groei van junioren, of dumpt het al het vuile werk gewoon op jou voor een laag salaris?

Elke junior krijgt, naast het productteam, wiens leiding ermee instemt hem aan te nemen, een mentor. De taak van de mentor is om hem door een drie maanden durend proces van onboarding en het verbeteren van harde vaardigheden te begeleiden. Daarom kwamen we als mentoren bij elke culturele match terecht en beantwoordden de vraag: “Zal ik de verantwoordelijkheid nemen voor het ontwikkelen van een kandidaat in 3 maanden volgens ons plan?”

Deze fase verliep zonder bijzondere kenmerken en bracht ons uiteindelijk 4 aanbiedingen, waarvan er 3 werden geaccepteerd, en de jongens deden mee aan de teams.

Leven na het aanbod

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

Voor junioren: AAAAAAAAAAA!!!

Als er een nieuwe medewerker komt, moet hij worden ingewerkt, op de hoogte worden gebracht van de processen, worden verteld hoe alles werkt in het bedrijf en in het team, en hoe hij in het algemeen zou moeten werken. Als een junior uit de kast komt, moet je begrijpen hoe je hem kunt ontwikkelen.

Toen we erover nadachten, kwamen we op een lijst met 26 vaardigheden die, naar onze mening, een junior aan het einde van de onboardingperiode van drie maanden zou moeten hebben. Dit omvatte harde vaardigheden (volgens onze stapel), kennis van onze processen, Scrum, infrastructuur en projectarchitectuur. We hebben ze samengevoegd in een roadmap, verdeeld over 3 maanden.

Hier is bijvoorbeeld het stappenplan van mijn junior

Aan elke junior wijzen wij een mentor toe, die individueel met hem samenwerkt. Afhankelijk van de mentor en het huidige niveau van de kandidaat kunnen er 1 tot 5 keer per week bijeenkomsten plaatsvinden van 1 uur. Mentoren zijn vrijwillige front-end-ontwikkelaars die meer willen doen dan alleen code schrijven.

Een deel van de last voor mentoren wordt weggenomen door cursussen op onze stapel - Dart, Angular. Er worden regelmatig cursussen gegeven voor kleine groepen van 4-6 personen, waarbij de studenten zonder onderbreking van hun werk studeren.

Gedurende 3 maanden verzamelen we periodiek feedback van junioren, hun mentoren en leads en passen we het proces individueel aan. De opgepompte vaardigheden worden gedurende de gehele periode 1-2 keer gecontroleerd, aan het eind wordt dezelfde controle uitgevoerd - op basis daarvan worden aanbevelingen gedaan over wat er precies moet worden verbeterd.

Conclusie

Voor het bedrijf: Is het de moeite waard om in junioren te investeren? Ja!

Voor junioren: Zoek naar bedrijven die zorgvuldig kandidaten selecteren en weten hoe ze deze moeten ontwikkelen

Gedurende drie maanden hebben we 3 vragenlijsten beoordeeld, 122 testtaken uitgevoerd en 54 technische interviews afgenomen. Dit heeft ons 21 geweldige junioren opgeleverd die nu de helft van hun onboarding- en acceleratie-roadmaps hebben voltooid. Ze voeren al echte producttaken uit in ons project, waar alleen al aan de voorkant meer dan 3 regels code en meer dan 2 opslagplaatsen aanwezig zijn.

We kwamen erachter dat de trechter voor junioren behoorlijk complex kan en moet zijn, maar uiteindelijk passeren alleen die jongens die echt bereid zijn heel hard te werken en in hun ontwikkeling te investeren, deze.

Nu is onze hoofdtaak het voltooien van ontwikkelingsroutekaarten van drie maanden voor elke junior in de modus van individueel werken met een mentor en algemene cursussen, het verzamelen van statistieken, feedback van leads, mentoren en de jongens zelf. Op dit punt kan het eerste experiment als voltooid worden beschouwd, kunnen conclusies worden getrokken, kan het proces worden verbeterd en kan het opnieuw worden gestart om nieuwe kandidaten te selecteren.

Bron: www.habr.com