Come addestrare un junior?

Come entrare in una grande azienda se sei un junior? Come assumere un junior di valore se sei una grande azienda? Di seguito racconterò la nostra storia di assunzione di nuovi talenti nel front-end: come abbiamo progettato i test, ci siamo preparati a condurre interviste e abbiamo organizzato un programma di mentoring per lo sviluppo e l'onboarding dei neofiti, e perché le domande standard per i colloqui non funzionano.

Io, sto cercando di addomesticare un junior

Ciao! Mi chiamo Pavel, faccio front-end nel team di Wrike. Stiamo creando un sistema per la gestione dei progetti e la collaborazione. Lavoro nel web dal 2010, ho trascorso 3 anni lavorando per clienti esteri in remoto, ho partecipato a diverse startup e ho tenuto un corso sulle tecnologie web all'università. Nella mia azienda sono coinvolto nello sviluppo di corsi tecnici e del programma di mentoring per i junior, oltre che nel loro reclutamento diretto.

Perché abbiamo pensato di assumere junior

Fino a poco tempo fa, assumevamo sviluppatori front-end di livello medio o senior, sufficientemente autonomi da poter gestire compiti di prodotto dopo l'onboarding. All'inizio di quest'anno abbiamo realizzato di voler cambiare questa politica: nell'ultimo anno, il numero delle nostre squadre di prodotto è quasi raddoppiato, il numero di front-end developer è salito vicino ai cento e nei prossimi tempi ciò dovrebbe raddoppiare nuovamente. C'è molto lavoro, poche mani disponibili e ancora meno sul mercato, quindi abbiamo deciso di rivolgerci a coloro che stanno appena iniziando il loro percorso nel front-end e abbiamo capito che eravamo pronti a investire nel loro sviluppo.

Chi è un junior?

Questa è la prima domanda che ci siamo posti. Ci sono diversi criteri, ma il principio più semplice e chiaro è il seguente:

A un junior bisogna spiegare quale funzionalità creare e come farla. A un middle bisogna spiegare quale funzionalità serve e lui si organizza autonomamente nella realizzazione. Un senior, invece, ti spiega perché quella funzionalità non deve essere fatta affatto.

In ogni caso, un junior è quel programmatore che ha bisogno di consiglio su come implementare una certa soluzione. Da cosa abbiamo deciso di partire:

1. Un junior è colui che desidera crescere e per questo è pronto a lavorare duramente;
2. Non sa sempre in quale direzione desidera crescere;
3. Ha bisogno di consigli e cerca aiuto all'esterno — dal suo leader, mentore o nella comunità.

Avevamo anche diverse ipotesi:

1. Ci sarà un uragano di risposte per la posizione di junior: Bisogna filtrare le risposte casuali già nella fase di invio del curriculum;
2. Il filtro iniziale non basterà — servono ulteriori test;
3. I test spaventeranno tutti — non sono necessari.

E naturalmente, avevamo un obiettivo: 4 junior in 3 settimane.

Con questa consapevolezza abbiamo iniziato a sperimentare. Il piano era semplice: partire da un imbuto il più largo possibile e provare a restringerlo gradualmente in modo da riuscire a gestire il flusso, ma senza ridurlo a un solo candidato a settimana.

Pubblicare l'annuncio di lavoro

Per l'azienda: Ci saranno centinaia di risposte! Pensate a un filtro.

Per il junior: Non temete un questionario prima di inviare il curriculum e il test — è un segno che l'azienda si prende cura di voi e ha ben impostato il processo.

Il primo giorno ci sono arrivati circa 70 curriculum da candidati "con conoscenza di JavaScript". E poi ancora. E ancora. Non potevamo fisicamente invitare tutti per un colloquio in ufficio e abbiamo scelto ragazzi con progetti interessanti, un buon GitHub o almeno un'esperienza.

