 |
| Image courtesy of Michal Marcol FreeDigitalPhotos.net |
Hned od počátku jsem měl štěstí, že mi nikdo nemluvil do toho, jak má interview vypadat. A jsem za tu důvěru vděčný. Taková svoboda mi vyhovuje, takže jsem si jednotlivé kroky pohovoru sestavil a vymyslel podle sebe.
Není to úplně jednoduchá věc, začít takhle z ničeho - není na to žádný mustr, informací je pomálu, není se moc koho zeptat, protože HR vám nejspíš neporadí a ten kdo dělal technický pohovory před váma, už nejspíš ve firmě nepracuje.
Proč nedávám testy
Jednu věc jsem věděl jistě - nechci používat žádné testy. Je s podivem, jak moc jsou testy na pohovorech rozšířené. Protože když uvážíme, jak malou mají, v daném kontextu, vypovídací hodnotu (osobně bych dokonce řekl mizivou) a jak velkou vyžadují režii na údržbu, aby aspoň k něčemu byly; člověk by řekl, že to za to nestojí.
Trochu to chápu. Když už jednou někdo ty testy vytvoří, tak je může dát kandidátovi klidně slečna z HR. On už to pak někdo vyhodnotí. Takže na první pohled se to zdá jako jednoduchý, efektivní a objektivní způsob ohodnocení kandidáta. Ani jedno z toho není pravda.
V první řadě, testy testují něco, na co kandidát téměř jistě nebyl připravený. Je téměř jisté, že ten obskurní syntaktický příklad, který v testu máte, nikdy v životě v praxi nepotkal. Ať už vám ta "chytrá" knížka, nebo internet, podle kterých jste to sestavili, tvrdí cokoliv. A nejde jen o to, že jsou příklady vycucané z prstu, problém je, že se na ně nedá nijak připravit - když si chci udělat certifikaci, vím, co se potřebuju naučit, jaký bude rozsah, co se dá použít ke studiu apod. Když jdu na pohovor, nevím nic - dostanu (nejspíš nekvalitní) test a záleží jen na štěstí, nakolik se moje zkušenost z obrovského Java kontinentu kryje s tématy v testu.
Šíře Java landscape je další problém. Co chcete vměstnat do rozumné délky testu? Dejme tomu, že by test měl trvat hodinu, předpokládaný čas na otázku je tři minuty (takže kandidát nad tím nebude moc přemýšlet a jen vysype z hlavy, na co si vzpomene), což vychází na 20 otázek. Kolik otázek věnujete Java SE? Kolik Java EE, kolik Springu? A co něco souvisejícího, třeba databáze, nebo skriptování? Taky máte dojem, že to jen škrábete po povrchu?
Možná si říkáte, zaměříme se jen na technologie, které používáme. OK, používáme na projektech Spring, tak budou testy o Springu. Právě jste se připravili o polovinu schopných lidí, kteří by u vás mohli pracovat. Na druhou stranu, třeba to tak chcete - jednodruhové, vyšlechtěné, single-malt vývojáře.
Dalším problémem testů je jejich aktuálnost. Jak často vychází major verze nějakého frameworku/platformy? Když vezmu v potaz Java EE (verze 5 až 7), tak za poslední čtyři roky bych takový test musel předělat dvakrát až třikrát (beru v úvahu, že reálné využití se nekryje s vydáním specifikace). Kdybych řešil jen Spring (verze 2.5-4.0), jsem na tom podobně.
A zmíním ještě jednu věc. Máte uni-sex testy "one-size-fits-all", které dáváte všem, bez ohledu na úroveň seniority? Máte pro každou senioritu zvláštní test? Jestli chcete dělat testy v rozumné kvalitě, budete s tím mít dost práce.
Byl to ale velmi specifický případ. Měl jsem možnost podílet se na nabírání Java vývojářů na Filipínách. Nabírat vývojáře na druhé straně světa není úplně jednoduché. Jádrem přijímacího procesu byl osobní pohovor, kdy za stranu zaměstnavatele se na něm podílely osoby z Česka (já), Francie a USA. Když už si to konečně naplánujete interně, že se sejdete na druhé straně glóbu, je podstatný, aby vám na pohor přišli už jenom relevantní lidé.
První filtrování udělalo místní HR. Jako druhý filtr jsem navrhoval klasický phone screen, ale vzhledem k časovému posunu (Česko-Filipíny +7 hodin) jsme se nakonec shodli právě na testech - hlavně z důvodu jejich asynchronicity. Napsal jsem tedy (s vydatnou a převážnou pomocí kolegy Bantera) test, který by byl takovým "rozumným" filtrem. Opravdu jenom filtrem, nic víc - pokud někdo neprošel testem, nemělo smysl se s ním vidět osobně.
Na tomto testu jsou podstatné tři věci, které ospravedlňují jeho existenci: kontext, účel a trvanlivost. Kontext je, myslím, jasný - pohovory na jiném kontinentu zkrátka normálně nedělám. Účel jsem už také zmínil, šlo o pouhý filtr, při celkovém hodnocení kandidáta jsem k testu nijak nepřihlížel. No a "trvanlivost" - šlo o jednorázovou záležitost, ten test jsem od té doby neviděl, vidět nechci a kdyby náhodou, bylo potřeba řešit najímání vývojářů v Jižní Americe ;-) začal bych ze stejné pozice: testy raději ne.
V první řadě, testy testují něco, na co kandidát téměř jistě nebyl připravený. Je téměř jisté, že ten obskurní syntaktický příklad, který v testu máte, nikdy v životě v praxi nepotkal. Ať už vám ta "chytrá" knížka, nebo internet, podle kterých jste to sestavili, tvrdí cokoliv. A nejde jen o to, že jsou příklady vycucané z prstu, problém je, že se na ně nedá nijak připravit - když si chci udělat certifikaci, vím, co se potřebuju naučit, jaký bude rozsah, co se dá použít ke studiu apod. Když jdu na pohovor, nevím nic - dostanu (nejspíš nekvalitní) test a záleží jen na štěstí, nakolik se moje zkušenost z obrovského Java kontinentu kryje s tématy v testu.
Šíře Java landscape je další problém. Co chcete vměstnat do rozumné délky testu? Dejme tomu, že by test měl trvat hodinu, předpokládaný čas na otázku je tři minuty (takže kandidát nad tím nebude moc přemýšlet a jen vysype z hlavy, na co si vzpomene), což vychází na 20 otázek. Kolik otázek věnujete Java SE? Kolik Java EE, kolik Springu? A co něco souvisejícího, třeba databáze, nebo skriptování? Taky máte dojem, že to jen škrábete po povrchu?
Možná si říkáte, zaměříme se jen na technologie, které používáme. OK, používáme na projektech Spring, tak budou testy o Springu. Právě jste se připravili o polovinu schopných lidí, kteří by u vás mohli pracovat. Na druhou stranu, třeba to tak chcete - jednodruhové, vyšlechtěné, single-malt vývojáře.
Dalším problémem testů je jejich aktuálnost. Jak často vychází major verze nějakého frameworku/platformy? Když vezmu v potaz Java EE (verze 5 až 7), tak za poslední čtyři roky bych takový test musel předělat dvakrát až třikrát (beru v úvahu, že reálné využití se nekryje s vydáním specifikace). Kdybych řešil jen Spring (verze 2.5-4.0), jsem na tom podobně.
A zmíním ještě jednu věc. Máte uni-sex testy "one-size-fits-all", které dáváte všem, bez ohledu na úroveň seniority? Máte pro každou senioritu zvláštní test? Jestli chcete dělat testy v rozumné kvalitě, budete s tím mít dost práce.
Co nějaká výjimka?
V tom, proč nedávat testy bych se mohl pitvat ještě dlouho, ale myslím, že pár zdatných (a dostačujících) důvodů jsem uvedl. Na druhou stranu, přeci jenom, nenašel by se nějaký případ, kdy testy u pohovoru dávají smysl? Přiznám se, nedávno jsem testy taky jednou použil. Či spíše přesněji: akceptoval je a podílel se na nich.Byl to ale velmi specifický případ. Měl jsem možnost podílet se na nabírání Java vývojářů na Filipínách. Nabírat vývojáře na druhé straně světa není úplně jednoduché. Jádrem přijímacího procesu byl osobní pohovor, kdy za stranu zaměstnavatele se na něm podílely osoby z Česka (já), Francie a USA. Když už si to konečně naplánujete interně, že se sejdete na druhé straně glóbu, je podstatný, aby vám na pohor přišli už jenom relevantní lidé.
První filtrování udělalo místní HR. Jako druhý filtr jsem navrhoval klasický phone screen, ale vzhledem k časovému posunu (Česko-Filipíny +7 hodin) jsme se nakonec shodli právě na testech - hlavně z důvodu jejich asynchronicity. Napsal jsem tedy (s vydatnou a převážnou pomocí kolegy Bantera) test, který by byl takovým "rozumným" filtrem. Opravdu jenom filtrem, nic víc - pokud někdo neprošel testem, nemělo smysl se s ním vidět osobně.
Na tomto testu jsou podstatné tři věci, které ospravedlňují jeho existenci: kontext, účel a trvanlivost. Kontext je, myslím, jasný - pohovory na jiném kontinentu zkrátka normálně nedělám. Účel jsem už také zmínil, šlo o pouhý filtr, při celkovém hodnocení kandidáta jsem k testu nijak nepřihlížel. No a "trvanlivost" - šlo o jednorázovou záležitost, ten test jsem od té doby neviděl, vidět nechci a kdyby náhodou, bylo potřeba řešit najímání vývojářů v Jižní Americe ;-) začal bych ze stejné pozice: testy raději ne.
Výzva
Jestli děláte pohovory a dáváte na nich testy - zkuste se nad těmi testy zamyslet. Dávájí vám to, co od nich očekáváte? Je nějaká jiná cesta, jak dosáhnout stejného výsledku? Troufám si tvrdit, že bez testů se vám podaří najmout kvalitnější lidi. Zkuste to, jen tak se posunete dál.Mind Map
a co treba test, jestli ten clovek dokaze logicky uvazovat a jestli umi analyzovat problem?
OdpovědětVymazatco jsem slysel, nekde davali jako test nejakou slozitejsi obdobu problemu prevoznika, vlka, kozy, zeli.
Tak tam ti hrozi, ze do firmy vezmes cloveka co vie dobre uvazovat, ale vobec nie je dobry SW engineer. Teda vezmes matfyzaka ktory je mudry, ale mozno ta porazi ked zbadas jeho kod :)
Vymazatno po tomhle logickem testu uz nasleduje normalni pohovor viz. autor clanku.
Vymazatdotaz: muze byt nekdo kdo test s prevoznikem nezvladne, ale pritom je dobry SW engineer?
Ale uvedom si, ze dobry programator ma X firiem ktore o neho maju zaujem. Ak chces 60 minut jeho casu tak ten pohovor vyuzi uzitocne. Ked sa ma firma na pohovore pyta kokotiny typu prevoznik tak vidim, ako efektivne vedia hospodarit s casom ...
VymazatMyslím, že tyhle logické úlohy jsou podobně "objektivní" jako testy - my dopředu známe (většinou jednu) správnou odpověď a kandidát ji buď už zná taky, anebo nezná a zkusí ji na pohovoru (většinou ve stresu) vymyslet.
VymazatKaždopádně, výsledkem je, že ověříme, že kandidát pravděpodobně umí řešit logické úlohy. Ale korelace s kvalitou kandidáta jako vývojáře/SW inženýra bude dost nejistá.
my pouzivame testy, ktore sme si pisali sami a su v nich len zaklady javy a roznych kniznic.
OdpovědětVymazatnijak to nebodujeme - sluzi nam to len na overenie toho, ci kandidat ma aspon nejake skusenosti s technologiami, ktore ma v CV. veci, ktore tam nema ignorujeme a cely test s nim vyhodnocujeme a davame doplnujuce otazky pri pohovore
Suhlasim. Testy su shit. Zbytocne kandidata stresuju a su hrozne neosobne. Lepsia je diskusia a korigovat ju potrebnym smerom. Ked niekto robil so Springom tak sa pytam na to a idem do takej hlbky kym sa kandidat chyta.
OdpovědětVymazatPodle mě testy jdou skutečně použít jen jako filtr na rádobyvývojáře kteří jediné co umí je copy&paste vygooglovaných ukázek bez toho aby jim rozuměli. Zkusil bych to s klasickou teorií algoritmů - časová náročnost, paměťová náročnost. Základní datové struktur (v prostředí Javy jsou to Collections), rozdíly mezi konkrétními implementacemi s ohledem na jejich efektivitu pro různá použití. K tomu nějaké obecné dotazy na OOP, když už jde o Javu. Kdo tyhle základy neovládá tak bude velmi špatně použitelný i jako junior.
OdpovědětVymazatMyslím, že otázky na pohovoru by měly být co nejblíž tomu, co pak bude kandidát dělat běžně, děnně v práci - pokud dělám embedded systémy, můžou být věci kolem paměťové náročnosti a efektivnosti algoritmů kritické. Pokud dělám enterprise/webovou Javu, budou spíše druhořadé.
VymazatBohove, chrante nas od proramatoru, pro ktere je pametova narocnost v enterprise aplikacich druhorada!
VymazatNa otázky na asymptotickou složitost jsem alergický. Rozhodně se hodí, když tomu lidi rozumí jako spoustě dalších věcí i mimo IT, ale opravdu je to ten největší problém, co vás na projektu trápí. Minule, když se mě na to ptali, tak se ukázalo, že mají aplikaci plnou SQL injection, maven repository si kpírovali na flashkách... Hlavně, že nabírali lidi s matematickými znalostmi.
OdpovědětVymazatVsetko to je o tom, akeho cloveka chcete do firmy, a na aku poziciu/pracu.
OdpovědětVymazatSenior by mal mat aspon prehlad o teoretickych konceptoch, ci uz spominane kolekcie, zlozitost atd. Honit si ego nad nejakym juniorom co bude busit kod hlava nehlava a copy pastovat polku internetu je ale dost zbytocna aktivita.
Matfyzacke pseudointelektualne & zakomplexovane kocky su castokrat v korporatnom prostredi stratene a nehodia sa tam. Na busenie nejakeho C++ backend real time tradingu, modelovania atd. sa mozu hodit viac. Atd....
My jsme ve firmě také od testů upustili přesně z důvodů popsaných v článku. Test považuji za vhodný případě, že počet kandidátů s kvalitním životopisem převyšuje časové možnosti potkat se s každým. Dle mých zkušeností je možné poměrně jednoduše udělat obrázek pouze z pohovoru. Například každý, kdo dělal 2 roky s hibernatem, by měl mít alespoň elementární znalosti o optimalizacich selektů.. Kdo dělal s databází a není schopen říci, co je full table scan? Kdo se vzdělává sám a nechce prozradit ani jeden volně dostupný zdroj? Kdo dělal webové aplikace a neví rozdíl mezi POST a GET? SQL injection? :-) A naopak - není vhodné vzít někoho, kdo se dobře orientuje oblasti, která není zrovna váš mainstream? Např.potřebujete maven a kandidát je dobrý v gradle? Nediskvalifikuje test kandidáta, který nedělal v guice ale je dobrý ve springu?
OdpovědětVymazatHezky shrnuto. Souhlasím.
VymazatSeznam.cz je v Českých luzích a hájích také známej svýma vypečenýma testama...
OdpovědětVymazatA pak z nich lezou takový UX tragédie jako stream.cz nebo lide.cz.
Vymazat