🥇Come addomesticare un junior?

Come entrare in una grande azienda se sei un junior? Come assumere un junior di valore se sei una grande azienda? Nel seguito racconterò la nostra storia di assunzione di ragazzi alle prime armi nel front-end: come abbiamo gestito i test, ci siamo preparati per condurre colloqui e abbiamo strutturato un programma di mentoring per lo sviluppo e l'onboarding dei nuovi arrivati, oltre a spiegare perché le domande standard per i colloqui non funzionano.

Io, sto cercando di addestrare un junior

Ciao! Mi chiamo Pavel, faccio front-end nel team di Wrike. Creiamo un sistema per la gestione dei progetti e il lavoro collaborativo. Lavoro nel web dal 2010, ho lavorato per 3 anni in remoto all'estero, ho partecipato a diversi startup e ho insegnato un corso sulle tecnologie web all'università. In azienda partecipo allo sviluppo dei corsi tecnici e del programma di mentoring di Wrike per junior, oltre che direttamente nella loro assunzione.

Perché abbiamo iniziato a pensare all'assunzione di junior

Fino a poco tempo fa assumevamo sviluppatori front-end di livello middle o senior — abbastanza autonomi da svolgere compiti di prodotto dopo l'onboarding. All'inizio di quest'anno abbiamo capito che volevamo cambiare questa politica: nel corso dell'anno il numero delle nostre squadre di prodotto è quasi raddoppiato, il numero dei front-end developer si è avvicinato al centinaio, e a breve questo dovrebbe raddoppiare nuovamente. Ci sono molti lavori da fare, poche mani disponibili e sul mercato ce ne sono ancora meno, quindi abbiamo deciso di rivolgerci a ragazzi che stanno appena iniziando il loro percorso nel front-end e abbiamo capito di essere 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:

Un junior ha bisogno di essere guidato su quale funzionalità realizzare e come farlo. Un middle ha bisogno di capire quale funzionalità è necessaria e lui stesso capirà come implementarla. Un senior invece ti spiegherà perché quella funzionalità non deve essere realizzata affatto.

In un modo o nell'altro, un junior è quel sviluppatore che ha bisogno di consigli su come realizzare determinate soluzioni. Da ciò abbiamo deciso di partire:

Il junior è colui che vuole svilupparsi ed è pronto a lavorare duramente per questo;
Non sempre sa in quale direzione vuole svilupparsi;
Ha bisogno di consigli e cerca aiuto esterno — dal suo leader, mentore o nella comunità.

Abbiamo anche alcune ipotesi:

Sulla posizione junior ci sarà un'ondata di candidature. È necessario filtrare le candidature casuali già nella fase di invio del curriculum;
Il filtro primario non sarà d'aiuto — servono anche compiti di prova;
I compiti di prova 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 con un imbuto il più ampio possibile e poi cercare di restringerlo gradualmente in modo da poter gestire il flusso, senza ridurlo a 1 candidato a settimana.

Pubblicizziamo l'offerta di lavoro

Per l'azienda: Avremo centinaia di candidature! Pensate a un filtro.
Per il junior: Non temete il questionario prima di inviare il curriculum e il compito di prova — è un segno che l'azienda si preoccupa di voi e ha impostato bene il processo.

Nel primo giorno abbiamo ricevuto circa 70 curriculum da candidati 'con conoscenza di JavaScript'. E poi ancora. E ancora. Non potevamo fisicamente invitare tutti a un colloquio in ufficio e abbiamo scelto ragazzi con i progetti pet più interessanti, un GitHub attivo o almeno un po' di esperienza.

Ma la lezione principale che abbiamo imparato nel primo giorno è stata: l'ondata è iniziata. È arrivato il momento di aggiungere un modulo di questionario prima dell'invio del curriculum. Il suo obiettivo era escludere candidati che non erano disposti a fare il minimo sforzo per inviare il curriculum e coloro che non possedevano conoscenze e contesto almeno a tal punto da cercare le risposte corrette su Google.

Conteneva domande standard su JS, HTML, web, Computer Science — le conosce chiunque abbia un'idea di cosa viene chiesto durante un colloquio per un frontend. Qual è la differenza tra let/var/const? Come applicare gli stili solo per schermi più piccoli di 600px in larghezza? Non volevamo fare queste domande durante l'intervista tecnica — l'esperienza ha dimostrato che si può rispondere dopo 2-3 colloqui, senza comprendere davvero lo sviluppo. Ma potevano mostrarci inizialmente se il candidato comprendeva il contesto in generale.

In ogni categoria abbiamo preparato da 3 a 5 domande e giorno dopo giorno cambiavamo il loro set nel modulo di risposta, finché non abbiamo escluso quelle più facili e più difficili. Questo ha permesso di ridurre il flusso — in 3 settimane abbiamo ricevuto 122 candidati, con cui è stato possibile continuare a lavorare. Erano studenti di informatica; ragazzi che hanno voluto passare dal backend al frontend; lavoratori o ingegneri di età compresa tra 25 e 35 anni, che hanno deciso di cambiare radicalmente il loro campo di attività e hanno investito vari sforzi nell'autoformazione, nei corsi e nei tirocini.

