🥇Come domare un junior?

Come entrare in una grande azienda se sei junior? Come assumere un giovane decente se sei una grande azienda? Sotto il taglio, ti racconterò la nostra storia di assunzione di principianti nel front-end: come abbiamo svolto attività di test, ci siamo preparati a condurre interviste e abbiamo creato un programma di mentoring per lo sviluppo e l'onboarding dei nuovi arrivati, e anche perché le domande standard del colloquio non sono necessarie. non funziona.

Sto cercando di domare Junior

Ciao! Mi chiamo Pavel, mi occupo del lavoro front-end nel team Wrike. Creiamo un sistema per la gestione e la collaborazione dei progetti. Lavoro sul web dal 2010, ho lavorato 3 anni all'estero, ho partecipato a diverse startup e ho tenuto un corso sulle tecnologie web all'università. In azienda mi occupo dello sviluppo di corsi tecnici e del programma di mentoring Wrike per junior, oltre a reclutarli direttamente.

Perché abbiamo pensato di assumere giovani?

Fino a poco tempo fa, reclutavamo sviluppatori di livello medio o senior per il frontend, sufficientemente indipendenti da svolgere attività sul prodotto dopo l'onboarding. All'inizio di quest'anno ci siamo resi conto che volevamo cambiare questa politica: nel corso dell'anno il numero dei nostri team di prodotto è quasi raddoppiato, il numero di sviluppatori front-end si è avvicinato al centinaio e nel prossimo futuro tutto questo sarà devo raddoppiare ancora. C'è molto lavoro, poche mani libere e ce ne sono ancora meno sul mercato, quindi abbiamo deciso di rivolgerci ai ragazzi che hanno appena iniziato il loro viaggio nel front-end e ci siamo resi conto che siamo pronti a investire nel loro sviluppo.

Chi è un junior?

Questa è la primissima domanda che ci siamo posti. Esistono diversi criteri, ma il principio più semplice e comprensibile è questo:

A Junior è necessario spiegare quale funzione e come farlo. È necessario che al Medio venga spiegato quale funzionalità è necessaria e capirà lui stesso l'implementazione. Il signor stesso ti spiegherà perché non è necessario eseguire questa funzione.

In un modo o nell'altro, un junior è uno sviluppatore che ha bisogno di consigli su come implementare questa o quella soluzione. Su cosa abbiamo deciso di basarci:

Junior è qualcuno che vuole crescere ed è pronto a lavorare duro per questo;
Non sempre sa in quale direzione vuole svilupparsi;
Ha bisogno di consigli e cerca aiuto dall'esterno: dal suo leader, dal suo mentore o nella comunità.

Avevamo anche diverse ipotesi:

Ci sarà una tempesta di risposte alla posizione di June. Devi filtrare le risposte casuali nella fase di invio del tuo curriculum;
Un filtro primario non aiuterà. — sono necessarie più attività di test;
Le attività di test spaventeranno tutti - non sono necessari.

E ovviamente avevamo un obiettivo: 4 junior in 3 settimane.

Con questa consapevolezza abbiamo iniziato a sperimentare. Il piano era semplice: iniziare con il funnel più ampio possibile e provare a restringerlo gradualmente in modo da poter elaborare il flusso, ma non ridurlo a 1 candidato a settimana.

Pubblichiamo un posto vacante

Per la compagnia: Ci saranno centinaia di risposte! Pensa a un filtro.

Per junior: Non aver paura del questionario prima di inviare il tuo curriculum e l'incarico di prova: questo è un segno che l'azienda si è presa cura di te e ha impostato bene il processo.

Il primo giorno abbiamo ricevuto circa 70 curriculum di candidati “con conoscenza di JavaScript”. E poi ancora. E inoltre. Fisicamente non potevamo invitare tutti in ufficio per un colloquio e scegliere tra loro i ragazzi con i progetti per animali domestici più interessanti, vivere Github o almeno sperimentare.

