Si e shëndoshë një junior?

Si të hyni në një kompani të madhe, nëse jeni junior? Si të punësoni një junior të denjë, nëse jeni një kompani e madhe? Nën kat do të tregoj historinë tonë të punësimit të fillestarëve në frontend: për atë si punuam mbi detyrat testuese, u përgatitëm për të zhvilluar intervista dhe ndërtuam një program mentorimi për të zhvilluar dhe përfshirë fillestarët, si dhe pse pyetjet standarde për intervista nuk funksionojnë.

Po përpiqem të tame një junior.

Përshëndetje! Unë quhem Pavel, po punoj në frontend në ekipin Wrike. Po krijojmë një sistem për menaxhimin e projekteve dhe bashkëpunimin. Kam punuar në web që nga viti 2010, kam punuar për 3 vjet në një kompani ndërkombëtare nga distanca, kam marrë pjesë në disa startup-e dhe kam dhënë një kurs mbi teknologjitë web në universitet. Në kompaninë tonë marrë pjesë në zhvillimin e kurseve teknike dhe programit të mentorimit Wrike për juniorët, si dhe rekrutimin e tyre.

Përse menduam ndonjëherë për punësimin e juniorëve?

Derisa kohët e fundit kemi punësuar zhvillues frontend nga niveli middle ose senior — mjaft të pavarur për të kryer detyrat e produktit pas përfshirjes. Në fillim të këtij viti kuptuam se donim të ndryshonim këtë politikë: gjatë një viti numri i grupeve tona të produkteve ka rritur gati dy herë, numri i frontend-ëve ka arritur në një qind, dhe në një të ardhme të afërt gjithçka duhet të dyfishohet sërish. Ka shumë punë, pak duar të lira, dhe në treg ka edhe më pak, prandaj vendosëm të drejtohemi te ata që sapo kanë filluar rrugën e tyre në frontend dhe kuptuam se ishim të gatshëm të investonim në zhvillimin e tyre.

Kush është një junior?

Ky është pyetja e parë që na bëmë. Ka kritere të ndryshme, por principi më i thjeshtë dhe i kuptueshëm është ky:

Njohuritë e një juniori duhet të shpjegohen se cilën funksionalitet duhet të realizojë dhe si. Një mid-level duhet të kuptojë se cila është funksionaliteti që nevojitet dhe do e menaxhojë vetë realizimin. Një senior do t'ju shpjegojë pse ky funksionalitet nuk duhet bërë fare.

Në një mënyrë ose një tjetër, një junior është ai zhvillues që ka nevojë për këshilla se si të realizojë zgjidhjen përkatëse. Nga çfarë kemi vendosur të fillojmë:

1. Një junior është ai që dëshiron të zhvillohet dhe është i gatshëm të punojë shumë për këtë;
2. Ai nuk di gjithmonë se në cilën drejtim dëshiron të zhvillohet;
3. Ka nevojë për këshillë dhe kërkon ndihmë nga jashtë — nga udhëheqësi i tij, mentori ose nga komuniteti.

Po gjithashtu kishim disa hipoteza:

1. Për poziten e juniorëve do të ketë një stuhi të reagimeve. Duhet të filtrojmë reagimet rastësore që në fazën e dërgimit të CV-ve;
2. Filtri fillestar nuk do të ndihmojë — na duhen edhe disa teste;
3. Testet do t’i trembin të gjithë — ato nuk janë të nevojshme.

Natyrisht, ne patëm një qëllim: 4 juniorë në 3 javë.

Me këtë ndërgjegje filluam të eksperimentojmë. Plani ishte i thjeshtë: të fillonim me një gyp sa më të gjerë dhe të provonim ta ngushtonim gradualisht në mënyrë që të mund të përballonim fluksin, por pa e zvogëluar atë në 1 kandidat në javë.

Vendosim shpalljen e punës

Për kompaninë: Do të ketë qindra reagime! Mendoni për filtrin.

Për juniorin: Mos kini frikë nga anketa para dërgimit të CV-së dhe testeve — kjo është një shenjë që kompania kujdeset për ju dhe ka organizuar mirë procesin.

Në ditën e parë, morëm rreth 70 CV nga kandidatët "me njohuri në JavaScript". Pastaj edhe më shumë. E kemi fizikisht të pamundur të thërrasim të gjithë për intervistë në zyrë dhe zgjodhëm nga ata djemtë me projektet më interesante, një GitHub aktiv ose të paktën përvojë.