Ma la principale conclusione che abbiamo tratto fin dal primo giorno è stata che l'uragano era iniziato. Era il momento di aggiungere un questionario prima di inviare il curriculum. Il suo compito era quello di filtrare i candidati non pronti a impegnarsi minimamente nell'invio del curriculum, e quelli che non possedevano le conoscenze e il contesto almeno a tal punto da poter cercare online le risposte corrette.

Conteneva domande standard su JS, markup, web, Computer Science — le conosce chiunque abbia un'idea di cosa venga chiesto in un colloquio front-end. Qual è la differenza tra let/var/const? Come applicare gli stili solo per schermi larghi meno di 600px? Non volevamo fare queste domande durante l'intervista tecnica — la pratica ha dimostrato che si possono rispondere dopo 2-3 colloqui, senza realmente comprendere lo sviluppo. Ma sicuramente ci hanno permesso di verificare inizialmente se il candidato avesse una comprensione di base del contesto.

In ogni categoria abbiamo preparato 3-5 domande e giorno dopo giorno abbiamo cambiato il loro set nel modulo di risposta, fino a escludere le più triviali e le più difficili. Questo ha permesso di ridurre il flusso — in 3 settimane abbiamo ricevuto 122 candidati, con cui si poteva continuare a lavorare. Erano studenti di informatica; ragazzi che volevano passare dal backend al frontend; lavoratori o ingegneri di età compresa tra i 25 e i 35 anni, che desideravano cambiare drasticamente carriera e avevano dedicato vari sforzi all'autoapprendimento, corsi e tirocini.

Conosciamoci meglio

Per l'azienda: L'incarico di prova non spaventa i candidati, ma aiuta a ridurre il funnel.

Per il junior: Non copiate gli incarichi di prova - si nota. E tenete in ordine il vostro GitHub!

Se avessimo invitato tutti a un colloquio tecnico, ci saremmo trovati a dover condurre circa 40 colloqui a settimana solo per i junior e solo per il frontend. Pertanto, abbiamo deciso di testare la seconda ipotesi - riguardo all'incarico di prova.

Ciò che era importante per noi nell'incarico di prova:

1. Costruire una buona architettura scalabile, ma senza over-engineering;
2. È meglio impiegare più tempo per fare le cose bene piuttosto che assemblare in fretta un lavoro scadente e inviarlo con il commento 'lo porterò a termine'.
3. La cronologia dello sviluppo nel git - cultura ingegneristica, iteratività dello sviluppo e il fatto che la soluzione non sia stata semplicemente copiata.

Abbiamo deciso di esaminare un problema algoritmico e una piccola applicazione web. Gli esercizi algoritmici erano preparati a livello di laboratorio dei corsi iniziali - ricerca binaria, ordinamento, verifica delle anagrammi, lavoro con liste e alberi. Alla fine abbiamo scelto la ricerca binaria come prima prova. L'applicazione web doveva essere il gioco del tris, utilizzando qualsiasi framework (o senza di esso).

Quasi metà dei candidati rimasti ha superato l'incarico di prova - ci hanno inviato soluzioni 54 candidati. Un'incredibile intuizione - secondo voi, quante implementazioni del gioco del tris pronte per la copia si trovano in rete?

Quante?In realtà, sembra che ci siano solo 3. E nella stragrande maggioranza delle soluzioni erano proprio queste 3 varianti.
Cosa non mi è piaciuto:

• copia-incolla, o sviluppo seguendo lo stesso tutorial senza una propria architettura;
• entrambe le attività nello stesso repository in cartelle diverse, senza storia dei commit, ovviamente;
• codice disordinato, violazione del principio DRY, mancanza di formattazione;
• una mescolanza di modello, vista e controller in una sola classe lunga centinaia di righe di codice;
• mancanza di comprensione del testing unitario;
• soluzione 'alla lettera' - hardcodificando la matrice delle combinazioni vincenti 3x3, che sarà piuttosto difficile espandere a 10x10, per esempio.