Ma la conclusione principale che abbiamo tratto il primo giorno è stata che la tempesta era iniziata. Ora è il momento di aggiungere un modulo di questionario prima di inviare il tuo curriculum. Il suo obiettivo era quello di eliminare i candidati che non erano disposti a fare il minimo sforzo per inviare un curriculum e quelli che non avevano le conoscenze e il contesto per almeno cercare su Google le risposte corrette.

Conteneva domande standard su JS, layout, web, informatica: tutti coloro che immaginano ciò che chiedono in un colloquio front-end li conoscono. Qual è la differenza tra let/var/const? Come posso applicare gli stili solo a schermi di larghezza inferiore a 600 px? Non volevamo porre queste domande durante un colloquio tecnico: la pratica ha dimostrato che è possibile rispondere dopo 2-3 colloqui senza comprendere affatto lo sviluppo. Ma inizialmente sono riusciti a mostrarci se il candidato, in linea di principio, comprende il contesto.

Per ogni categoria abbiamo preparato 3-5 domande e giorno dopo giorno ne abbiamo modificato l'insieme nel modulo di risposta fino a eliminare le più accettabili e le più difficili. Questo ci ha permesso di ridurre il flusso: in 3 settimane abbiamo ricevuto 122 candidati, con il quale potremmo lavorare ulteriormente. Questi erano studenti di informatica; ragazzi che volevano passare al front-end dal back-end; operai o ingegneri, di età compresa tra 25 e 35 anni, che volevano cambiare radicalmente la propria professione e dedicarsi con maggiore impegno all'autoformazione, ai corsi e ai tirocini.

Conoscersi meglio

Per la compagnia: Il compito del test non scoraggia i candidati, ma aiuta ad abbreviare il percorso.

Per junior: Non copiare e incollare quelli di prova: si nota. E mantieni il tuo GitHub in ordine!

Se chiamassimo tutti per un colloquio tecnico, dovremmo fare circa 40 colloqui a settimana solo per i junior e solo per il front end. Pertanto, abbiamo deciso di testare la seconda ipotesi, relativa all'attività di test.

Cosa è stato importante per noi nel test:

Costruire una buona architettura scalabile, ma senza eccessiva ingegneria;
È meglio impiegare più tempo, ma farlo bene, piuttosto che mettere insieme un mestiere da un giorno all’altro e inviarlo con il commento “Lo finirò sicuramente”;
La storia dello sviluppo in Git è la cultura ingegneristica, lo sviluppo iterativo e il fatto che la soluzione non sia stata copiata in modo palese.

Abbiamo concordato di voler esaminare un problema algoritmico e una piccola applicazione web. Quelli algoritmici sono stati preparati a livello di laboratori di livello elementare: ricerca binaria, ordinamento, controllo di anagrammi, lavoro con elenchi e alberi. Alla fine, abbiamo optato per la ricerca binaria come prima opzione di prova. L'applicazione web doveva funzionare a tris utilizzando qualsiasi framework (o senza di esso).

Quasi la metà dei ragazzi rimanenti ha completato l'attività di test: ci hanno inviato le soluzioni 54 candidati. Intuizione incredibile: quante implementazioni di tris, pronte per il copia-incolla, pensi che ci siano su Internet?

Сколько;In effetti, sembra che ce ne siano solo 3. E nella stragrande maggioranza delle decisioni c'erano proprio queste 3 opzioni.
Cosa non è piaciuto:

copia-incolla o sviluppo basato sullo stesso tutorial senza una propria architettura;
entrambe le attività si trovano nello stesso repository in cartelle diverse, ovviamente non c'è cronologia dei commit;
codice sporco, violazione DRY, mancanza di formattazione;
una miscela di modello, vista e controller in un'unica classe lunga centinaia di righe di codice;
mancanza di comprensione dei test unitari;
una soluzione “frontale” è un hardcode di una matrice 3x3 di combinazioni vincenti, che sarà piuttosto difficile espandere a 10x10, ad esempio.