Conosciamoci meglio

Per l'azienda: Il compito di prova non spaventa i candidati, ma aiuta a ridurre il funnel.
Per il junior: Non copiate i test — è evidente. E mantenete in ordine il vostro GitHub!

Se avessimo invitato tutti a un colloquio tecnico, avremmo dovuto svolgere circa 40 colloqui a settimana solo per i junior e solo per il frontend. Quindi abbiamo deciso di testare la seconda ipotesi — riguardo al compito di prova.

Ciò che per noi era importante nel compito:

Costruire un'architettura scalabile e ben progettata, ma senza esagerare con l'ingegnerizzazione;
Meglio impiegare più tempo, ma fare bene, piuttosto che fare un lavoro approssimativo in una notte e inviarlo con il commento 'lo porterò a termine';
La storia dello sviluppo su Git — cultura ingegneristica, iterazione nello sviluppo e che la soluzione non fosse copiabile in modo sfacciato.

Abbiamo deciso di voler esaminare un compito algoritmico e una piccola applicazione web. I compiti algoritmici erano preparati a livello di laboratori dei corsi iniziali — ricerca binaria, ordinamento, controllo delle anagrammi, lavoro con liste e alberi. Alla fine ci siamo fermati sulla ricerca binaria come primo esempio di prova. L'applicazione web doveva essere un tris utilizzando qualsiasi framework (o senza di esso).

Quasi metà dei ragazzi rimasti ha completato il compito — ci hanno inviato le soluzioni 54 candidati. Un'incredibile intuizione — secondo voi, quante implementazioni di tris pronte per essere copiate ci sono in rete?

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

copia e incolla, oppure sviluppo seguendo lo stesso tutorial senza un'architettura personale;
entrambe le attività nello stesso repository in diverse cartelle, senza storia dei commit;
codice sporco, violazione del principio DRY, assenza di formattazione;
una fusione di modello, vista e controller in un'unica classe lunga centinaia di righe di codice;
mancanza di comprensione dei test unitari;
soluzione "dritta" — hardcode della matrice delle combinazioni vincenti 3x3, che sarà piuttosto difficile espandere a 10x10, per esempio.

E inoltre, abbiamo fatto attenzione ai repository vicini — progetti interessanti andavano bene, mentre un sacco di test assegnati da altre aziende sembravano più che altro un campanello d'allarme: perché il candidato non è riuscito a passarli?

Alla fine abbiamo trovato ottime opzioni in React, Angular, Vanilla JS — ne abbiamo selezionate 29. E abbiamo deciso di invitare un altro candidato senza test per i suoi progetti molto interessanti. La nostra ipotesi sull'utilità dei test si è rivelata corretta.

Colloquio tecnico

Per l'azienda: Non vi sono venuti solo mid-level/senior! Serve un approccio più personalizzato.
Per il junior: Ricordate che non è un esame — non cercate di rimanere in silenzio per ottenere un punteggio sufficiente o di confondere il professore con un flusso di tutte le vostre conoscenze per farvi dare "ottimo".

Cosa vogliamo capire in un colloquio tecnico? Una cosa semplice: come ragiona il candidato. Probabilmente ha alcune hard skills, se ha superato le prime fasi di selezione — resta da scoprire se sa come applicarle. Abbiamo concordato di affrontare 3 problemi.

Il primo — sugli algoritmi e le strutture dati. Con una penna, su un foglio, in pseudocodice e con disegni abbiamo analizzato come copiare un albero o come eliminare un elemento da una lista collegata. La scoperta sgradevole è stata che non tutti comprendono la ricorsione e come funzionano i riferimenti.

Il secondo — live coding. Siamo andati su codewars.com, abbiamo scelto cose non troppo complesse come l'ordinamento di un array di parole per l'ultima lettera e, per 30-40 minuti, abbiamo cercato di far passare tutti i test insieme al candidato. Sembrava non dovessero esserci sorprese da parte di ragazzi che avevano superato il gioco del tris — ma in pratica non tutti sono riusciti a capire che il valore deve essere salvato in una variabile e che la funzione deve restituire qualcosa tramite return. Anche se spero sinceramente che fosse solo ansia e che siano riusciti a risolvere questi problemi in condizioni più tranquille.

Infine, il terzo — un po' di architettura. Abbiamo discusso di come realizzare una barra di ricerca, come funziona il debounce, come rendere vari widget nei suggerimenti di ricerca, come il frontend può interagire con il backend. Sono emerse numerose soluzioni interessanti, incluso il rendering lato server e i websocket.

Abbiamo condotto 21 interviste seguendo questo schema. Il pubblico era completamente eterogeneo — parliamo di fumetti:

