Najímání IT specialistů je složitý úkol. Za prvé, na trhu dnes pociťujeme nedostatek zkušených zaměstnanců, a oni to vědí. Kandidáti často nejsou ochotni trávit hodně času "výběrovými procesy" zaměstnavatele, pokud je předem nezaujmete. Dříve populární praxe "dáme test na 8+ hodin" nyní již nefunguje. Pro prvotní hodnocení znalostí a odfiltrování kandidátů před plnohodnotným technickým pohovorem se musí používat jiné, rychlejší metody. Za druhé, pro kvalitní hodnocení znalostí a dovedností je nutné mít tyto dovednosti sami nebo zapojit kolegu, který tyto dovednosti má. Tyto obtíže lze vyřešit pomocí metod, o nichž budu hovořit v tomto článku. Sám tyto metody aplikuji a vytvořil jsem si jakési hodnocení.
Takže můj top 7 způsobů rychlé kontroly kompetencí IT specialistů před pohovorem:
7. Prozkoumat portfolio, příklady kódu, veřejné repozitáře kandidáta.
6. Krátký testovací úkol na čas (vykonává se za 30-60 minut).
5. Krátký expresní pohovor o dovednostech po telefonu/Skypu (jako dotazník, jen online a hlasem).
4. Live-Doing (Kódování) – řešíme jednoduchý úkol v reálném čase se sdílenou obrazovkou.
3. Dotazníky s otevřenými otázkami o zkušenostech.
2. Krátké testy s výběrem odpovědí, časově omezené.
1. Víceúrovňový testovací úkol, první etapa se vykonává před pohovorem.
Dále podrobněji zkoumám tyto metody, jejich výhody a nevýhody a situace, v nichž používám tuto nebo onu metodu rychlé kontroly kompetencí programátorů.
V předchozím článku o náborovém trychtýři jsem provedl průzkum mezi čtenáři o způsobech rychlé kontroly dovedností IT specialistů. V tomto článku vyprávím o způsobech, které mám osobně rád, proč se mi líbí a jak je používám. Začínám první pozicí a končím sedmou.
1. Víceúrovňový testovací úkol, první etapa se vykonává před pohovorem.
Považuji tento způsob hodnocení dovedností vývojářů za nejlepší. Na rozdíl od tradičního testovacího úkolu, kdy řeknete: "vezmi si úkol a jdi ho udělat", v mém přístupu je proces plnění testovacího úkolu rozdělen do fází – diskuse a pochopení úkolu, navrhování řešení a posuzování potřebných zdrojů, několik fází realizace řešení, dokumentace a předání řešení. Tento přístup je blíže současné normální technologii vývoje softwaru než prostě "vezmi a udělej". Podrobnosti následují.
V jakých případech používám tento způsob
Pro své projekty obvykle najímám vzdálené zaměstnance, kteří vyvíjejí samostatnou, odlišnou a relativně nezávislou část projektu. To snižuje potřebu komunikace mezi zaměstnanci, často až na nulu. Zaměstnanci nekomunikují mezi sebou, ale s projektovým manažerem. Proto je pro mě důležité hned na začátku posoudit schopnosti člověka rychle se zorientovat v úkolu, klást upřesňující otázky, samostatně vypracovat plán kroků pro vyřešení úkolu, posoudit potřebné zdroje a čas. V tom mi dobře pomáhá vícestupňový testovací úkol.
Jak realizovat
Vybereme a formulujeme samostatný a originální úkol související s projektem, na kterém bude vývojář pracovat. Obvykle popisuji jako úkol zjednodušený prototyp hlavního úkolu nebo budoucího produktu, pro jehož realizaci se vývojář bude muset setkat se základními problémy a technologiemi projektu.
Prvním krokem testovacího úkolu je seznámení se s úkolem, vyjasnění nejasností, navrhování řešení, plánování kroků k vyřešení úkolu a posouzení času potřebného na splnění jednotlivých kroků a celého testovacího úkolu. Výstupem očekávám dokument o 1-2 stránkách, kde je podrobně uveden plán kroků vývojáře a odhad času. Také žádám kandidáty, aby uvedli, který z kroků by chtěli realizovat zcela, aby potvrdili své dovednosti v praxi. Programovat zatím nic není potřeba.
Tento úkol (stejný) je zadán několika uchazečům. Očekáváme, že odpovědi uchazečů dorazí následující den. Následně, za 2-3 dny, když budou všechny odpovědi shromážděny, analyzujeme, co nám uchazeči zaslali a jaké doplňující otázky kladli předtím, než se pustili do plnění úkolu. Na základě těchto informací můžeme pozvat na další kolo libovolný potřebný počet uchazečů.
Dalším krokem je krátký pohovor. Už máme o čem mluvit. Uchazeč má už přibližnou představu o předmětu projektu, na kterém bude pracovat. Hlavním cílem tohoto pohovoru je odpovědět na technické otázky uchazeče a motivovat jej k plnění hlavního testovacího úkolu – programování té části úkolu, kterou si sám vybral. Nebo té části, jejíž realizaci chcete vidět vy.
Vždy je velmi zajímavé sledovat, kterou část úkolu se vývojář rozhodne realizovat. Někteří preferují rozpracovat strukturu projektu, dekomponovat řešení na moduly a třídy, tedy se pohybují shora dolů. Jiní vyberou specifický podúkol, který považují za nejdůležitější, aniž by popisovali celkové řešení. Tedy jdou zdola nahoru – od nejsložitějšího podúkolu k celému řešení.
Výhody
Můžeme vidět erudici uchazeče, aplikovatelnost jeho znalostí na náš projekt, rozvinutost komunikačních dovedností. Také snadno porovnáme uchazeče mezi sebou. Obvykle vyloučím ty uchazeče, kteří poskytli příliš optimistické nebo příliš pesimistické odhady času na splnění úkolu. Samozřejmě, že mám svůj vlastní odhad doby. Malý odhad uchazeče zpravidla naznačuje, že se osoba nedostatečně seznámila s úkolem a splnila tento test povrchně. Příliš velký odhad času obvykle znamená, že uchazeč má špatnou představu o předmětu, nemá zkušenosti s potřebnými tématy. Uchazeče však neodmítám okamžitě na základě jejich odhadu, ale žádám je, aby odůvodnili svůj odhad, pokud už nebyl dostatečně odůvodněn.
Někomu se tento způsob může zdát složitý a nákladný. Můj odhad náročnosti použití tohoto způsobu je takový – na popis testovacího úkolu je potřeba 30-60 minut, a poté na kontrolu odpovědí každého kandidáta 15-20 minut. Kandidátům obvykle zabere splnění takového testovacího úkolu maximálně 1-2 hodiny, přičemž se ponoří do podstaty úloh, které budou muset následně řešit. Už v této fázi může mít kandidát zájem a odradit se od další komunikace s vámi, aniž by strávil příliš mnoho času.
Nevýhody
Za prvé je třeba vymyslet originální, izolovaný a výstižný testovací úkol, což není vždy možné. Za druhé ne všichni kandidáti hned chápou, že na prvním stupni není potřeba programovat. Někteří okamžitě přistoupí k programování a zmizí na několik dní, poté pošlou zcela hotový testovací úkol. Formálně nesplnili daný testovací úkol, protože neudělali to, co od nich bylo požadováno. Ale zároveň, pokud poslali adekvátní řešení celého testovacího úkolu, tak to splnili. Abych vyloučil takovéto situace, obvykle telefonicky kontaktuji všechny kandidáty, kteří dostali úkol, po 2 dnech od jeho zadání a zjišťuji, jak na tom jsou.
2. Krátké testy s možnostmi odpovědí, časově omezené.
Tento způsob příliš často nepoužívám, i když se mi velmi líbí a považuji ho za jeden z nejlepších způsobů rychlé kontroly kompetencí. O tomto způsobu napíšu samostatný článek v blízké době. Tyto testy se široce používají v různých oblastech znalostí. Nejvýraznějším a typickým příkladem je teoretická zkouška pro získání řidičského oprávnění. V Rusku tato zkouška obsahuje 20 otázek, na které je třeba odpovědět za 20 minut. Povolená je jedna chyba. Při dvou chybách je nutné bezchybně odpovědět na 10 dalších otázek. Tento způsob se fantasticky automatizuje.
Bohužel jsem se nesetkal s dobrými realizacemi podobných testů pro programátory. Pokud znáte dobré hotové realizace podobných testů pro programátory, prosím, napište to v komentářích.
Jak realizovat
Pracoval jsem s nezávislými realizacemi podobných testů pro zaměstnavatele při plnění objednávek jako outsourcový náborář. Takový test je zcela realizovatelný. Například pomocí Google Forms. Hlavní problém spočívá v sestavování otázek a variant odpovědí. Obvykle fantazie zaměstnavatelů stačí na 10 otázek. Bohužel, v Google Forms nelze realizovat rotaci otázek z poolu a časová omezení. Pokud znáte dobrý online nástroj pro vytváření vlastních testů, kde lze omezit čas na dokončení testu a uspořádat výběr různých otázek pro různé kandidáty, napište prosím o takových službách v komentářích.
V jakých případech používám tento způsob
Teď používám tento způsob na žádost zaměstnavatelů, pokud mají připravené testy, které lze poskytnout kandidátům. Také je možné kombinovat podobné testy se čtvrtým způsobem z mého hodnocení - požádat kandidáta, aby sdílel svou obrazovku a prošel testem. Přitom můžete s ním diskutovat o otázkách a variantách odpovědí.
Výhody
Při dobré realizaci je tento způsob autonomní. Kandidát si může vybrat pohodlný čas na uskutečnění testu a vy nemusíte trávit mnoho svého času.
Nevýhody
Kvalitní realizace tohoto způsobu je poměrně nákladná a není to příliš pohodlné pro malé firmy, které zřídka najímají nové zaměstnance.
3. Dotazníky s otevřenými otázkami o zkušenostech
To je soubor otevřených otázek, které kandidátovi nabízejí, aby se zamyslel na základě své zkušenosti. Přitom nenabízíme varianty odpovědí. Otevřené otázky jsou takové, na které nelze jednoduchým a jednoznačným způsobem odpovědět. Například si vzpomeňte na nejtěžší úkol, který jste řešili s pomocí takového frameworku? V čem byla pro vás hlavní obtíž?
Jak realizovat
Snadno realizovatelné pomocí Google Forms. Hlavní je vymyslet otázky. Používám několik standardních konstrukcí.
Povězte mi o posledním projektu, který jste dělali pomocí XXX, co bylo pro vás na tomto projektu nejtěžší?
Jaké jsou podle vás hlavní výhody technologie XXX, uveďte příklady ze svých zkušeností?
Když jste si vybrali technologii XXX, jaké jiné alternativy jste zvažovali a proč jste zvolili právě XXX?V jakých situacích byste zvolili technologii AAA, a ne BBB?
Povězte nám o nejtěžším úkolu, který jste řešili pomocí XXX, v čem byla hlavní složitost?
Tyto konstrukce lze tedy aplikovat na mnoho technologií z vašeho pracovního stacku. Odpovědi na takové otázky není snadné podat pomocí vzorových frází z internetu, protože jsou osobní a vztahují se na osobní zkušenosti. Při odpovídání na tyto otázky má kandidát obvykle na paměti, že na pohovoru může každý jeho odpověď vyvolat další otázky. Proto pokud zkušenosti chybí, uchazeči se často sami vyřadí, protože pochopí, že další diskuze může být bezvýznamná.
V jakých případech používám tento způsob
Při práci s objednávkami na výběr specialistů, pokud zadavatel nenabídl vlastní způsob primární kontroly kompetencí, používám tento způsob. Mám již připravené dotazníky na řadu témat a pro mě není problém použít tento způsob pro nového zadavatele.
Výhody
Není těžké to realizovat pomocí Google Forms. Nový dotazník lze navíc vytvořit na základě předchozího, kdy nahradíme názvy technologií a nástrojů jinými. Například dotazník o zkušenostech s Reactem se moc neliší od dotazníku o zkušenostech s Angularem.
Sestavení takového dotazníku trvá 15-20 minut, a uchazeči obvykle věnují odpovědím 15-30 minut. Časové náklady jsou malé, ale získáváme informace o osobních zkušenostech uchazeče, od kterých se můžeme odrazit a učinit každý pohovor s uchazeči jedinečným a zajímavějším. Obvykle je doba pohovoru po takovém dotazníku kratší, protože není nutné pokládat jednoduché standardizované otázky.
Nevýhody
Abychom odlišili vlastní odpověď uchazeče od "googlené", musíme se vyznat v tematice. Ale to rychle přichází s zkušeností. Po zhlédnutí 10-20 odpovědí se naučíte rozlišovat originální odpovědi uchazečů od těch, které byly nalezeny na internetu.
4. Live-Doing (Kodování) – řešíme jednoduchý úkol v reálném čase se sdílenou obrazovkou
Podstatou tohoto přístupu je požádat kandidáta, aby vyřešil jednoduchý úkol, a sledovat proces. Kandidát může používat cokoliv, není zakázáno hledat informace online. Kandidát může pociťovat stres z toho, že jeho práce je sledována. Ne všichni kandidáti souhlasí s takovým způsobem hodnocení svých dovedností. Na druhou stranu tento přístup umožňuje vidět, jaké znalosti má člověk v hlavě, jaké informace bude schopen využít i ve stresové situaci a jaké informace bude hledat ve vyhledávači. Úroveň kandidáta je viditelná téměř okamžitě. Začátečníci používají nejzákladnější, dokonce primitivní možnosti jazyka, často se pokoušejí implementovat funkčnost základních knihoven ručně. Zkušení kandidáti se dobře orientují v základních třídách, metodách a funkcích a mohou rychle vyřešit jednoduchý úkol – 2-3krát rychleji než začátečníci, využívající pro ně známou funkčnost základní knihovny jazyka. Ještě více zkušení kandidáti obvykle začínají úvahami o různých přístupech k řešení úkolu a nabízejí několik variant řešení, ptají se – jakou realizaci které z variant chci vidět. Vše, co kandidát dělá, lze prodiskutovat. I na základě stejného úkolu mohou rozhovory vypadat velmi odlišně, stejně jako řešení kandidátů.
Jako variantu tohoto přístupu můžete požádat kandidáta, aby absolvoval nějaký test na ověření profesních kompetencí a zdůvodnil volbu jednotlivých odpovědí. Na rozdíl od běžného testování zjistíte, jak oprávněná byla volba odpovědí. Můžete si vymyslet své vlastní varianty tohoto přístupu s ohledem na konkrétní vlastnosti vaší pracovní pozice.
Jak realizovat
Tento přístup lze snadno realizovat pomocí Skype nebo jiného podobného systému videokonference, který umožňuje sdílení obrazovky. Úkoly si můžete vymyslet sami nebo využít platformy jako Code Wars, různé hotové testy.
V jakých případech používám tento způsob
Když vybírám programátory a z životopisu je zcela nejasné, jaká je úroveň znalostí uchazeče, nabízím uchazečům pohovor v takovém formátu. Podle mých zkušeností – přibližně 90 % vývojářů nemá proti tomu nic. Je jim příjemné, že od prvního pohovoru začíná diskuze o programování, a ne hloupé otázky typu „kým se vidíte za 5 let“.
Výhody
I přes stres a nervozitu uchazeče je okamžitě vidět celková úroveň dovedností kandidáta. Také jsou dobře patrné komunikační dovednosti uchazeče – jak uvažuje, jak vysvětluje a motivuje své odpovědi. Pokud je potřeba uchazeče probrat s kolegy, není problém si nahrát videonahrávku ze své obrazovky a pak pohovor ukázat ostatním.
Nevýhody
Spojení může být přerušeno. Kvůli nervozitě může uchazeč začít zmatkovat. V takové situaci lze přerušit a dát mu čas na přemýšlení o úkolu o samotě, zavolat za minut 10 a pokračovat. Pokud i poté uchazeč reaguje podivně, je dobré vyzkoušet jiný způsob hodnocení dovedností.
5. Krátký expresní pohovor o dovednostech po telefonu/Skype
Je to jen rozhovor hlasem po telefonu, Skypu nebo jiném systému hlasové komunikace. Při tom můžeme posoudit komunikační dovednosti uchazeče, jeho erudici a rozhled. Jako plán rozhovoru lze použít dotazník. Alternativně lze podrobněji probrat s kandidátem jeho odpovědi na váš dotazník.
Jak realizovat
Domlouváme se s uchazečem na rozhovoru a voláme. Klade se otázky, zaznamenáváme odpovědi.
V jakých případech používám tento způsob
Tento způsob obvykle aplikuji spolu s dotazníkem, když mi jeho odpovědi přišly originální nebo nedostatečně přesvědčivé. Diskutuji s uchazečem kolem otázek z dotazníku a zjišťuji jeho názory podrobněji. Považuji takový rozhovor za nezbytný, když jsou důležité komunikační dovednosti uchazeče a schopnost jednoduše a srozumitelně formulovat své myšlenky.
Výhody
Bez hlasového rozhovoru na profesionální témata obvykle nelze určit, jak dobře uchazeč umí formulovat své myšlenky.
Nevýhody
Hlavní nevýhodou jsou dodatečné časové náklady. Proto tento způsob používám jako doplněk k jiným, pokud je to nezbytné. Kromě toho existují kandidáti, kteří skvěle hovoří o odborných tématech, ale v praxi toho umí málo. Pokud potřebujete programátora, který bude úkoly plnit stabilně a kvalitně, je lepší zvolit jiný způsob prvotního ověřování kompetencí. Pokud potřebujete manažera nebo analytika, tedy specialistu, který překládá z lidského jazyka do 'programátorského' a zpět, pak bude tento způsob ověřování kompetencí velmi užitečný.
6. Krátký testovací úkol na čas (provádí se za 30-60 minut)
Pro řadu profesí je důležité umění specialisty rychle nalézt řešení úkolu. Obvykle se řeší jednodušší úkoly, ale čas na řešení úkolu je důležitý.
Jak realizovat
Domlouváme se s kandidátem na čas provedení testovacího úkolu. V určenou dobu posíláme kandidátovi podmínky úkolu a zjišťujeme, zda pochopil, co se od něj požaduje. Měříme čas, který kandidát strávil řešením úkolu. Analyzujeme řešení a čas.
V jakých případech používám tento způsob
V mé praxi byla tato metoda použita k ověřování kompetencí specialistů technické podpory, SQL programátorů a testerů (QA). Úkoly byly typu 'najdi problémová místa a vymysli, jak problém odstranit', 'optimalizuj SQL dotaz, aby fungoval třikrát rychleji' atd. Samozřejmě můžete vymyslet své úkoly. Tento způsob lze také použít pro začínající vývojáře.
Výhody
Ztrácíme čas pouze na sestavení a ověření úkolu. Kandidát si může vybrat vhodný čas pro splnění úkolu.
Nevýhody
Hlavní nevýhoda spočívá v tom, že na internetu mohou být zveřejněna řešení vašich úkolů nebo podobných, a proto je nutné mít určité množství variant a pravidelně vymýšlet nové úkoly. Pokud je třeba testovat reakční rychlost a rozhled, osobně volím testy na čas (metoda č. 2).
7. Prozkoumat portfolio, příklady kódu, veřejné repozitáře kandidáta
To je snad nejjednodušší způsob ověřování kompetencí, za předpokladu, že vaši kandidáti mají portfolio a že ve vašem týmu pro selekci jsou specialisté schopní portfolio ohodnotit.
Jak realizovat
Zkoumáme životopisy uchazečů. Pokud najdeme odkazy na portfolio, prozkoumáme je. Pokud v životopise nejsou uvedeny žádné pokyny na portfolio, požádáme uchazeče o jeho zaslání.
V jakých případech používám tento způsob
V mé praxi se tento způsob používal velmi zřídka. V portfoliích uchazečů není často možné nalézt práce na dané téma. Zkušení uchazeči často dávají přednost tomuto způsobu před standardním a nezajímavým testovacím úkolem. Říkají: „Podívejte se na můj rep, tam je desítky příkladů mých řešení různých úloh, uvidíte, jak píšu kód.“
Výhody
Šetří se čas uchazečů. Při dostatečné možnosti času profesionálů ve vaší týmu je možné rychle a bez komunikace s uchazeči vyřadit nevhodné. Zatímco náborář hledá uchazeče, jeho kolega hodnotí portfolio. Vzniká tak dostatečně rychlá a paralelní práce.
Nevýhody
Tento způsob nelze aplikovat na všechny IT profese. Pro hodnocení portfolia je nutné mít sám vyvinuté dovednosti. Pokud nejste odborník, nebudete schopni kvalitně posoudit portfolio.
Kolegové, zvu vás k diskusi o přečteném v komentářích. Jaké další způsoby rychlé kontroly kompetencí používáte?
Zdroj: habr.com