Abbiamo prestato attenzione anche ai repository vicini: i progetti interessanti per gli animali domestici erano un vantaggio e una serie di attività di test di altre società erano più un campanello d'allarme: perché il candidato non poteva arrivarci?

Di conseguenza, abbiamo trovato opzioni interessanti in React, Angular, Vanilla JS: ce n'erano 29. E abbiamo deciso di invitare un altro candidato senza testare i suoi fantastici progetti per animali domestici. La nostra ipotesi sui benefici delle attività di test è stata confermata.

Colloquio tecnico

Per la compagnia: Non sono i intermedi/senior che sono venuti da te! Abbiamo bisogno di un approccio più individuale.

Per junior: Ricorda che questo non è un esame - non cercare di rimanere in silenzio per una C o di bombardare il professore con un flusso di tutta la tua conoscenza possibile in modo che si confonda e dia un "eccellente".

Cosa vogliamo capire in un colloquio tecnico? Una cosa semplice: come pensa il candidato. Probabilmente ha delle abilità difficili se ha superato le prime fasi di selezione: resta da vedere se sa come usarle. Abbiamo concordato 3 compiti.

Il primo riguarda gli algoritmi e le strutture dati. Con una penna, su un foglio di carta, in pseudolinguaggio e con l'aiuto di disegni, abbiamo capito come copiare un albero o come eliminare un elemento da una lista concatenata singolarmente. La spiacevole scoperta è stata che non tutti comprendono la ricorsione e il funzionamento dei riferimenti.

Il secondo è la codifica in tempo reale. Siamo andati a codewars.com, ha scelto cose semplici come ordinare una serie di parole in base all'ultima lettera e per 30-40 minuti insieme al candidato ha cercato di far superare tutti i test. Sembrava che non dovessero esserci sorprese da parte dei ragazzi che avevano imparato il tris, ma in pratica non tutti erano in grado di rendersi conto che il valore dovrebbe essere memorizzato in una variabile e la funzione dovrebbe restituire qualcosa tramite return. Anche se spero sinceramente che si sia trattato di nervosismo e che i ragazzi siano stati in grado di affrontare questi compiti in condizioni più leggere.

Infine, il terzo riguarda un po’ l’architettura. Abbiamo discusso di come creare una barra di ricerca, di come funziona il debounce, di come visualizzare vari widget nei suggerimenti di ricerca, di come il front-end può interagire con il back-end. C'erano molte soluzioni interessanti, incluso il rendering lato server e i socket web.

Abbiamo condotto 21 interviste utilizzando questo disegno. Il pubblico era completamente vario: diamo un'occhiata ai fumetti:

"Razzo". Non si calma mai, si lascia coinvolgere da tutto e durante un colloquio ti travolgerà con un flusso di pensieri che non sono nemmeno direttamente collegati alla domanda posta. Se fosse in un'università, questo sarebbe un tentativo familiare di dimostrare, beh, tutta la tua conoscenza, quando tutto ciò che ricordi del biglietto che hai trovato è che ieri sera hai deciso di non studiarlo - non riesci ancora a ottenerlo fuori.
"Groot". È abbastanza difficile entrare in contatto con lui perché è Groot. Durante un colloquio, devi passare molto tempo cercando di ottenere risposte parola per parola. Va bene se è solo uno stupore, altrimenti sarà molto difficile per te nel tuo lavoro quotidiano.
"Drax". Lavoravo nel trasporto merci e in termini di programmazione ho imparato solo JS su Stackoverflow, quindi non sempre capisco di cosa si discute durante un colloquio. Allo stesso tempo, è una brava persona, ha le migliori intenzioni e vuole diventare un ottimo sviluppatore front-end.
Beh, probabilmente "Signore delle stelle". Nel complesso, un buon candidato con cui puoi negoziare e costruire un dialogo.

Alla fine della nostra ricerca 7 candidati sono arrivati alla finale, confermando le loro hard skills con un ottimo test e buone risposte al colloquio.

Adattamento culturale