Inoltre, prestavamo attenzione ai repository circostanti - bei progetti personali erano un aiuto, mentre una serie di incarichi di prova di altre aziende era piuttosto un campanello d'allarme: perché il candidato non è riuscito a passare lì?

Alla fine abbiamo trovato ottime soluzioni su React, Angular, Vanilla JS - ne abbiamo raccolte 29. E abbiamo deciso di invitare un altro candidato senza incarico di prova per i suoi fantastici progetti personali. La nostra ipotesi sull'utilità degli incarichi di prova è stata confermata.

Colloquio tecnico

Per l'azienda: Non vi sono venuti medi o senior! Serve un approccio più personalizzato.

Per il junior: Ricordate che non è un esame - non cercate di zittire per prendere un tre o confondere il professore con tutta la vostra possibile conoscenza, sperando che metta 'eccellente'.

Cosa vogliamo capire durante il colloquio tecnico? Una cosa semplice - come ragiona il candidato. Probabilmente possiede alcune competenze tecniche, se ha superato le prime fasi di selezione - rimane da scoprire se sa applicarle. Ci siamo accordati su 3 problemi.

Il primo - riguardo ad algoritmi e strutture dati. Con penna e foglietto, in pseudo-linguaggio e con disegni, abbiamo esaminato come copiare un albero o come rimuovere un elemento da una lista collegata. Una scoperta sgradevole è stata che non tutti comprendono la ricorsione e come funzionano i riferimenti.

Il secondo - live coding. Entravamo su codewars.com, sceglievamo cose semplici come ordinare un array di parole per ultima lettera e, per 30-40 minuti, cercavamo di far passare tutti i test insieme al candidato. Sembrava non ci dovessero essere sorprese da ragazzi che avevano superato il tris - ma in pratica non tutti riuscivano a realizzare che dovevano mantenere un valore in una variabile e che una funzione doveva restituire qualcosa tramite return. Anche se spero sinceramente che sia stata solo ansia, e che i ragazzi siano riusciti a capire questi problemi in condizioni più leggere.

Infine, il terzo - un po' di architettura. Abbiamo discusso come implementare una barra di ricerca, come funziona il debounce, come rendere vari widget nei suggerimenti di ricerca, come il frontend possa interagire con il backend. Sono emerse parecchie soluzioni interessanti, compreso il server-side rendering e i websocket.

Abbiamo condotto 21 colloqui secondo questo schema. Il gruppo era estremamente eterogeneo - immaginiamo con dei fumetti:

1. «Razzo». Non si ferma mai, si intromette ovunque e durante il colloquio ti sommergerà di pensieri, che non sono nemmeno correlati alla domanda posta. Se fosse all'università, sarebbe quella famosa tentata di dimostrare tutto il proprio sapere, quando riguardo a un biglietto ti ricordi solo che ieri sera hai deciso di non studiarlo — non lo sortirai comunque.
2. «Groot». È piuttosto difficile contattarlo, perché lui è Groot. Durante il colloquio ci vuole tempo per farlo ripartire, tirare fuori le risposte parola per parola. È già buono se è solo un blocco — altrimenti, lavoro quotidiano sarà molto difficile.
3. «Drax». In passato si occupava di trasporti, e ha imparato solo JS tramite Stackoverflow, quindi non sempre capisce di cosa si stia parlando durante il colloquio. Tuttavia, è una brava persona, ha buone intenzioni e vuole diventare un grande sviluppatore front-end.
4. E probabilmente, «Star-Lord». In generale, è un buon candidato, con cui è possibile dialogare e costruire una comunicazione.

Alla fine delle nostre ricerche 7 candidati sono arrivati in finale, confermando le loro hard skills con un ottimo compito di prova e buone risposte durante il colloquio.

Cultural fit

Per l'azienda: Devi lavorare con lui! È davvero pronto a lavorare moltissimo per il suo sviluppo? Si integrerà davvero nel team?