Por përfundimi kryesor që ne bëmë në ditën e parë — stuhi ka filluar. Koha ka ardhur për të shtuar një formë ankete para dërgimit të CV-ve. Qëllimi i saj ishte të përjashtonte kandidatët që nuk ishin të gatshëm të bënin përpjekje minimale për dërgimin e CV-së, dhe ata që nuk kishin njohuri dhe kontekst të paktën në atë masë për të kërkuar përgjigjet e sakta.

Në të kishte pyetje standarde mbi JS, kodimin, webin, Informatikën — i di çdo kush që e di se çfarë pyetet në një intervistë në frontend. Çfarë është ndarja let/var/const? Si të aplikoni stilet vetëm për ekranet më të vogla se 600px në gjerësi? Nuk doja t'i bëja këto pyetje gjatë intervistës teknike — praktika tregoi se mund të përgjigjesh në to pas 2-3 intervistash, pa kuptuar plotësisht zhvillimin. Por, ato ishin në gjendje të na tregojnë fillimisht nëse kandidati kupton përgjithësisht kontekstin.

Në çdo kategori, kemi përgatitur 3-5 pyetje dhe ditë pas dite ndërronim setin e tyre në formën e përgjigjes, derisa përjashtuam ato më të lehtat dhe më të vështirat. Kjo na lejoi të pakësojmë fluksin — brenda 3 javëve morëm 122 kandidatë, me të cilët mund të punonim më tej. Ishin studentë IT; djem që dëshironin të kalonin nga backend në frontend; punëtorë ose inxhinerë të moshës 25–35 vjeçare që kishin dëshiruar të ndryshonin radikalisht drejtimin e veprimtarisë dhe kishin bërë përpjekje të ndryshme për vetëarsim, kurse dhe praktikë.

Ta njohim më mirë

Për kompaninë: Detyra testuese nuk i frikëson kandidatët, por ndihmon të shkurtohet procesi.

Për juniorin: Mos kopjoni detyrat testuese — kjo është e dukshme. Dhe mbani rregull të mjaftueshëm në GitHub-in tuaj!

Nëse do të kishim thirrur të gjithë për një intervistë teknike, do të na duhej të zhvillonim afërsisht 40 intervista në javë vetëm për juniorët dhe vetëm në frontend. Prandaj vendosëm të kontrollonim hipotezën e dytë — për detyrën testuese.

Çfarë ishte e rëndësishme për ne në teste:

1. Të ndërtojmë një arkitekturë të mirë dhe të shkallëzuar, por pa e tepruar;
2. Më mirë të punosh më shumë, por të bësh mirë, sesa të bësh një punë të shpejtë e të dërgosh me komentarin «do ta përfundoj patjetër»;
3. Historia e zhvillimit në git — kultura inxhinierike, iterativiteti i zhvillimit dhe fakti që zgjidhja nuk është kopjuar në mënyrë të turpshme.

Ne u pajtuam që dëshironim të shihnim një detyrë algoritmike dhe një aplikacion të vogël web. Detyrat algoritmike ishin përgatitur në nivelin e laboratorëve të kurseve fillestare — kërkimi binar, renditja, kontrolli i anagramëve, puna me lista dhe pemë. Në fund, u ndaluam te kërkimi binar si opsioni i parë për provë. Aplikacioni web duhej të ishte tic-tac-toe duke përdorur ndonjë framework (ose pa të).

Gati gjysma e djemve të mbetur e përfunduan detyrën testuese — na dërguan zgjidhjet 54 kandidatë. Një insight i pabesueshëm — sipas jush, sa realizime të tic-tac-toe, të gatshme për kopjim, ka në internet?

Sa?Në të vërtetë, duket se ka vetëm 3. Dhe në shumicën dërrmuese të zgjidhjeve ishin pikërisht këto 3 variante.
Çfarë nuk më pëlqeu:

• kopjim, ose zhvillim nga i njëjti tutorial pa një arkitekturë të vetme;
• të dy detyrat në të njëjtin repository në dosje të ndryshme, me histori commitësh që sigurisht nuk ka;
• kod i papastër, shkelje e DRY, mungesë formatimi;
• përzierje e modelit, pamjeve dhe kontrolluesit në një klasë me gjatësi qindra linjash kodi;
• mungesë e kuptimit të testeve të njësi;
• zgjidhja "në një goditje" — hardkodi i matricës së kombinimeve fituese 3x3, që do të jetë mjaft e vështirë për t'u zgjeruar në 10x10, për shembull.

Po ashtu, ne kemi vënë re repo të tjera — projektet e bukura të përkushtimit po ecnin përpara, ndërsa një mori detyrash testuese nga kompani të tjera ishin më shumë një sinjal: pse kandidati nuk arriti të kalojë atje?