Per la compagnia: Lavori con lui! Il candidato è disposto a lavorare molto duramente per il suo sviluppo? Si inserirà davvero nella squadra?

Per junior: Lavori con loro! L'azienda è davvero pronta a investire nella crescita dei junior, o semplicemente vi scaricherà addosso tutto il lavoro sporco per uno stipendio basso?

Ogni junior, oltre al team di prodotto, il cui leader deve accettare di assumerlo, riceve un mentore. Il compito del mentore è guidarlo attraverso un processo di inserimento e aggiornamento delle competenze tecniche della durata di tre mesi. Pertanto, siamo arrivati a ogni adattamento culturale come mentori e abbiamo risposto alla domanda: "Mi assumerò la responsabilità di sviluppare un candidato in 3 mesi secondo il nostro piano?"

Questa fase è passata senza particolarità e alla fine ci ha portato 4 offerte, 3 dei quali sono stati accettati, e i ragazzi sono entrati nelle squadre.

La vita dopo l'offerta

Per la compagnia: Prenditi cura dei tuoi ragazzi o lo faranno gli altri!

Per junior:AAAAAAAAAA!!!

Quando un nuovo dipendente esce, deve essere inserito, aggiornato sui processi, informato su come funziona tutto in azienda e nel team e come dovrebbe lavorare in generale. Quando esce un junior bisogna capire come svilupparlo.

Riflettendoci, abbiamo stilato un elenco di 26 competenze che, a nostro avviso, un junior dovrebbe possedere entro la fine del periodo di onboarding di tre mesi. Ciò includeva competenze tecniche (secondo il nostro stack), conoscenza dei nostri processi, Scrum, infrastruttura e architettura del progetto. Li abbiamo combinati in una tabella di marcia, distribuita in 3 mesi.

Ad esempio, ecco la tabella di marcia del mio junior

Assegniamo un mentore a ogni junior che lavora con lui individualmente. A seconda del mentore e del livello attuale del candidato, gli incontri possono svolgersi da 1 a 5 volte a settimana per 1 ora. I mentori sono sviluppatori front-end volontari che vogliono fare qualcosa di più che limitarsi a scrivere codice.

Parte del carico sui mentori viene alleviato dai corsi nel nostro stack: Dart, Angular. I corsi si svolgono regolarmente per piccoli gruppi di 4-6 persone, dove gli studenti studiano senza interruzione dal lavoro.

Nel corso di 3 mesi, raccogliamo periodicamente feedback dai junior, dai loro mentori e responsabili e adattiamo il processo individualmente. Le abilità potenziate vengono controllate 1-2 volte durante l'intero periodo, lo stesso controllo viene eseguito alla fine: sulla base di esse vengono formate raccomandazioni su cosa esattamente deve essere migliorato.

conclusione

Per la compagnia: Vale la pena investire nei junior? SÌ!

Per junior: Cerca aziende che selezionino attentamente i candidati e sappiano come svilupparli

Nel corso di 3 mesi, abbiamo esaminato 122 questionari, 54 attività di test e condotto 21 interviste tecniche. Questo ci ha portato 3 grandi junior che ora hanno completato la metà della loro tabella di marcia di onboarding e accelerazione. Stanno già completando attività di prodotto reali nel nostro progetto, dove ci sono più di 2 di righe di codice e più di 000 repository solo sul front-end.

Abbiamo scoperto che l'imbuto per i junior può e deve essere piuttosto complesso, ma alla fine lo attraversano solo quei ragazzi che sono davvero pronti a lavorare molto duramente e ad investire nel proprio sviluppo.

Ora il nostro compito principale è completare roadmap di sviluppo di tre mesi per ogni junior nella modalità di lavoro individuale con un mentore e corsi generali, raccogliere metriche, feedback da lead, mentori e dai ragazzi stessi. A questo punto il primo esperimento può dirsi concluso, si possono trarre le conclusioni, si può migliorare il processo e si può ricominciare da capo per selezionare nuovi candidati.

Fonte: habr.com

Come domare un junior?