Posleního čtvrt roku žiju pohovory. Dělám technická interview, dosti podobná tomu, co jsem před časem popsal v článku Jak dělám Java pohovor. Je to pro mne živé a přitažlivé téma - kromě toho, že je to (téměř) každodení zkušenost, tak sleduju různé články na internetu. Většinou v angličtině. K dnešnímu postu mě ale inspiroval článek, který je... ve slovenštině.
Riki Fridrich navrhuje v článku Kontrak namiesto pohovoru alternativu ke klasickému výběrovému řízení - místo pohovoru si kandidát střihne maličký projekt. Riki nepřichází s ničím novým - před rokem o tom psali Jeff Atwood, Jon Evans, letos Nelly Yusupova a Tommy Morgan. Takže to je myšlenka, která rezonuje. Minimálně na internetu.
V čem je problém?
Všemi výše uvednémi články prosvítají dvě základní myšlenky:
- Pracovní pohovory jsou neefektivní.
- Nejlepším způsobem, jak si (z několika úhlů) otestovat nového vývojáře, je zadat mu malý, ale reálný projekt.
Riki jde u druhého bodu ještě dál, když říká, že "to je budoucnost najímání seniorních ajťáků".
Všechny právě zmíněné "činnosti" jsou nástroje, které nám pomáhají v naší práci. Je přece na nás, jestli je budeme používat efektivně (a správně). A je velmi důležité si uvědomit, že všechny tyto nástroje fungují v určitém kontextu (moje oblíbené slovo :-)
Myslíte si, že např. softwarový projekt bude úspěšný jen proto, že "nasadím" nějaký z těchto nástrojů? Já nevím jak vy, ale já už jsem viděl dost špatných implementací Scrumu (mmch. je zajímavý, že zainteresovaní vývojáři to většinou vidí, jako úspěch, i když projekt šel do kytek).
Podobné je to i s pracovním pohovorem. Není to žádná stříbrná kulka. Pohovor, to je jen taková "kvalifikace do závodu". Co v člověku opravdu je, se ukáže teprve během zkušební doby. Jak říká Rands, až teprve po 90 dnech budou obě strany vědět, na čem jsou. Neexistuje žádná zkratka.
Takže, ať už děláte takový skvělý pohovor jako já ;-) nebo jedete v obvyklé korporátní nudě, pořád je to jen jeden stupínek na dlouhé cestě. Pohovor bude tak efektivní, jak efektivní si ho uděláte - ať už jste kandidát, nebo zaměstnavatel.
Nastavení prostředí. Aby kandidát mohl začít na něčem vyšívat, musí si nachystat nástroje. Jak dlouho mu to může trvat? Třeba je firma tak vyspělá, že nejenom že má build (nebo dokonce release) na jeden klik. Dokonce má na jeden klik i nastavení prostředí. Takový ty věci, jako vývojový (aplikační/webový) server, potřebné pluginy do IDE (ve správných verzích), všechny závislosti pro build, deploy a běh aplikace atd.
Řekněme, že tohle všechno je na jeden klik a když to bude hodně komplexní, tak to bude trvat maximálně 30 minut (berme, že konektivita pro stahování artefaktů je v dostatečné kapacitě). Build je taky na jeden klik a opět, když to bude hodně komplexní, tak dejme tomu 10 minut. Takže včetně uvaření kafe, za hodinu je kandidát připraven vyvíjet.
Mno. Zrovna jsem tenhle týden dostal od kandidáta na pohovoru otázku, jak dlouho u nás trvá příprava prostředí pro vývoj. A upřímně jsem odpověděl, že když jsem si rozcházel projekt, na kterém teď vypomáhám s nějakými change requesty, trvalo mi to tři dny. Ten projekt je specifický a má to svoje objektivní důvody. Ale je to realita, která se čas od času přihodí.
Obecně, moje zkušenost (v oblasti enterprise Javy) je, že rozchození projektu trvá řádově man days. Nevím, možná je to extrémní situace. Když jsem před 10 lety programoval v PHP, tak jsem si: 1) zkopíroval z disku zdrojáky, 2) hodil je na Apache (mod_php) a 3) a začal bastlit ve Vimu, tak to mohlo trvat tak 20 minut. (Teď trochu kecám - tehdy jsem bušil ve Slackwaru a celý LAMP jsem si kompiloval ze zdrojáků. Takže i s přípravou serveru to trvalo o dost dýl. Ale dejme tomu, že to zanedbáme.)
Máte zkušenosti z jiných domén? Jak dlouho trvá nastavit prostředí v Ruby? V Pythonu? V Erlangu? V Androidu? Myslím reálné business projekty.
Sdílení artefaktů. Kandidát bude potřebovat s firmou sdílet nějaké artefakty. V první řadě, bude potřebovat někde získat zdrojový kód. A zpátky komitovat svoje změny. Co nějaká dokumentace, Wiki? Nějaké konfigurační artefakty, které nejsou přímo součástí aplikace?
Pokud jste na GitHubu (nebo jiné, obdobné hostingové službě), máte vyhráno. Nejste na GitHubu? A safra! Kdo bude s vaším kandidátem řešit problémy s konektivitou, nastavením práv apod.? Nejde o to, že by to bylo složité (zatím to vždycky fungovalo ;-) a kandidát by si s tím neuměl poradit. Problém je, že to "žere" čas, který má kandidát na projekt.
Sdílení informací. Kolik artefaktů, vyjma aplikace samotné, vám na projektu vzniká? Jste agilní a máte jich minimum? Znalosti a kontext se sdílí v týmu hlavně orálně (stand-upy, statusy atd.)? Nebo máte naopak hodně formálních artefaktů? Věci jako specifikaci, analytický model, guide lines atd.
A teď. Kolik času kandidátovy zabere, aby vstřebal alespoň nutné minimum, které mu umožní na projektu začít?
Znalost technologií. Třeba firma dělá v něčem křišťálově čistém - víš, nevíš. Abych pravdu řekl, nic takového mě nenapadá. Děláte v JavaScriptu? Kolik frameworků znáte opravdu dobře? Děláte v PHP? Totéž. Pokud bych vzal v potaz doménu Java frontend frameworků, tak pravděpodobnost, že kandidát zná, či má zkušenosti právě s tím vaším, je tak 10 %. OK, pokud dělal s (nějakým klonem) JSF, tak se to může blížit i 50 %.
Moje frontendová zkušenost za cca 8 let v Javě? Co projekt, to jiný framework. Pokaždé se to učíte znova a znova. Když to vezmu chronologicky: Servlety, HTMLB (zná to někdo?), Wicket, RichFaces, Vaadin.
U backendových technologií to není tak divoký, ale stejně. Celkem běžně potkávám na pohovorech lidi, kteří třeba 5 let dělali v JDBC a ani nezavadili o JPA, nebo něco podobného.
Takže jaká je pravděpodobnost, že kandidát bude technologicky sedět na potřeby firemního produktu? Pokud to nebude 80-90 %, co s tím? Jak dlouho se bude nové technologie učit? Nebo si oživovat ty staré (třeba přes dvě, tři nekompatibilní verze)? Jaký to bude mít vztah k našemu projektu?
Jsou pracovní pohovory neefektivní?
Pracovní pohovory jsou tak neefektivní, jak neefektivní si je každý udělá. A to platí pro obě strany. Říct, že pracovní pohovor je neefektivní, je stejné, jako říct, že neefektivní je třeba Scrum. Nebo psaní unit testů. Nebo kontinuální integrace. Mám pokračovat?Všechny právě zmíněné "činnosti" jsou nástroje, které nám pomáhají v naší práci. Je přece na nás, jestli je budeme používat efektivně (a správně). A je velmi důležité si uvědomit, že všechny tyto nástroje fungují v určitém kontextu (moje oblíbené slovo :-)
Myslíte si, že např. softwarový projekt bude úspěšný jen proto, že "nasadím" nějaký z těchto nástrojů? Já nevím jak vy, ale já už jsem viděl dost špatných implementací Scrumu (mmch. je zajímavý, že zainteresovaní vývojáři to většinou vidí, jako úspěch, i když projekt šel do kytek).
Podobné je to i s pracovním pohovorem. Není to žádná stříbrná kulka. Pohovor, to je jen taková "kvalifikace do závodu". Co v člověku opravdu je, se ukáže teprve během zkušební doby. Jak říká Rands, až teprve po 90 dnech budou obě strany vědět, na čem jsou. Neexistuje žádná zkratka.
Takže, ať už děláte takový skvělý pohovor jako já ;-) nebo jedete v obvyklé korporátní nudě, pořád je to jen jeden stupínek na dlouhé cestě. Pohovor bude tak efektivní, jak efektivní si ho uděláte - ať už jste kandidát, nebo zaměstnavatel.
Projekt místo pohovoru?
Je to hezká myšlenka. Místo příkladu do šuflíku - opravdový projekt. Místo programování na tabuli/papír - programování v oblíbeném IDE. Místo akademických algoritmů - reálný problém. Místo stresující nudy - práce, která baví. OK, myšlenka je to inspirativní. Co ale musíme udělat, aby byla proveditelná?Nastavení prostředí. Aby kandidát mohl začít na něčem vyšívat, musí si nachystat nástroje. Jak dlouho mu to může trvat? Třeba je firma tak vyspělá, že nejenom že má build (nebo dokonce release) na jeden klik. Dokonce má na jeden klik i nastavení prostředí. Takový ty věci, jako vývojový (aplikační/webový) server, potřebné pluginy do IDE (ve správných verzích), všechny závislosti pro build, deploy a běh aplikace atd.
Řekněme, že tohle všechno je na jeden klik a když to bude hodně komplexní, tak to bude trvat maximálně 30 minut (berme, že konektivita pro stahování artefaktů je v dostatečné kapacitě). Build je taky na jeden klik a opět, když to bude hodně komplexní, tak dejme tomu 10 minut. Takže včetně uvaření kafe, za hodinu je kandidát připraven vyvíjet.
Mno. Zrovna jsem tenhle týden dostal od kandidáta na pohovoru otázku, jak dlouho u nás trvá příprava prostředí pro vývoj. A upřímně jsem odpověděl, že když jsem si rozcházel projekt, na kterém teď vypomáhám s nějakými change requesty, trvalo mi to tři dny. Ten projekt je specifický a má to svoje objektivní důvody. Ale je to realita, která se čas od času přihodí.
Obecně, moje zkušenost (v oblasti enterprise Javy) je, že rozchození projektu trvá řádově man days. Nevím, možná je to extrémní situace. Když jsem před 10 lety programoval v PHP, tak jsem si: 1) zkopíroval z disku zdrojáky, 2) hodil je na Apache (mod_php) a 3) a začal bastlit ve Vimu, tak to mohlo trvat tak 20 minut. (Teď trochu kecám - tehdy jsem bušil ve Slackwaru a celý LAMP jsem si kompiloval ze zdrojáků. Takže i s přípravou serveru to trvalo o dost dýl. Ale dejme tomu, že to zanedbáme.)
Máte zkušenosti z jiných domén? Jak dlouho trvá nastavit prostředí v Ruby? V Pythonu? V Erlangu? V Androidu? Myslím reálné business projekty.
Sdílení artefaktů. Kandidát bude potřebovat s firmou sdílet nějaké artefakty. V první řadě, bude potřebovat někde získat zdrojový kód. A zpátky komitovat svoje změny. Co nějaká dokumentace, Wiki? Nějaké konfigurační artefakty, které nejsou přímo součástí aplikace?
Pokud jste na GitHubu (nebo jiné, obdobné hostingové službě), máte vyhráno. Nejste na GitHubu? A safra! Kdo bude s vaším kandidátem řešit problémy s konektivitou, nastavením práv apod.? Nejde o to, že by to bylo složité (zatím to vždycky fungovalo ;-) a kandidát by si s tím neuměl poradit. Problém je, že to "žere" čas, který má kandidát na projekt.
Sdílení informací. Kolik artefaktů, vyjma aplikace samotné, vám na projektu vzniká? Jste agilní a máte jich minimum? Znalosti a kontext se sdílí v týmu hlavně orálně (stand-upy, statusy atd.)? Nebo máte naopak hodně formálních artefaktů? Věci jako specifikaci, analytický model, guide lines atd.
A teď. Kolik času kandidátovy zabere, aby vstřebal alespoň nutné minimum, které mu umožní na projektu začít?
Znalost technologií. Třeba firma dělá v něčem křišťálově čistém - víš, nevíš. Abych pravdu řekl, nic takového mě nenapadá. Děláte v JavaScriptu? Kolik frameworků znáte opravdu dobře? Děláte v PHP? Totéž. Pokud bych vzal v potaz doménu Java frontend frameworků, tak pravděpodobnost, že kandidát zná, či má zkušenosti právě s tím vaším, je tak 10 %. OK, pokud dělal s (nějakým klonem) JSF, tak se to může blížit i 50 %.
Moje frontendová zkušenost za cca 8 let v Javě? Co projekt, to jiný framework. Pokaždé se to učíte znova a znova. Když to vezmu chronologicky: Servlety, HTMLB (zná to někdo?), Wicket, RichFaces, Vaadin.
U backendových technologií to není tak divoký, ale stejně. Celkem běžně potkávám na pohovorech lidi, kteří třeba 5 let dělali v JDBC a ani nezavadili o JPA, nebo něco podobného.
Takže jaká je pravděpodobnost, že kandidát bude technologicky sedět na potřeby firemního produktu? Pokud to nebude 80-90 %, co s tím? Jak dlouho se bude nové technologie učit? Nebo si oživovat ty staré (třeba přes dvě, tři nekompatibilní verze)? Jaký to bude mít vztah k našemu projektu?
Je to reálné?
V předešlé sekci jsem načrtnul některé z problémů (jistě ne jediných), které by bylo potřeba vyřešit, aby byl "přijímací" projekt proveditelný. Všechno jsou to technické záležitosti, v podstatě jenom prerekvizity. Už jenom u těchto předpokladů mám vážné obavy, že by se jejich splnění mohlo vejít do pár hodin, maximálně jednoho dne. Ale dejme tomu, že by to šlo.Další sadou výzev bude nastavení firmy a její kultura. Kandidát by ideálně měl dostat za svůj projekt zaplaceno. Kde se ty peníze ve firmě vezmou? Některé společnosti fungují striktně nákladově - vezmou se ty peníze z budgetu projektu? Nebo z nějaké režijní činnosti? Kdo za to bude odpovědný? Jakým způsobem se budou ty náklady vyúčtovávat? V maličkým startupu nad tím můžeme mávnout rukou. Ve větší firmě to bude show-stopper.
Také nemůžu nezmínit věc, která mi přijde velmi kritická - součinost firmy s kandidátem. Zdá se mi to, nebo se furt nikdo nepoučil, že přidáním lidí na projekt se vývoj zpomalí (Brook's law)? Pokud přijímáme jednoho kandidáta, (časové) náklady na součinost se v běžné práci ztratí. Pokud ale potřebujeme najmout tým lidí - a neříkám, že najednou - znamená to zasekat se v podpoře kandidátů na půl roku dopředu. Na full time. To si nedovedu představit. A to mám se zaškolováním lidí na projektech, řekl bych, celkem bohaté zkušenosti.
A pak nám zbývá poslední, esenciální ingredience. Kandidát. Chápu, že když chce někdo dělat pro firmu svých snů, udělá pro to opravdu hodně. Doplňte si dle svých preferencí Google, Twitter, ThoughtWorks, GitHub, Stack Overflow, Apache, Canonical... já nevím, co ještě. Takže když vám taková firma zadá vstupní projekt, rádi ho uděláte a ještě to budete považovat za čest.
Jenže, kolik takových firem je? Jedno promile? Co ty ostatní, kde pracuje 90 % těch vývojářů, co nejsou špičkový? Ruku na srdce, kolik z vás by šlo do týdenního projektu (byť placeného) s nejistým výsledkem?
Aby kandidáti do něčeho takového šli, museli by změnit svůj mindset. Nedávno jsem v článku Měl by mít vývojář portfolio? psal o tom, že na pohovorech chci vidět kandidátův kód. Nemám srovnání, ale odhaduju, že jsem v tomhle spíš výjimka. Je to vidět i na přístupu kandidátů - někteří jsou tím dost zaskočeni. Někteří dají do placu kód, který není zrovna oslnivý. A zlomek jich tento požadavek prostě ignoruje.
Takže můj pocit je, že pro majoritu vývojářů by psaní vstupního projektu bylo příliš velkým myšlenkovým veletočem.
Závěr
Myslím, že myšlenka dát vývojáři místo pohovoru projekt, je zajímavá. Ale realizovatelná tak v jednom procentu případů. Velmi specifických případů. Asi půjde o nějaký startup, kde to nebude problém procesně a technicky. V případě kandidáta půjde asi o excelentního bušiče kódu, který zrovna šťastně odpovídá technologickému nastavení firmy. A práce bude pro kandidáta tak zajímavá, že mu to za ten projekt bude stát. To je dost výjimečná konstelace.
Související články
Související externí články
Myšlenka kontraktu místo pohorovu se mi líbí. Mimojiné to odfiltruje méně vážné zájemce, rovněž je to tlak na firmu, aby byla dostatečně atraktivní.
OdpovědětVymazatTakhle to dělá @jirihradil, možná by mohl článek okomentovat. Byl jsem odhodlaný to u nich zkusit, ačkoliv jsem před tím v RoR nenapsal ani řádku (teda pár řádek ano).
Pravda, tvoje námitky vycházejí z kruté reality.
Moc se mi líbí jak nabírají lidi v kasínech v USA, vyberou při pohovoru dva nejvhodnější kandidáty na stejnou pozici z nichž toho horšího na konci zkušební doby vyhodí.
OdpovědětVymazatTo asi moc nepodporuje týmového ducha, ne?
VymazatTo si muze dovolit nekdo, kdo nepotrebuje kvalifikovanou pracovni silu. Na programatorsky projekt je tezke sehnat lidi, takove plytvani by bylo cesta do pekel.
VymazatZajimalo by me jestli se dari vyvazovat kvalitu lidi (napr. timhle druhem pohovoru) s tim ze jich je udajne na trhu nedostatek - nedostatek je urcite tech kvalitnich. Podari se tym sestavit vcas ?
OdpovědětVymazatObecně, kvalitních lidí je málo (mám tendenci si myslet, že je to tak v každé doméně). Moje zkušenost je, si na dobré vývojáře počkat - vyplatí se to, bez ohledu na termíny projektu.
VymazatV mém případě momentálně nejsem vázaný konkrétními dead lines, takže to je o to jednodušší. Plus nejedná se o jeden konkrétní projekt, ale celou sérii projektů, takže spíše sestavuji takový pool vývojářů.
Když bratr chodil na pohovory na místo junior programátora, tak dostal jednou, dvakrát udělat projekt. Navrhnout a programovat. Jedno byla asi střední firma, 50 lidí? Nutno dodat, že byl po škole bez praxe. Ale nebyly to reálné projekty, jen ukázové.
OdpovědětVymazatKód chtěli vidět několikrát.
U absolventů to chápu - nemají praxi, tak dostanou drobný "cvičební" projekt, nad kterým se pak dá podiskutovat. Nejspíš tam bude nulová součinnost ze strany firmy.
VymazatV principu/výsledku se to asi moc neliší od kódování přímo na pohovoru (omezený scope, akademický problém apod.).
To je pravda, neuvědomil jsem si, že vlastně řešíš něco jiného. U senior vývojářů. :)
VymazatPokud bych dostal projekt místo pohovoru, tak bych rovnou šel dál. Přesně z těch důvodů co jsou v článku. Naposledy jsem měl 3 kolový pohovor a teprve 3. kolo jsme se bavili o tom co ode mě očekávají a co od nich čekám já do podrobna. Až na 3. kole jsem zjistil, že tam dělat nechci (chtěli mě hodně tlačit do obchodu). Pokud bych měl tohle zjistit až po vypracování krátkého projektu, tak bych asi byl hodně naštvaný. Dál taky nebude mít spousta lidí na ten projekt vůbec čas. Málokdo se přihlásí najednou pouze do jedné firmy. Nedokážu si představit, že bych měl dělat 3 projekty pro 3 různé firmy najednou. Dělat ty projekty po sobě by zase znamenalo si vyhradit několik měsíců na hledání práce.
OdpovědětVymazatTak nějak si to představuji - vyberu si (jednu) firmu, kde bych (hodně) chtěl dělat a pak pro ně můžu udělat malý projekt. Ale stejně...
VymazatVětšina lidí (včetně mne) osloví více firem - když jsem hledal aktuální zaměstnání, odepsal jsem asi na 10 inzerátů (asi všude mě nakonec pozvali), pro pohovor jsem si z nich vybral 3. Stále jsem přitom byl zaměstnaný v bývalé práci a že bych přitom na full time dělal ještě jiný projekt (byť třeba jen jeden) je fantasmagorie.
RE: Naposledy jsem měl 3 kolový pohovor a teprve 3. kolo jsme se bavili o tom co ode mě očekávají a co od nich čekám já...
VymazatJako freelancer, ktery ma za sebou MNOHO pohovoru a velmi omezeny cas se zabyvat nabidkami, mohu rict, ze jsem se velmi dobre naucil hned na prvni schuzce (== v prvnim kole) resit konkretni detaily te pozice. A namitka ze nekdy to proste nejde je blbost - chce to trochu asertivity, hromadu dotazu a donutit protistranu ke spolupraci hned na zacatku. Pokud protistrana neni ochotna spolupracovat tak vetsinou nestoji ani za vzdech ;). Ztracet cas tim ze na konec zjistim ze tam delat nechci je opravdu bida.
Jinak i vstupni projekt uz jsem delal a je pravda ze ten tyden jsem nemohl delat nic jineho. Pravda, cely prijimaci proces trval asi tri tydny, z cehoz minimalne dva jsem se musel zabyvat jenom tim... ale o to vic se clovek snazi, aby ho nakonec prijali, kdyz uz do toho investoval tolik casu ;).
Prijali me, ale bohuzel se ukazalo, ze ani takhle narocny prijimaci proces proste nevybere dobre lidi vzdycky.
Muj zaver: Prijimaci projekt je dobra vec - ale staci neco jednoducheho, aby se overil kandidatuv styl. Jestli se kandidat osvedci jako vyvojar (se vsim vsudy) se stejnak pozna - dle me zkusenosti - az tak po pul roce. Nekdy drive, nekdy pozdeji - ale rozhodne ne po nekolika pohovorech a jednom tydenim projektu...
Pokud je RoR projekt dobre strukturovany a mas nainstalovany veci jako Ruby/DB atd tak je setup projektu obecne otazka desitek minut, coz je oproti Java projektum velice prijemne...
OdpovědětVymazatKdyž jsem si rozmýšlel sekci Znalost technologií, tak Ruby on Rails bylo to první, co my přišlo na mysl - úzce ohraničená, homogenní technologie. To by bylo použitelné. Ale je to (nechci nikoho urazit) minoritní technologie.
VymazatV podstatě velmi souhlasím.
OdpovědětVymazatTuto věc bych doplnil mým názorem.
Jedná se o práci mimo pohovor - tzv. "testovací projekty zdarma".
Těchto úloh jsem už absolvoval nespočet a mám s nimi JEN negativní zkušenosti.
Problém není v tom, že by byl můj kód příliš nekvalitní nebo že by mě na základě těchto projektů nechtěli. Velký problém vidím v tom, že mnozí "zaměstnavatelé" namísto poděkování za zdarma zpracovaný projekt jej mnohdy využívají k tomu, aby si na něm našly chyby a na jejich základě mi snížili plat.
Jako třešničku na dortě uvedu příklad kdy jeden nejmenovaný kolega z oboru vypracoval za týden tento "vzorový projekt zdarma". Šéf mu jej plně odkýval, sám jej pochválil, že je nejlepší od všech uchazečů.... dohodli se na platě.... a než stihl onen kolega nastoupit, zaměstnal levnějšího kandidáta.
Můj závěr a názor?
Jestliže po Vás někdo chce něco zadarmo už během pohovoru (vypracovat doma MIMO rámec pohovoru), tak tyto lidi v prvním kroku automaticky žádám o tzv. Smlouvu o dílo.
Nakonec, co čekat od člověka, který Vás vydírá už během pohovoru příslibem "že když to uděláte zdarma, bude o Vás ještě nadále uvažovat".
Tady platí pravidlo, že jak někomu kývneš na něco zdarma, tak tě bude chtít "šulit" zdarma v budoucnu jen víc a víc.
Navíc takové firmy nemají programátorům později co nabídnout a dají se podle tohoto poměrně bezpečně odhadnout.
U mě a mých kolegů je to zejmena dáno negativními zkušenostmi, kdy vypracování projektu bylo mrhání časem, energií a jistým způsobem podlehnutí vydírání.
Přeji pěkný den.
Martin
Martine, díky za sdílenou zkušenost.
Vymazat