Si rezultat gjetëm disa mundësi të shkëlqyera në React, Angular, Vanilla JS — u grumbulluan 29 të tilla. Dhe një kandidatë tjetër vendosëm ta ftojmë pa test se projektet e tij të përkushtimit ishin shumë të mira. Hipoteza jonë për përfitimin nga detyrat testuese u konfirmua.

Intervista teknike

Për kompaninë: Nuk erdhën midhla / të moshenjësit! Duhet më shumë qasje individuale.

Për juniorin: Mos harroni, që kjo nuk është një provim — mos u përpiqni të heshtni për një notë mesatare ose të shkurtoni profesorin me gjithçka që dini, në mënyrë që ai të ngatërohet dhe të japë "shkëlqyer".

Çfarë dëshirojmë të kuptojmë në intervistën teknike? Një gjë të thjeshtë — si mendon kandidati. Probabil u ka ndonjë aftësi të fortë, nëse kaloi fazat e para të përzgjedhjes — mbetet të zbulojmë nëse di t'i aplikojë ato. U vendosëm për 3 detyra.

E para — për algoritmet dhe strukturat e të dhënave. Me stilolaps, në një letër, në një pseudogjuhë dhe me ndihmën e vizatimeve ne shikuam se si të kopjojmë një pemë ose si të heqim një element nga një listë e lidhur. Një zbulim i pakëndshëm ishte që nuk të gjithë kuptojnë rekurzionin dhe se si funksionojnë lidhjet.

E dyta — kodim i drejtpërdrejtë. Ne hynim në codewars.com, zgjidhnim gjëra të thjeshta si renditja e një varg fjalësh sipas shkronjës së fundit dhe për 30-40 minuta bashkë me kandidatin, përpiqeshim t'i kalonim të gjitha provat. Dukej se nuk duhet të kishte surpriza nga djemtë që kishin përfunduar xhdo-nuk — por në praktikë, jo të gjithë kuptuan se vlera duhet të ruhej në një ndryshore dhe funksioni duhet të kthejë diçka përmes return. Megjithatë, shpresoj se ishte nervozizëm, dhe djemtë kanë mundësinë të zgjidhin këto detyra në kushte më të lehta.

Më në fund, e treta — pak për arkitekturën. Diskutuam se si mund të bëhet një kat për kërkimin, si funksionon debounce, si të renditen ndryshmet në rekomandimet e kërkimit, si frontend mund të bashkëveprojë me backend-in. U gjetën zgjidhje të shumta interesante, përfshirë renderimin në server dhe websockets.

Ne kemi zhvilluar 21 intervista në këtë format. Publiku ishte absolutisht i larmishëm — le të flasim për komikët:

1. «Raketa». Kurrë nuk qetësohet, ngacmon kudo, dhe gjatë intervistës do t'ju mbushë me një rrjedhë mendimesh që as nuk lidhen drejtpërdrejt me pyetjen e parashtruar. Po të shkonte në universitet, kjo do të ishte një përpjekje e njohur për të demonstruar të gjitha njohuritë e tij, kur në fakt nuk e mban mend më shumë se sa vendoset të mos e studiojë — prapë se prapë, nuk do të arrijë dot.
2. «Groot». Është mjaft e vështirë të krijosh kontakt, sepse ai është Groot. Gjatë intervistës, duhet shumë kohë për ta bërë të flasë, duke nxjerrë përgjigje fjalë për fjalë. Mirë është nëse është thjesht një ngërç — ndryshe, më pas do t'ju jetë shumë e vështirë në punë të përditshme.
3. «Drax». Disa herë merrej me transportin, dhe nga programimi kishte mësuar vetëm JS nga Stackoverflow, prandaj nuk e kupton gjithmonë se për çfarë po flitet në intervistë. Megjithatë, është një person i mirë, ka qëllime të mira dhe dëshiron të bëhet një frontender i shkëlqyer.
4. Ndoshta dhe «Lord Star». Në përgjithësi, një kandidat i mirë, me të cilin mund të arrijmë një marrëveshje dhe të ndërtojmë dialog.

Në fund të hulumtimeve tona 7 kandidatë arritën në finale, duke konfirmuar aftësitë e tyre të forta me një detyrë testuese të shkëlqyer dhe përgjigje të mira gjatë intervistës.

Përshtatja kulturore

Për kompaninë: Ka për të punuar me ty! A është kandidati gati të punojë ekstremisht shumë për zhvillimin e tij? A është i sigurt se do të përfshihet në ekip?