Per il junior: Devi lavorare con loro! È l'azienda realmente pronta a investire nella crescita dei junior, o semplicemente scaricherà su di te tutto il lavoro sporco per uno stipendio basso?

Ogni junior, oltre al team di prodotto, il cui leader deve dare il consenso per assumerlo, viene assegnato a un mentore. L'obiettivo del mentore è guidarlo attraverso un processo di onboarding di tre mesi e miglioramento delle hard skills. Perciò, a ogni cultural fit ci presentavamo come mentori e ci ponevamo la domanda: “Prenderò la responsabilità di far crescere il candidato per 3 mesi secondo il nostro piano?”

Questa fase si è svolta senza particolari problemi e alla fine ci ha portato 4 offerte, 3 delle quali sono state accettate, e i ragazzi sono stati integrati nei team.

La vita dopo l'offerta

Per l'azienda: Prenditi cura dei tuoi junior o lo faranno altri!

Per il junior: AAAAAAAAAAAAA!!!

Quando un nuovo dipendente entra, deve essere onboardato — introdotto ai processi, spiegato come funziona tutto in azienda e nel team, e come deve lavorare. Quando entra un junior, bisogna capire come svilupparlo.

Quando abbiamo cominciato a pensarci, abbiamo creato una lista di 26 skills, che secondo noi un junior dovrebbe possedere al termine del periodo di onboarding di tre mesi. Queste includono hard skills (relative al nostro stack), conoscenze sui nostri processi, scrum, infrastruttura, architettura del progetto. Le abbiamo riunite in una roadmap distribuita su 3 mesi.

Ad esempio, ecco la roadmap del mio junior

A ogni junior abbiniamo un mentore, che lavora con lui in modo individuale. A seconda del mentore e del livello attuale del candidato, gli incontri possono avvenire da 1 a 5 volte a settimana per 1 ora. I mentori diventano volontariamente sviluppatori front-end proattivi, che desiderano fare qualcosa di più che semplicemente scrivere codice.

Parte del carico dai mentori è assorbito dai corsi sul nostro stack — Dart, Angular. I corsi vengono svolti regolarmente per piccoli gruppi di 4-6 persone, dove i ragazzi studiano senza distogliere l'attenzione dal lavoro.

Nel corso di 3 mesi raccoglieremo periodicamente feedback dai junior, dai loro mentori e dai lead, e adegueremo il processo individualmente. 1-2 volte durante questo periodo, verrà effettuata una verifica delle skills acquisite, una verifica simile verrà effettuata alla fine — su questa base verranno formulate raccomandazioni su cosa è necessario potenziare.

Conclusione

Per l'azienda: Vale la pena investire nei junior? Sì!

Per il junior: Cerca aziende che selezionano attentamente i candidati e sanno come svilupparli.

In 3 mesi abbiamo esaminato 122 questionari, 54 compiti di prova e condotto 21 colloqui tecnici. Questo ci ha portato 3 ottimi junior, che ora hanno completato metà delle loro roadmap di onboarding e accelerazione. Già risolvono compiti reali di prodotto nel nostro progetto, dove solo nel front-end ci sono più di 2.000.000 di righe di codice e oltre 400 repository.

Abbiamo scoperto che il funnel per i junior può e deve essere abbastanza complesso, ma alla fine solo i ragazzi veramente pronti a lavorare molto e investire nel proprio sviluppo riescono a superarlo.

Ora il nostro obiettivo principale è completare le roadmap di sviluppo di tre mesi per ciascun junior nella modalità di lavoro individuale con il mentore e corsi comuni, raccogliere metriche, feedback dai lead, dai mentori e dai ragazzi stessi. A questo punto, il primo esperimento potrà essere considerato concluso, si potranno trarre conclusioni, migliorare il processo e ripeterlo per selezionare nuovi candidati.

Fonte: habr.com