«Raketa». Non si calma mai, si infiltra ovunque, e durante l'intervista ti sommergerà con un flusso di pensieri non necessariamente legati alla domanda posta. Se fosse in un'università, sarebbe il tentativo che molti conoscono di dimostrare di avere una conoscenza approfondita, quando riguardo al biglietto che ti capita di ricordare solo che ieri sera hai deciso di non studiarlo — tanto non lo tirerai fuori.
«Groot». È piuttosto difficile entrare in contatto con lui, perché è Groot. Durante l'intervista bisogna lavorare a lungo per estrarre le risposte parola per parola. È meglio se è solo un'impasse — altrimenti, nella tua quotidianità lavorativa sarà molto difficile.
«Drax». Prima si occupava di trasporti e ha imparato a programmare solo JS su Stackoverflow, quindi non comprende sempre di cosa si stia parlando durante l'intervista. Tuttavia, è una brava persona, ha buone intenzioni e vuole diventare un grande frontend developer.
E probabilmente, «Star-Lord». In generale, è un buon candidato, con cui è possibile accordarsi e costruire un dialogo.

Alla fine delle nostre ricerche 7 candidati hanno raggiunto la finale, confermando le proprie competenze tecniche con un ottimo compito di prova e risposte positive all'intervista.

Cultural fit

Per l'azienda: Sarà un piacere lavorare con lui! È davvero pronto a lavorare estremamente duro per il proprio sviluppo? Si integrerà bene nel team?
Per il junior: Sarà un piacere lavorare con loro! L'azienda è davvero pronta a investire nella crescita dei junior, o semplicemente scaricherà su di voi tutto il lavoro sporco per uno stipendio basso?

Ogni junior, oltre al team di prodotto, il cui leader deve accettare di prenderlo, è assegnato a un mentore. Il compito del mentore è guidarlo attraverso un processo di onboarding e di sviluppo delle hard skills di tre mesi. Quindi per ogni cultural fit ci presentavamo come mentori e ci chiedevamo: «Mi assumerò la responsabilità di fare crescere il candidato seguendo il nostro piano in 3 mesi?»

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 inseriti nei team.

Vita dopo l'offerta

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

Quando entra un nuovo dipendente, è necessario fare onboarding — introdurlo ai processi, spiegargli come funziona tutto in azienda e nel team e come deve lavorare. Quando si tratta di un junior, bisogna capire come svilupparlo.

Quando abbiamo riflettuto su questo, abbiamo redatto un elenco di 26 competenze che, secondo noi, un junior dovrebbe possedere entro la fine del periodo di onboarding di tre mesi. Sono state incluse competenze tecniche (secondo il nostro stack), conoscenze sui nostri processi, sullo Scrum, sull'infrastruttura e sull'architettura del progetto. Le abbiamo raggruppate in una roadmap distribuita nel tempo su 3 mesi.

Ad esempio, ecco la roadmap del mio junior

A ciascun junior associamo 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 un'ora. I mentori sono frontender proattivi che vogliono fare qualcosa di più che semplicemente scrivere codice.

Parte del carico sui mentori è alleviato dai corsi sul nostro stack — Dart, Angular. I corsi si tengono regolarmente per piccoli gruppi di 4-6 persone, dove i ragazzi possono studiare senza essere distolti dal lavoro.

Per tutto il periodo di 3 mesi, raccogliamo periodicamente feedback dai junior, dai loro mentori e dai leader e correggiamo il processo in modo individuale. 1-2 volte durante tutto il periodo viene effettuata una verifica delle competenze acquisite, una verifica simile viene effettuata alla fine — sulla base di essa vengono formulate raccomandazioni su cosa è necessario migliorare.

Conclusione

Per l'azienda: Vale la pena investire nei junior? Sì!
Per il junior: Cercate aziende che selezionano attentamente i candidati e sanno come svilupparli.

In 3 mesi abbiamo esaminato 122 questionari, 54 compiti test e condotto 21 colloqui tecnici. Questo ci ha portato a 3 fantastici junior, che ora hanno completato metà delle loro roadmap per l'onboarding e l'accelerazione. Stanno già risolvendo compiti reali nel nostro progetto, dove solo nel front-end ci sono più di 2.000.000 righe di codice e oltre 400 repository.

Abbiamo scoperto che il funnel per i junior può e deve essere abbastanza complesso, ma alla fine vi passano solo quei ragazzi che sono realmente pronti a lavorare molto e a investire nel proprio sviluppo.

Attualmente il nostro obiettivo principale è completare le road map di sviluppo di tre mesi per ciascun junior attraverso il lavoro individuale con un mentore e corsi comuni, raccogliere metriche, feedback dai leader, dai mentori e dai ragazzi stessi. Una volta concluso, questo primo esperimento potrà essere considerato completato, si potranno trarre conclusioni, migliorare il processo e ripartire da capo per selezionare nuovi candidati.

Fonte: habr.com