Për juniorin: Do të punoni me ata! A është kompania gati të investojë në rritjen e juniorëve, apo thjesht do t'ju hedhë gjithë punën e ndyrë me një pagë të ulët?

Çdo junior përveç ekipit të produktit, të cilit lideri duhet ta pranojë, kalon te një mentor. Detyra e mentorit është ta kalojë atë përmes një processi tre mujor onboarding dhe zhvillimi i aftësive të forta. Prandaj, për çdo përshtatje kulturore vinin si mentorë dhe pyetnim veten: «A do të marrë mbi vete përgjegjësinë për të zhvilluar kandidatin për tre muaj në planin tonë?»

Ky fazë kaloi pa ndonjë veçanti dhe në fund na solli 4 oferta, 3 prej të cilave u pranuan, dhe djemtë u bënë pjesë e ekipeve.

Jeta pas ofrimit

Për kompaninë: Kujdesuni për juniorët tuaj ose do t'i bëjnë tjerë!

Për juniorin: AAAA! AAAA! AAAA!

Kur të dalë një punonjës i ri, është e nevojshme të bëhet onboarding — të njihet me proceset, të tregohet si funksionon gjithçka në kompani dhe në ekip dhe si duhet të punojë ai në përgjithësi. Kur del një junior, është e rëndësishme të kuptohet si mund të zhvillohet ai.

Kur mendojmë për këtë, kemi formuar një listë prej 26 aftësish që, sipas mendimit tonë, një junior duhet të ketë deri në fund të periudhës tri mujore të onboarding-ut. Këtu përfshihen hard-skills (sipër bazës sonë), njohuritë mbi proceset tona, Scrum-in, infrastrukturën, arkitekturën e projektit. Kemi bashkuar këto në një roadmap, të shpërndarë gjatë 3 muajve.

Për shembull, ja roadmap-i i juniorit tim.

Çdo junior ka një mentor të caktuar, i cili punon me të në mënyrë individuale. Në varësi të mentorit dhe nivelit aktual të kandidatit, takimet mund të ndodhin nga 1 deri në 5 herë në javë për 1 orë. Mentorët bëhen me vullnet të plotë frontend-istë që duan të bëjnë diçka më shumë se thjesht të shkruajnë kod.

Disa nga ngarkesat e mentorëve lehtësohen nga kurset për bazën tonë të teknologjive — Dart, Angular. Kurset organizohen rregullisht për grupe të vogla prej 4-6 njerëzish, ku nxënësit punojnë pa ndërprerë nga puna.

Gjatë 3 muajve, ne periodikisht mbledhim feedback nga juniorët, mentorët e tyre dhe liderët dhe rregullojmë procesin në mënyrë individuale. 1-2 herë gjatë gjithë periudhës bëhet një kontroll i aftësive të përmirësuara, një kontroll i tillë bëhet në fund — mbi të cilin formohen rekomandimet për atë që duhet përmirësuar.

Përfundim

Për kompaninë: A duhet të investohet në juniorë? Po!

Për juniorin: Kërkoni kompani që përzgjedhin me kujdes kandidatët dhe dinë si t'i zhvillojnë ata.

Në tre muaj kemi shqyrtuar 122 pyetësorë, 54 detyra testuese dhe kemi zhvilluar 21 intervista teknike. Kjo na ka sjellë 3 juniorë të shkëlqyer që tashmë kanë kaluar gjysmën e roadmap-eve të tyre për onboarding dhe akselerim. Ata tashmë po zgjidhin detyra reale produkti në projektin tonë, ku vetëm në frontend janë më shumë se 2,000,000 rreshta kodi dhe më shumë se 400 depo.

Kemi zbuluar se kanali për juniorët mund dhe duhet të jetë mjaft i komplikuar, por në fund vetëm ata djem që janë vërtet gati të punojnë shumë dhe të investojnë në zhvillimin e tyre kalojnë përmes tij.

Aktualisht, objekti ynë kryesor është përfundimi i planit të zhvillimit për çdo junior në një periudhë tre mujore, duke punuar individualisht me një mentor dhe përmes kurseve të përbashkëta, mbledhja e metrikeve, feedback-ut nga liderët, mentorët dhe vetë studentët. Në këtë pikë, eksperimentin e parë mund ta quajmë të përfunduar, për të nxjerrë përfundime, për të përmirësuar procesin dhe për ta nisur atë përsëri për përzgjedhjen e kandidatëve të rinj.

Burimi: habr.com