Cum să ajungi într-o companie mare dacă ești junior? Cum să angajezi un junior decent dacă ești o companie mare? În continuare, voi povesti despre experiența noastră de angajare a tinerelor talente în frontend: despre cum am elaborat teste, ne-am pregătit pentru interviuri și am structurat un program de mentorat pentru dezvoltarea și integrarea noilor veniți, dar și de ce întrebările standard pentru interviuri nu funcționează.
Încerc să îmblânzesc un junior
Salut! Numele meu este Pavel, fac frontend în echipa Wrike. Creăm un sistem pentru gestionarea proiectelor și colaborare. Lucrez în web din 2010, am lucrat 3 ani la remote în străinătate, am participat la câteva startup-uri și am predat un curs de tehnologii web la universitate. În companie, contribuiesc la dezvoltarea cursurilor tehnice și a programului de mentorat Wrike pentru juniori, precum și la recrutarea acestora.
De ce ne-am gândit la angajarea juniorilor
Până de curând, angajam dezvoltatori frontend de nivel middle sau senior — suficient de independenți pentru a putea îndeplini sarcini de produs după integrare. La începutul acestui an, am realizat că dorim să schimbăm această politică: în ultima an, numărul echipelor noastre de produs a crescut aproape de două ori, numărul dezvoltatorilor frontend s-a apropiat de o sută, iar în perspectiva apropiată, acest număr ar trebui să se dubleze din nou. Munca este multă, mâinile libere sunt puține, iar pe piață sunt chiar mai puține, așa că am decis să ne îndreptăm spre cei care abia încep în frontend și am realizat că suntem pregătiți să investim în dezvoltarea lor.
Cine este un junior?
Aceasta este prima întrebare pe care ne-am pus-o. Există diferite criterii, dar cel mai simplu și clar principiu este următorul:
Unui junior trebuie să-i explici ce caracteristică și cum să o implementeze. Unui middle trebuie să-i explici ce caracteristică este necesară, iar el se va descurca singur cu implementarea. Un senior însă îți va explica de ce această caracteristică nu trebuie realizată deloc.
Așa sau altfel, un junior este acel dezvoltator care are nevoie de sfaturi despre cum să implementeze o soluție sau alta. De la ce am decis să ne ghidăm:
- Un junior este cineva care vrea să se dezvolte și este pregătit să muncească mult pentru aceasta;
- Nu știe întotdeauna în ce direcție vrea să se dezvolte;
- Are nevoie de sfaturi și caută ajutor extern — de la liderul său, mentor sau în comunitate.
Am avut și mai multe ipoteze:
- Pe poziția de junior va fi o furtună de răspunsuri. Trebuie să filtrăm răspunsurile aleatorii încă din etapa de trimitere a CV-urilor;
- Filtrul inițial nu va ajuta — avem nevoie de sarcini de testare suplimentare;
- Sarcinile de testare îi vor speria pe toți — nu sunt necesare.
Ei bine, desigur, noi am avut un obiectiv: 4 juniori în 3 săptămâni.
Cu această realizare, am început să experimentăm. Planul a fost simplu: să începem cu un funnel cât mai larg și să încercăm să-l îngustăm treptat, astfel încât să putem gestiona fluxul, dar să nu ajungem la un singur candidat pe săptămână.
Publicăm anunțul de angajare
Pentru companie: Vor fi sute de răspunsuri! Gândiți-vă la un filtru.
Pentru junior: Nu vă fie teamă de chestionar înainte de a trimite CV-ul și sarcina de testare — este un semn că compania se îngrijorează de voi și a pregătit bine procesul.
În prima zi, am primit aproximativ 70 de CV-uri de la candidați "cu cunoștințe de JavaScript". Și apoi încă. Și încă. Nu am putut fizic să chemăm pe toți la interviuri în birou și am ales dintre ei băieți cu cele mai interesante pet-proiecte, un GitHub activ sau măcar un pic de experiență.
Dar concluzia principală pe care am tras-o în prima zi este că furtuna a început. A venit momentul să adăugăm un formular de chestionar înainte de trimiterea CV-ului. Scopul său era să îi excludă pe candidații care nu erau dispuși să facă un minim efort pentru a trimite CV-ul, și pe cei care nu aveau cunoștințe și context suficient pentru a căuta răspunsuri corecte.
În el erau întrebări standard despre JS, markup, web, Computer Science — le știe toată lumea care își dă seama ce se întreabă la un interviu de front-end. Care este diferența dintre let/var/const? Cum aplici stiluri doar pentru ecrane cu o lățime mai mică de 600px? Nu voiam să punem aceste întrebări la interviul tehnic — practic, am observat că la ele se poate răspunde după 2-3 interviuri, fără să se înțeleagă deloc dezvoltarea. Dar acestea ne-au putut arăta, inițial, dacă candidatul înțelege în principiu contextul.
În fiecare categorie am pregătit 3-5 întrebări și zi de zi am schimbat setul acestora în formularul de răspuns, până când am exclus cele mai simple și cele mai dificile. Acest lucru ne-a permis să reducem fluxul — în 3 săptămâni am primit 122 candidați, cu care am putut lucra mai departe. Aceștia erau studenți IT; tineri care au dorit să treacă de la backend la frontend; muncitori sau ingineri cu vârste între 25 și 35 de ani, care au dorit să schimbe radical domeniul de activitate și au depus diferite eforturi în auto-educare, cursuri și stagii.
Hai să ne cunoaștem mai bine
Pentru companie: Proba de lucru nu îi sperie pe candidați, ci ajută la reducerea numărului de interviuri.
Pentru junior: Nu copiați teste — se observă. Și mențineți-vă GitHub-ul în ordine!
Dacă am fi invitat pe toată lumea la interviuri tehnice, ar fi trebuit să avem aproximativ 40 de interviuri pe săptămână doar pentru juniori și doar pentru frontend. Prin urmare, am decis să verificăm a doua ipoteză — despre proba de lucru.
Ce era important pentru noi în proba de lucru:
- Să construim o arhitectură bună și scalabilă, dar fără supra-inginerie;
- Mai bine să dureze mai mult, dar să se facă bine, decât să creezi ceva peste noapte și să trimiti cu comentariul „cu siguranță voi termina”;
- Istoricul dezvoltării în Git — cultura ingineriei, iterativitatea dezvoltării și faptul că soluția nu a fost copiată în mod flagrant.
Ne-am pus de acord că vrem să vedem o problemă algoritmică și o aplicație web mică. Problemele algoritmice au fost pregătite la nivel de laborator pentru cursuri introductorii — căutare binară, sortare, verificare de anagrame, lucru cu liste și arbori. În final, ne-am oprit la căutarea binară ca prim variantă de probă. Aplicația web ar fi trebuit să fie X și 0 folosind orice framework (sau fără).
Proba de lucru a fost finalizată de aproape jumătate din ceilalți — am primit soluții 54 candidați. O descoperire incredibilă — cât credeți că sunt de fapt implementări de X și 0, pregătite pentru copiat, disponibile pe internet?
Câte?De fapt, pare că există doar 3. Și în majoritatea soluțiilor erau exact aceste 3 variante.
Ce nu mi-a plăcut:
- copiere, sau dezvoltare după același tutorial fără o arhitectură proprie;
- ambele probleme în același depozit în foldere diferite, fără istoricul commit-urilor, bineînțeles;
- cod murdar, încălcarea principiului DRY, lipsa de formatare;
- amestec de model, vizualizare și controller într-o singură clasă lungă de sute de linii;
- lipsa de înțelegere a testării unitare;
- soluția «în față» — hardcodarea matricei combinațiilor câștigătoare 3x3, ceea ce va fi destul de greu de extins la 10x10, de exemplu.
De asemenea, am observat atenta la repozitoriile vecine — proiectele personale grozave erau în creștere, iar o mulțime de teste de la alte companii păreau mai degrabă un semnal: de ce nu a reușit candidatul să treacă acolo?
În final, am găsit opțiuni grozave pe React, Angular, Vanilla JS — s-au strâns 29. Și am decis să invităm un alt candidat fără test pentru proiectele sale personale foarte interesante. Ipoteza noastră despre utilitatea testelor a fost confirmată.
Interviu tehnic
Pentru companie: La voi au venit nu medii/superiori! Este nevoie de mai multă abordare individualizată.
Pentru junior: Amintiți-vă că acesta nu este un examen — nu încercați să tăceți pentru a obține o notă de trecere sau să copleșiți profesorul cu toate cunoștințele voastre, astfel încât să se confunde și să vă pună „excelent”.
Ce vrem să înțelegem la interviul tehnic? Un lucru simplu — cum raționează candidatul. Probabil că deține anumite abilități tehnice, dacă a trecut etapele inițiale de selecție — rămâne să vedem dacă le poate aplica. Am convenit asupra a 3 sarcini.
Prima — despre algoritmi și structuri de date. Cu un pix, pe o foaie, în pseudocod și cu ajutorul desenelor, am discutat cum să copiem un arbore sau cum să ștergem un element dintr-o listă simplu legată. O descoperire neplăcută a fost că nu toți înțeleg recursivitatea și modul în care funcționează referințele.
A doua — live coding. Am intrat pe , am ales lucruri simple, cum ar fi sortarea unui array de cuvinte după ultima literă și, timp de 30-40 de minute, împreună cu candidatul, am încercat să facem toate testele să treacă. Părea că nu ar fi trebuit să fie surprize de la băieții care au reușit să termine X și 0 — dar, în practică, nu toți au putut înțelege că valoarea trebuie păstrată într-o variabilă, iar funcția trebuie să returneze ceva prin return. Deși sper sincer că a fost doar un moment de stres și băieții au reușit să rezolve aceste sarcini în condiții mai relaxate.
În final, a treia — puțin despre arhitectură. Am discutat despre cum ar putea fi realizată o bară de căutare, cum funcționează debounce, cum să redimensionăm diferite widget-uri în sugestiile de căutare, cum frontend-ul poate interacționa cu backend-ul. Au fost multe soluții interesante, inclusiv despre redimensionarea pe server și websocket-uri.
Am desfășurat 21 de interviuri după acest model. Publicul a fost complet divers — să luăm un exemplu din benzi desenate:
- „Racheta”. Nu se liniștește niciodată, se bagă peste tot, iar la interviu te va copleși cu un flux de gânduri, care chiar nu au legătură cu întrebarea adresată. Dacă ar fi fost la universitate, aceasta ar fi fost o încercare bine cunoscută de a demonstra toate cunoștințele tale, când de fapt, despre subiectul de examen îți amintești doar că aseară ai decis să nu-l înveți — oricum nu o vei face.
- „Groot”. Este destul de greu să intri în contact cu el, pentru că el este Groot. La interviu trebuie să te învârți mult, extrăgând răspunsuri cu cuvântul, câte unul. Este bine dacă este doar o ezitare — altfel, în munca de zi cu zi îți va fi foarte greu.
- „Drax”. A lucrat înainte în transporturi, iar din programare a învățat doar JS pe Stackoverflow, așa că nu înțelege mereu despre ce se discută la interviu. Cu toate acestea, este o persoană bună, are cele mai bune intenții și vrea să devină un frontend-er grozav.
- Și probabil, „Star-Lord”. În general, un candidat decent, cu care se poate ajunge la un acord și se poate construi un dialog.
La finalul cercetărilor noastre 7 candidați au ajuns în finală, confirmându-și abilitățile tehnice printr-o sarcină de testare grozavă și răspunsuri bune la interviu.
Corespondență culturală
Pentru companie: Vei lucra cu el! Este candidatul pregătit să lucreze extrem de mult pentru dezvoltarea sa? Va încadra el în echipă?
Pentru junior: Vei lucra cu ei! Este compania pregătită să investească în dezvoltarea juniorilor, sau pur și simplu va lăsa toată munca murdară pe umerii tăi pentru un salariu mic?
Fiecare junior, pe lângă echipa de produs, al cărei lider trebuie să fie de acord să-l ia, ajunge la un mentor. Sarcina mentorului este să-l ghideze printr-un proces de onboardare de trei luni și să-i dezvolte abilitățile tehnice. De aceea, la fiecare corespondență culturală veneam în calitate de mentori și ne puneam întrebarea: „Îmi asum responsabilitatea de a dezvolta candidatul în 3 luni conform planului nostru?”
Această etapă a decurs fără probleme și, în cele din urmă, ne-a adus 4 oferte, 3 dintre care au fost acceptate, iar băieții au intrat în echipe.
Viața după ofertă
Pentru companie: Ai grijă de juniorii tăi sau o vor face alții!
Pentru junior: AAAAAAA!!!
Când un nou angajat se alătură echipei, acesta trebuie să fie introdus în procesele interne, să i se explice cum funcționează totul în companie și în echipă, precum și cum să abordeze munca. În cazul unui junior, este important să înțelegem cum să îl dezvoltăm.
Când ne-am gândit la acest lucru, am alcătuit o listă cu 26 de abilități pe care, după părerea noastră, un junior ar trebui să le aibă la finalul celor trei luni de onboardare. Acestea includ abilități tehnice (în funcție de tehnologiile noastre), cunoștințe despre procesele noastre, scrum, infrastructură și arhitectura proiectului. Le-am organizat într-un roadmap, distribuit pe o perioadă de 3 luni.
De exemplu, acesta este roadmap-ul juniorului meu
Fiecare junior beneficiază de un mentor care colaborează cu el în mod individual. În funcție de mentor și de nivelul actual al candidaților, întâlnirile pot avea loc între 1 și 5 ori pe săptămână, câte 1 oră. Mentorii sunt frontend-iști proactivi care doresc să facă mai mult decât să scrie cod.
O parte din sarcinile mentorilor sunt preluate de cursurile despre tehnologiile noastre — Dart, Angular. Cursurile se desfășoară regulat pentru grupuri mici de 4-6 persoane, unde participanții lucrează fără a fi întrerupți de la activitatea lor.
Pe parcursul celor 3 luni, colectăm periodic feedback de la juniori, mentori și lideri, ajustând procesul individual. Odată sau de două ori în această perioadă se realizează evaluări ale abilităților dezvoltate, iar o evaluare similară se face la final — pe baza acestora se formulează recomandări pentru aspectele care necesită îmbunătățiri.
Concluzie
Pentru companie: Merită să investim în juniori? Da!
Pentru junior: Căutați companii care selectează cu atenție candidații și știu cum să îi dezvolte.
În cele 3 luni, am analizat 122 de chestionare, 54 de teste și am realizat 21 de interviuri tehnice. Acestea ne-au adus 3 juniori valoroși, care acum au parcurs jumătate din roadmap-urile lor pentru onboardare și accelerare. Ei rezolvă deja sarcini reale în proiectul nostru, unde doar pe frontend există mai mult de 2.000.000 de linii de cod și peste 400 de repozitorii.
Am constatat că procesul de selecție pentru juniori poate fi și trebuie să fie suficient de complex, dar în final prin el trec doar acei tineri care sunt cu adevărat pregătiți să muncească din greu și să investească în dezvoltarea lor.
În prezent, principala noastră sarcină este să finalizăm planurile de dezvoltare pe trei luni pentru fiecare junior, în cadrul unei colaborări individuale cu un mentor și a cursurilor generale, să strângem metrici, feedback de la lideri, mentori și de la juniorii înșiși. Acest prim experiment va putea fi considerat încheiat, putem trasa concluzii, îmbunătăți procesul și reporni selecția pentru noi candidați.
Sursa: habr.com
