Jak se staví tým

Tenhle článek jsem chtěl napsat už několik let. Pořád jsem to odkládal s tím, že časem ještě získám víc zkušeností a tak to bude mít větší, komplexnější váhu. Že pořád na to bude jednou dost času. Ale tak to v životě nechodí... jednou přijde čas a uvědomíte si, že věci, která vás kdysi extrémně přitahovaly, vám najednou nic neříkají. A že pokud to neuděláte teď, tak už to neuděláte nikdy.

Přesně takovým obdobím teď procházím. Přičinil jsem se o zlom ve své kariéře a tak po 8 letech, kdy jsem dělal team leadera a souběžných 6 letech, kdy jsem se intenzivně věnoval technickému rekruitmentu, tyto dvě oblasti (dobrovolně) opouštím. A tak je tenhle článek jakýmsi rozloučením a předáním štafety.

Na začátku by měla být vize

Když dostanete možnost postavit nový tým, nebo třeba významně doplnit ten stávající, měli byste mít nějakou vizi, jak ten tým bude vypadat. Proč vize? Protože budování týmu nekončí přijímacím pohovorem. Nekončí ani po zkušební době, či úplném zapracování. Ono totiž nekončí nikdy - je to cesta, která je svým vlastním cílem. A proto potřebujete úběžník, ke kterému budete po celou dobu existence týmu směřovat.

Termín z perspektivy jsem si nevybral náhodou:

• Vize i úběžník jsou virtuální entity, kterých v realitě nejde dosáhnout.
• Vize i úběžník jsou "lehce pohyblivé cíle" - záleží na perspektivě, úhlu pohledu, času a pozorovateli.
• O skutečném vývoji/postupu vypovídá historie - to když se ohlédnete zpět a uvidíte, jakou cestu jste urazili.
• Existují nástroje, které vám ve složitem terénu pomůžou udržet směr.

Smutnou pravdou je, že většina teamleaderů a manažerů - pokud už si dali tu práci a takovou týmovou vizi si definovali - vám nebude schopna tuto vizi popsat. Samozřejmě, takový ty soft-skill/HR/people-management keci vám řekne každý. Ale to jsou jen newspeak keci.

Jestli mě Kanban něčemu naučil, tak "make policies explicit". Pro vizi to platí taky. Nemusíte ji s nikým sdílet. Ale sepište si to. Vyslovte to nahlas. Není to žádná magie, ale funguje to zázračně. Jinak budete po léta bloudit v pustinách. Vy i celý tým.

Přijímací pohovor

O (technických) přijímacích pohovorech jsem tady na blogu psal po léta. Ačkoliv to jsou, nijak překvapivě, ty nejčtenější články, jejich vliv byl minimální. Když jsem se po 5 letech vrátil na pracovní trh, byla to velmi tristní zkušenost.

Tak jako jsem v minulé sekci zdůrazňoval důležitost vize, pro pohovory platí to samé - nepokažte si to hned na začátku. Může vám v tom pomoci pár pravidel:

• Buďte konzistentní. Všichni lidi v týmu by měli projít stejným procesem. (Ale udělejte výjimku, když to dává smysl.)
• Udělejte technické kolo co nejbližší skutečné práci, kterou děláte. Tohle většině českých firem ještě nedošlo. Jste SW inženýři, dělejte věci racionálně a nedržte se bludných mýtů.
• Nedělejte síto příliš úzké a husté. Nemáte ani představu, jak je život rozmanitý. Pravda, čím budete starší, tím méně věcí vás bude překvapovat. Ale stejně vždycky přijde něco, co jste nečekali (pokud jste před tím nezavřeli oči). Výjimkou z tohoto pravidla je, pokud jste si ve vizi definovali, že chcete postavit tým ze samých klonů tzv. ideálního kandidáta (mmch. to chce většina pražských firem).
• Směřujte k vizi. Ptejte se: bude tenhle kandidát za 1/2 roku, za rok sedět do naší (týmové) vize?

 Neexistuje ideální pohovor. Pokud to s pohovorem myslíte vážně a neberete kohokoli z ulice, stojí za to se inspirovat u zkušených (článků je plný internet), něco seriózního si o tom přečíst a pracovat na tom a pohovor zlepšovat. Za sebe doporučuji třeba Esther Derby, Johanna Rothman, Gerald Weinberg, Andy Lester, či Michael Lopp (Rands in Repose).

Já jsem svůj způsob pohovorování vybrušoval pět let. Je to proces, který odpovídá mé vizi, takže pro někoho může být nevhodný. Některé věci jsou dokonce nepřenosné.

Pokud nevíte kde začít, zkuste 2-a-půl kolové schéma (obsah už si doplníte sami):

• Phone screen. Krátký a jednoduchý technický filtr - má smysl se vidět tváří v tvář a strávit spolu víc času? (Pro inspiraci, jak jsem to dělal já.)
• Technické kolo. Viz výše. A opět můžete nakouknout ke mně do kuchyně.
• Netechnické kolo. Podívejte se na kandidáta i jinak, než přes technologie - není to robot. Pokud si později nebudete sedět, bude to spíš kvůli osobním, netechnickým kvalitám. Ale i tady platí "nedělejte síto příliš husté".

Neúprosná pohovorová statistika

Postavit dobrý tým je těžká makačka. Je to plnohodnotný (IT) projekt. Věc, kterou si členové vašeho týmu nejspíš nikdy neuvědomí (a spousta dalších lidí okolo), je, kolik je za tím práce, dát dohromady 5 až 10 lidí.

Po léta si vedu pohovorovou statistiku. Tady je jeden konkrétní, řekl bych průměrný rok:

• Phone screen: celkově 46 pohovorů, z toho 33 postoupilo do dalšího kola (úspěšnost 72 %).
• Technické interview: celkově 29 pohovorů, z toho 20 postoupilo do dalšího kola (úspěšnost 69 %).
• Personální intervew: pro toto kolo nemám data (v grafu níže extrapoluji).
• Do týmu nastoupilo 6 lidí. Trvalo to rok.

 

Statistika pohovorů

Ke statistice pár poznámek:

• To že se lidi dostali na phone screen, znamená, že už byli minimálně profiltrovaný přes CV, buď interním HR, nebo agenturou. Tzn. že většinou už absolvovali headhunterský telefon. A samozřejmě prošli přes moje CV review.
• Reálně do dalšího kola nastoupí méně kandidátů, než kolik jich bylo úspěšných (z různých důvodů nepokračují dál).
• Interview byla během roku konzistentně rozvrstvena. Zhruba to znamená udělat za měsíc 4 phone screeny a 2-3 technická interview. A jednou za dva měsíce zapracovat nového člověka.
• Počítejte, že ze všech lidí, kteří vám projdou pohovory, vám do týmu nastoupí cca 10 % z nich. I míň.
• Povšimněte si poměrně vysoké úspěšnosti kandidátů v jednotlivých kolech. Domnívám se, že je to dáno tím, že jsem měl celý proces pod kontrolou a zůčastnil jsem se všech pohovorů (vyjma personálních interview). Pokud vám dělají interview různí lidé a nekonzistentně, bude neúspěšnost vyšší.

Zapracování

Fajn. Člověk vám nastoupil a dostal počítač a stravenky. Zpravidla bude nadšený a iniciativní. Neprošvihněte to! Samozřejmě, musí se naučit všechny ty procesy nástroje, projekty a produkty. Zaručeně tím ztráví celou zkušební dobu a velmi pravděpodobně celý úvodní semestr. Pokud je vaše doména složitá, může zapracování trvat i dva roky (true story).

Tohle období ubíhá tak nějak samo od sebe, samospádem. Možná to bude dost překotné. Ale nepodceňte to - je to první čas, kdy budete daného člověka opravdu poznávat. Jak pracuje, jak žije, jak se chová, jak na něj reagují ostatní (členové týmu)?

Je to jedinečné období, kdy můžete zasadit semínko kultury a pomáhat mu zakořenit a růst. Pomůžou vám v tom nástroje jako 1:1 a ochota naslouchat a řešit problémy.

Týmová kultura

Jakmile máte v týmu prvního člověka, je týmová kultura to nejdůležitější, o co byste měli jako team leadeři pečovat. Je otázka, jaká je konstelace a kolik na to budete mít reálně času. Ale pokud má tým zdravě funovat v následujících letech a překoná různé (personální, pracovní a další) krize, bude to díky živoucí kultuře. Pokud týmová kultura churaví, nebo dokonce umře (taky jsem to zažil), bude to jen o tom, jak přinést domů pytel peněz na kus žvance.

Každá kultura funguje na tom, že se lidé potkávají. Čím širší komunikační kanál, tím lepší (zdravější). Nejlépe osobně, když to nejde tak aspoň video, až pak telefon a úplně na konci instant messaging. Pokud si píšete už jen emailem, tak už vlastně nekomunikujete.

Mějte pravidelné týmové schůzky. Potkávejte se nad problémy, u jídla a (v rozumné míře) mimo práci.

Každá kultura, která se rozvíjí, má nějaké (samo)korektivní mechanizmy, historii a způsob zpracování zpětné vazby. V případě SW inženýrství máme skvělý a ozkoušený nástroj: týmové retrospektivy. Retrospektivy nemusí být jen o projektech a iteracích. Můžou mít zaměření i na tým a jeho kulturu.

Retrospektiva: team radar

Mít dobrou týmovou kulturu není nic zas až tak těžkého - chce to jen pár rutinních a pravidelných úkonů. Jako když pečujete o zahrádku. Když to zandedbáte, začne vám zvolna zarůstat plevelem. V určitý moment se může stát, že se vám zahrádka vylidní. Přeju, ať se to nestane.

Související články

• Jak dělám Java pohovor III: phone screen
• Jak dělám Java pohovor IV: Java workshop
• Smutná zpráva o stavu IT trhu
• Geek, který zapadne
• 1:1, nejdůležitější nástroj team leadera

Smutná zpráva o stavu IT trhu

Aneb jak dělají technické pohovory jinde

Strávil jsem teď posledních pět měsíců hledáním nové práce. Nebylo to radostné období, bylo to tristní. Celkový dojem by se dal shrnout do jedné věty:

V oblasti IT jsme jen levná montovna aut.

Zaměstnavatelé (IT firmy) nehledají ani kreativní lidi, ani problem solvery, ani autonomní vývojáře. Nehledají lidi, kteří se konstantně učí a zlepšují. Ne. Místo toho hledají někoho, komu jeden bývalý kolega říkal láskyplně makáči. Občas jim někdo méně něžně říká lopaty. A já to řeknu natvrdo:

Většina firem u nás hledá programátory, které potřebují posadit rovnou k soustruhu, či k pásové výrobě.

A když to trochu víc zgeneralizuji, hledají lidi s fixním mindsetem. Zapomeňte na to, že byste se ještě někdy mohli něco naučit. Je potřeba, abyste sekali šroubky, jeden jako druhý. Jediným doporučením je, že jste navlas stejné šroubky dělali v minulosti (která skončila včera).

Silná slova, nebo jak to teda je?

Tak, bulvární úvod už máme za sebou, pojďme se na to podívat trochu objektivněji. V rámci možností. V tom, co jsem napsal v úvodu, se můžu těžce mýlit. Je to jenom odraz toho, jak interpretuji technická kola pohovorů, který jsem absolvoval. Hodně to reflektuje rozpor mezi tím, co firmy (a jejich techničtí lidé) říkají a jak reálně konají na pohovorech.

No a samozřejmě, ať to zazní hned na začátku - mám spoustu chyb a nejsem rytíř v blyštivé zbroji. Možná že celou situaci špatně čtu a prostě nedosahuji "standardních" nároků, které dnes IT trh vyžaduje. Možná mi jenom ujel vlak. Jako introvert, si to myslím polovinu času.

Moje reflexe je silně poznamenaná zpětnou vazbou, které se mi dostalo. Je po léta smutným faktem českého trhu, že v 80 % dostanete jako jediné vyjádření kultovní větu:

"Pro další jednání jsme upřednostnili uchazeče, kteří přesněji odpovídali aktuálním požadavkům pozice."

Nic proti rozhodnutí. Jen vám to tak nějak nepomůže, že jo? (A jsme zase u toho fixního mindsetu.)

Rozsah a forma

Dále neuvádím všechny pohovory, které jsem absolvoval, jen ty, kde proběhlo aspoň nějaké technické kolo (v libovolné formě). Uvádím vždy:

• Anonymizovaný typ firmy a název pozice.
• Krátký popis technického kola.
• A pak asi to nejcenější - reflexi.
• Formální, či neformální zpětná vazba od pohovorující strany.
• Černobílé hodnocení mindsetu: fixed/growth.

Upozornění

Tento článek je převažně negativní. Proto bych zdůraznil, že je primárně o procesu, ne o lidech. Pokud se někde vyjadřuju rozporuplně o pohovorujících, jde o názorovou neshodu a nevypovídá to nic o jejich charakteru, nebo schopnostech.

Start-up inkubátor, System Engineer

Technický pohovor

Technický pohovor měl formu videocallu, cca 1-1,5 hodiny a povídali jsme si o tématech Computer Science, Software Engineering, Distributed Systems a Functional Programming. Ptali se mě mmj. na věci jako:

• Agoritmy, speciálně Big O notation a Tree traversal
• Monads, Referential transparency, Covariance/Contravariance
• CAP Theorem, Partition tolerance

Potenciální další kolo bylo vědomostně ve stejném rozsahu, ale on-site, cca na 1/2 dne a "víc do hloubky".

Reflexe

Byl to můj první "start-up" pohovor v životě a tak mě dost zaskočilo tunelové vidění pohovorujících. Dvě třetiny otázek jsem nebyl schopný zodpovědět, protože:

• jsem je v praxi nikdy nepotkal,
• brali jsme je před 12 lety na škole a od té doby jsem je nikdy ani prakticky, ani teoreticky nepoužil,
• nastudoval jsem si je před časem po večerech čistě z hobby-zájmu a nebyl je schopný z hlavy plynule přednést/vysvětlit (konkrétní příklad: před 5 lety jsem si nastudoval Hadoop, na blogu jsem se dostal jenom k zápisku o HDFS).

Z pohovoru i z následného (podmínečného) pozvání do dalšího kola jsem měl neodbytný dojem semestrální zkoušky - nastudovat, dostat zápočet, zapomenout. Když jsem se ptal, zda určité věci, na které se ptají, opravdu používají v praxi, otevřeně řekli, že ne, ale "tím si u pohovoru prošli všichni", tak by nebylo fér to v interview nemít i nadále.

Mým silným pocitem bylo, že si se mnou neví rady - jejich core business a technologie jsem neznal, zároveň "cítili", že "něco" vím (takže to nebylo na přímé zamítnutí), ale nevěděli, jak se k "tomu" dostat, jak se zaptat.

Přímým důsledkem tohoto pohovoru jsou dva články na blogu (CAP Theorem a Covariance & Contravariance) a téměř absolvovaný kurz Functional Programming Principles in Scala. Jaké bylo mé překvapení, když jsem zjistil že pohovorové otázky z funkcionálního programování kopírují témata z kurzu. Nic proti Martinu Oderskému - jeho kurz je výborný. Ale Scala je jen podmnožinou FP a některé věci nedávají v jiném jazyce smysl (třeba covariance/contravariance v Clojure).

Zpětná vazba

Musím ocenit následnou, celkem obšírnou zpětnou vazbu, kde byly v mailu rozebrány jednotlivé oblasti, s doporučením, na co bych se měl zaměřit, pokud bych chtěl pokračovat do dalšího kola.

Mindset

Fixed ⚔

Machine Learning start-up, Software Developer

Technický pohovor

Tady to nebyl úplně klasický přijímací proces - sešli jsme se opakovaně, na několik neformálních rozhovorů, kdy jsme se vzájemně přestavovali a poznávali. Nejvíce technické pak bylo řešení architektonicko-integračního zadání na white-board a firemní představení dvou projektů, hlavně z technického pohledu, kde jsem se mohl ptát spoustu technických otázek (předpokládám, že z toho se dá leccos poznat).

Reflexe

Velice příjemná forma pohovoru, postavená na vzájemném respektu (to není úplně samozřejmé). Musím ocenit přizpůsobení technické části mé aktuální roli a senioritě (celkem výjimečné).

Zpětná vazba

Vzhledem k neformálnosti a otevřené formě rozhovorů jsem měl pocit jakési "instantní" zpětné vazby.

Mindset

Growth ✔

Marketing eCommerce start-up, Functional Developer

Technický pohovor

Technický pohovor se skládal z rozhovoru o technických řešení z mé praxe a z implementace cons funkce... na papír.

Reflexe

Můj pohovorující byl evidentně velmi seniorní funkcionální programátor. Bohužel, jsme nenašli společnou platformu pro diskuzi o technických řešení. Pokud popisujete integraci přes RESTové služby na úrovni API a jste neustále přerušováni dotazy co přesně v ten moment chodí v hlavičkách na úrovni TCP protokolu a ani po 30 minutách se nedoberete bodu, kdy si sladíte terminologii; máte problém - pokud nejste schopni se domluvit na pohovoru, těžko to budete zvládat později v práci.

V programování na papír jsem extrémně slabý. Re-implementaci nízhoúrovňových funkcí považuji za ztrátu času (pokud zrovna na škole nestudujete předmět Algoritmy).

Zpětná vazba

Zpětná vazba byla, že pro core business firmy nejsem vhodný, ale "kdybych nebyl tak drahý", tak bych se mohl věnovat vedleší činnosti - přesýpání dat, klidně v Clojure, kde by to nebyl takový problém. Doufám, že se mi podařilo zachovat poker-face.

Mindset

Fixed ⚔

Český internetový hegemon, Developer of Advanced Systems

Technický pohovor

Prvně jsem online absolvoval Java test na Codility. Šlo o dvě úlohy, které bylo potřeba vyřešit a odevzdat během 90 minut. První úloha byla naimplementovat algoritmus na prokládání řetězců, něco jako: 12 + 98 = 1928. V druhé úloze jsem měl vymyslet(!) a naimplementovat algoritmus na počet kroků v geometrické spirále.

Pak jsem byl pozván on-site na pohovor s HR paní, v jehož závěru jsem psal na dedikovaném počítači kombinovaný Java-Python-C++ test, 75 otázek během 45 minut (nevím, jestli si správně pamatuji ten čas, každopádně to byla míň než minuta na otázku). Třetina otázek byla z Javy, třetina z Pythonu, třetina z C++.

Reflexe

Nemám slov. Tak špatně udělané technické kolo jsem během své kariéry ještě nezažil. Jsou to takové ty absurdity života, kdy přemýšlíte, jestli nejde o nějakou skrytou kameru. A když za váma zaklapnou dveře, máte potřebu se hystericky smát, abyste neztratili pojítko s vesmírem, který jste doposud obývali, než jste vsoupili do budovy.

Docela by mě zajímaly myšlenkové pochody člověka, který takovou frašku "designoval". Ještě bych tak akceptoval Codility jako jakýsi filtr pro ne-programátory. Byť vymýšlení algoritmu s tikajícíma hodinama v pozadí patří spíš do ranku "konkurz na McGyvera".

On-site test pak rezignuje na jakoukoliv konvenční racionalitu:

• 2/3 testu nemají relaci jak ke kandidátově minulosti (v Pythonu jsem nikdy komerčně neprogramoval, v C++ ani jako hobby), tak potencionální budoucnosti (šlo o čistou Java pozici). Asi množstevní sleva, nebo snaha ušetřit.
• Cca 40 sekund na otázku je asi z důvodů, aby kandidát nepřemýšlel, případně mechanicky tahal z trouby rozpečené polotovary.
• Ad absurdum dotažené obskurnosti syntaxe daného jazyka ve stylu "kompilátor v hlavě intoxikované LSD".
• Java array je "first class citizen", zapomeňte na cokoliv, co přišlo po Java 1.1. Třeba znalosti Javy 8 nejlíp otestujete tak, že se tváříte, že kolekce nikdy neexistovaly.

Zpětná vazba

Nesmím opomenout zdůraznit: nulová zpětná vazba:

"Pro další jednání jsme upřednostnili uchazeče, kteří přesněji odpovídali aktuálním požadavkům pozice."

Mindset

Extremely Fixed ⚔

Big Data start-up, Erlang Developer

Technický pohovor

Prvním krokem bylo programovací zadání, s deklarovanou náročností cca 1/2 dne, které mělo být odevzdáno do 24 hodin. Zadání bylo velmi vágní. K vypracovanému zadání přišly připomínky, které jsem měl zhruba do týdne doimplementovat a znovu odeslat. Odevzdání probíhalo mailem.

Následovalo on-site kolo, kdy jsem postupně mluvil s dvojicí sysadminů/operations, dvojicí architektů a dvojicí vývojářů (Java a Erlang).

Se sysadminy jsme si povídali hlavně o unixu a jak hledat problémy v produkčním prostředí. S architekty jsme si u white-boardu popovídali o jednom z mých projektů.

S Java vývojářem jsme si (tuším) povídali o vypracovaném zadání. Bohužel si víc nepamatuji, protože to všechno přebyl jeden detail (viz reflexe). S Erlang vývojářem to byla klasika - přinesl si papír a tužku. Už tušíte, že jo? Naimplementovali jsme si funkci na parsování regulárního výrazu.

Reflexe

Programovací zadání bylo celkem zajímavý - naimplementovat RESTovou službu s určitou business logikou. V čem jsme se podstatně rozcházeli, byla časová náročnost - z mého pochopení zadání by toto zvládnul naprogramovat za půl dne jenom superman. Já jsem na zadání, i s dopracováním, strávil 2 MD čistého času a i tak významně prioritizoval, co jen nastínit a co udělat v rozumné kvalitě.

Co mě dost otrávilo, bylo dopracování zadání - doimplementovat persistenci. Jakože cože?!? To je zadání pro studenty průmyslovky?!? Kdybych to měl řešit na pohovoru já, tak si o tom tváří v tvář popovídáme a za 5 minut se není o čem bavit. Aby to pro mne nebyla ztráta času, aspoň jsem si vyzkoušel verzování databáze přes Flyway (zůstalo nepovšimnuto).

Rozhovory se sysadminy a architekty byly celkem očekávatelné a nemám, co bych vytknul, či vyzvedl. S programátory to byla jiná. Začněme Javou. Napsal jsem v zadání kus takovýhleho kódu:


Když pominu design (brilantní kód zkrátka na první dobrou nepíšu), obsahuje tenhle kód jeden podstatný problém - iteruje se přes mapu, místo aby se k ní přistupovalo přes klíč. Pohovorující kolega mne na tento detail upozornil.

• "Ano", říkám, "to je chyba".
• "Byl jste ve stresu, když jste to psal?", ptá se.
• "To bych ani neřekl, spíš jsem některým věcem dával nižší prioritu - postatný pro mne byl fungující, buildovatelný a spustitelný projekt.", vysvětluji.
• "No dobře, ale z mapy se hodnoty vytahují přes klíče, to je přece základ.", vrací se k tématu.
• "Ano", souhlasím, "byla to chyba."

Takhle to ještě chvilku pokračovalo, až se z toho stal nejsilnější pocit z interview - já jsem ten pro kterého je normální iterovat přes mapu, místo použití klíče. Je smutné, když se dva seniorní vývojáři baví o takové trivialitě tak dlouho a navíc spolu od počátku souhlasí. Ale možná, že mnou spáchaný hřích přehlušil veškerou další komunikaci.

No budiž, je to pohovor na Erlang programátora, nechme Javu odpočívat v pokoji. Takže: v praxi, stejně jako na pohovoru, je důležité:

• Programovat na papír.
• Re-implementovat esenciální core funkce jazyka (regex match)
• Předpokládat, že funkcionální termíny jsou obecně platné, bez ohledu na kontext (přece když řeknu list, tak je jasné, že myslím spojitý seznam z cons buněk - žádné jiné typy seznamů přece neexistují).

Myslím, že o funkcionálních programátorech možná napíšu satirický článek.

Zpětná vazba

Hodně zklamaný jsem byl ze zpětné vazby - do pohovorů jsem investoval 2,5 MD čistého času (zadání + pohovory) a výsledkem byly dvě věty:

"Ačkoliv kolegové hodnotili setkání s Vámi jako zajímavé, bohužel do finálního kola budeme zvát jiného kandidáta. Dle kolegů se zcela nepotkávájí Vaše dosavadní znalosti s technickou profilací naší role a nebyli bychom schopni plně využít Vaše zkušenosti."

Vezměte si dení sazbu seniorního vývojáře za 2,5 MD a na druhou misku vah položte informaci, že jste "zajímavý". Neocenitelné, což?

Mindset

Fixed ⚔

Data Management produkt, Java Developer

Technický pohovor

Byl jsem požádán o zaslání odkazů na své public repository. Poslal jsem link na Bitbucket a GitHub a vypíchnul jsem dva hobby projekty (oba v Groovy).

Následovalo on-site technické kolo, kde dva seniorní vývojáři převáženě zodpovídali mé otázky o své práci. Překvapivě jsem se o jejich technickém řešení dozvěděl méně, než z předešlého rozhovoru s CTO, který mi nakreslil a vysvětlil blokové schéma. Vývojáři jen povídali a asi předpokládali, že už všechno vím.

Na prodiskutování mého kódu nezbyl čas, vybavuji si jen jednu povšechnou otázku na Groovy/Gradle. Na závěr byla půl hodina live-programování v Javě, implementace algoritmu procháze bludiště... v NetBeans IDE.

Reflexe

Že jsme neprobírali můj kód, považuji za chybu. Já chci před pohovorem kandidátův kód nejen vidět, ale hlavně ho s ním prodiskutovat. Jak říká Linus: "Talk is cheap. Show me your code." Ta diskuze je důležitá - pokud si z něčeho uděláte představu, aniž byste znali kontext, dojdete pravděpodobně k mylným závěrům.

Závěrečné live-programování považuji za druhou nejhorší zkušenost z popisovaných technických kol. Jako jediné pozitivní hodnotím, že jsem požadovaný algoritmus nemusel vymýšlet, ale byl mi vysvětlen.

1. Programování probíhalo v NetBeans IDE, které nejen že nepoužívám já, ale ani nikdo v inkriminované společnosti! Na otázku: "Jak se v NetBeans dělá XYZ?", vám odpoví: "Nevím."
2. Před-připravený "projekt" v IDE, byla jediná Java třída, zabírající vertikálně asi 5 obrazovek.
3. Top třída obsahovala několik vnitřních tříd (i doménových). Trochu mi to připomnělo Javu před 10 a více lety, ještě než se rozmohly best-practices a Spring.
4. Top třída vesele kombinovala static a non-static membery, kteří se vzájemně provalávali.
5. Před-implementovaná část nahodile kombinovala procedurální a objektový přístup.
6. Projekt neobsahoval žádnou přípravu pro unit testy, byť mi bylo řečeno, že pokud chci, můžu si testy napsat. Ano, pokud mám na zadání 30 minut, budu v IDE, který neznám rozcházet jak spustit unit testy (co třeba závislosti?).
7. Pohovorující seděl celou dobu naproti mně a neviděl, co píšu. Prostě čekal, až skončím.

Přiznám se, na tomhle cvičení jsem pohořel. Ne že bych nic nenapsal, ale byl jsem trochu paralyzován. Asi na mě byl žalostný pohled, protože jsem byl požádán, abych napsal metody equals a toString. Nevěřícně jsem tak učinil.

Na závěr jsem byl požádán o zhodnocení. Přiznal jsem porážku a snažil se být diplomatický ve vysvětlení. Zakončil jsem tím, že daný kód, ten před-připravený projekt, by chtěl těžce zrefaktorovat.

Teď už být diplomatický být nemusím: Myslím, že je ostuda takový špatný kód ukázat kandidátovi na pohovoru. Je to první kód, který kandidát od firmy vidí. Pokud tato nemá problém ukázat něco takového, jako svou vizitku - rozumněj, něco čím můžu kandidáta nalákat - jak pak asi vypadají její produkční kódy?

Možná, že ve skuktečnosti píšou interně nesrovnatelně lepší kód. Potom ale hodně zanedbávají pohovory. Říkám si, jaké kandidáty asi chtějí tímto způsobem nabrat?

A ještě jedna poznámka - opět jedna z těch firem, kde musíte umět Java array jak když bičem mrská. Že od Java 5 používáte výhradně collections framework a v polích už nejste tak "fluent" jako kdysi, není argument.

Zpětná vazba

Zpětná vazba bylo dvojí. Jednak, hned po interview, mne zaskočila informace, že mne pohovorující kolegové "nepovažují za programátora". Budiž, názor je potřeba respektovat.

Následně jsem pak mailem dostal vyrozumění, které považujuza ilustrační příklad fixního mindsetu:

"Vaše zkušenosti a schopnosti jsou velice seniorní, bohužel však Vám nemůžeme nabídnout odpovídající pracovní pozici, kde byste tyto schopnosti uplatnil. To co děláte opravdu velmi dobře a na co se ve své práci zaměřujete, bohužel neodpovídá tomu, na co bychom se aktuálně v <jméno firmy> zaměřovali a není to v plánu ani v dohledné době, nebyli bychom tedy schopni Vám nabídnout odpovídající výzvy a začlenit Vás do některého z týmů."

Holt, s čím se jednou narodíš, s tím si musíš vystačit až do smrti. Proces učení se je iluze.

Mindset

Fixed ⚔

Velká (nejen) Java korporace, Big Data Engineer

Technický pohovor

Prvním kolem bylo zadání, které se skládalo ze tří částí:

1. Programování RESTové služby s určitou business logikou.
2. Doménový design jednoduché/zjednodušené business domény.
3. Návrh solution pro zpracování nekonéčného streamu.

Na vypracování zadání jsem měl zhruba týden (minimálně 1. část), až dva. Řešení jsem komitoval do soukromé repository na GitHubu.

Druhé kolo bylo on-site, kde jsem se po dvojicích sešel s implementačním týmem: senior + standard(?) vývojáři, senior sysadmin + standard(?) vývojář.

S první dvojicí jsme si povídali o programovacích jazycích a pak jsem na white-boardu:

• Vysvětlil řešení, na "které jsem pyšný" (granularita webových služeb v SOA řešení).
• Navrhnul monitorování distribuované platformy.
• Implementoval v Javě reverse Stringu, bez použití StringBuilder.reverse(). 

S druhou dvojicí jsem odpovídal na "linuxové" otázky a pak jsme si hlavně povídali, jak vypadá práce u nich.

Reflexe

Programovací zadání bylo celkem zajímavý a docela jsem si ho užil. Protože bylo velmi volné (to je rozdíl oproti vágní), tak jsem se rozšoupnul a půlku jsem naimplementoval ve Scale a půlku v Javě (že by potenciální článek?). Designové řešení doménového modelu bylo přímočaré, nic zvláštního.

Poslední část, streamové řešení, je pro mne exotické. Strávil jsem cca týden pročítáním internetu, abych se zorientoval a pak od stolu navrhl řešení v Clojure a jako zálohu Spark Streaming, s poznámkou nutného ověření (o Sparku nic nevím).

On-site práci na white-boardu hodnotím částečně pozitivně (popis mého řešení a monitorování), částečně negativně (programování a re-implementace core funkce). Programovat se má na počítači.

Jelikož většina pohovorujících měla z nějakého důvodu alespoň částečně načtený můj blog, cítil jsem během on-site pohovorů trochu přehnaný respekt, jenž nebyl adekvátní.

Zpětná vazba

První, krátkou zpětnou vazbu jsem dostal emailem po komitu prvních dvou částí zadání. Zbývající, opět krátkou, na začátku on-site interview.

Týden po on-site pohovoru jsem dostal další telefonický feedback. Řekl bych, že strukturovaný a vyvážený. Minimálně přesně pojmenoval mé slabší stránky.

Mindset

Growth ✔

Jak to zlepšit?

Mé hledání nové práce je momentálně u konce a doufám, že to minimálně dalších 5 let nebudu muset řešit. Shodou okolností a preferencí, se v blízké budoucnosti nebudu technickým hiringem zabývat. Jelikož ale pohory byly historicky vždy silným tématem tohoto blogu, měl bych aspoň doporučení (či zbožné přání):

Patero technického recruitera

1. Udělejte technické kolo co nejvíce praktické.

Nechte kandidáta vypracovat zadání. Udělejte s ním on-site workshop (jde to i přes Skype). Mějte zadání dostatečně volné, abyste kandidáta zbytečně netlačili do své škatulky. Nenuťte kandidáta programovat na white-board a už vůbec ne na papír! Neprogramujete děrné štítky.

2. Nechte si ukázat a vysvětlit kandidátův kód.

Uvidíte reálný kód, který vzniknul v určitém kontextu. Zadání, či workshop (předchozí bod) je pořád v laboratorních podmínkách, které nemusí každému sednout.

3. Testujte kandidáta na praktické věci, které reálně děláte.

Vykašlete se na re-implementaci algoritmů a core funkcí jazyka - nic podstatného pro váš business tím o kandidátovi nezjistíte. Naopak tím odfiltrujete slušné procento lidí, kteří excelují v něčem jiném. A zapomeňte na idiotské úlohy typu "kolik golfových míčků se vejde do letadla".

4. Nezkoumejte současný snapshot, hledejte projekci do budoucna.

Pokud něco neroste, je to pravděpodobně mrtvé. Současné kvality kandidáta jsou jen startovní bod. Snažte se najít jeho budoucí trajektorii.

5. Hledejte lidi s historií a schopností učit se.

Cílem nemusí být najít dokonalý technologický "match". Ale najít někoho flexibilního, kdo se potřebné věci rychle naučí, či do dané role doroste.

"You don’t hire for skills, you hire for attitude. You can always teach skills." ~ Simon Sinek

Související články

• Jak dělají Java pohovor jinde
• Kontrakt místo pohovoru, je to reálné?
• Měl by mít vývojář portfolio?
• Jak dělám Java pohovor II: proč nedávám testy?

Související externí články

• Pohovory (calavera.info)
• Zpráva o stavu IT trhu (Banter bloguje)
• Mladý kolektiv (Javorové lístky)
• Prečo startupy nemajú šancu získať seniorných vývojárov (Riki Fridrich)

Jak dělám Java pohovor IV: Java workshop

Zcela bezkonkurenčně nejčtenějším zápisem na mém blogu je opus magnum Jak dělám Java pohovor. Jeho čtenost je řádově vyšší, než u zbytku veškerých textů. Ten článek už je skoro pět let starý a neodpovídá (mojí) realitě.

Věci, které za to stojí, se snažím vylepšovat, takže je v důsledku dělám jinak. A pokud máte to štěstí, že si můžete vybírat lidi k sobě do týmu, tak by vám na tom mělo záležet. Hodně. A tak si ty poslední tři, čtyři roky říkám, že bych měl svůj zápis zaktualizovat. Jak tedy dělám pohovor dnes?

Agenda Java interview

Agenda pohovoru zůstala hodně podobná:

1. Představím se já.
2. Prostor pro otázky kandidáta a/nebo představení společnosti, business domény, našeho oddělení a projektů.
3. Diskuze nad kandidátovým projektem.
4. Review kandidátova kódu.
5. Java workshop

Drobnou změnou je bod číslo 3, diskuze nad kandidátovým projektem. Velkou a stěžejní změnou je pak titulní Java workshop.

Diskuze nad kandidátovým projektem

Dříve jsem v tomto bodě probíral kandidátovo CV, ale postupně se to vyvinulo v diskuzi nad konkrétní zkušeností. Přijde mi to zajímavější a přínosnější, než diskuze nad "suchou historií".

(Mimochodem, kandidáti mají neuvěřitelně zažitou historizaci svojí praxe. I když jim opakovaně explicitně zdůrazníte, že nechcete slyšet chronologicky odříkanou pracovní zkušenost, většinou vás naprosto ignorují a spustí naučený kolovrátek. Hanba vám HR a head-hunteři!)

V dnešní době se tedy ptám na projektovou zkušenost ve stylu:

"Mohl byste mi popsat Váš poslední, nebo poslední úspěšný projekt? Zajímají mě hlavně technické aspekty - mohl byste mi popsat a ideálně namalovat architekturu, či design vašeho vybraného projektu? Dále by mě zajímalo, jak byl projekt řízen, jaké role se na něm podílely a jaká byla Vaše role? Co třeba nějaké disciplíny SW inženýrství? Release management? Source code management? Issue tracking?"

Většinou se mi podaří kandidáta (přátelsky) přimět k namalování nějakého schématu na whiteboard. To má dva aspekty. Jednak se nad vizualizovanou architekturou/designem dobře diskutuje. A jednak poznáte, jak je na tom kandidát ohledně schopnosti vysvětlit technické věci, znalost modelování, uvědomění si "big picture", kontextu daného projektu a spoustu dalších věcí.

Ilustrační příklad whiteborard architektury

Java workshop

Když jsem pozměněnou podobu interview vymýšlel, chtěl jsem něco, co bude co nejblíž způsobu, jakým bych chtěl, abysme v týmu pracovali. Tedy: komunikovali spolu a uměli diskutovat nad kódem a designem. A samozřejmě... psali kód, ideálně s unit testy.

Začínám tím, že si s kandidátem sedneme vedle sebe a předložím mu - podle vybraného příkladu - následující obrázek (pro nadcházející odstavce, považujme za dané zadání návrhový vzor Observer):

Class diagram návrhového vzoru Observer

Zeptám se kandidáta, jestli zná UML a daný návrhový vzor. Pokud ano, tak ať jedno, druhé, či oboje vysvětlí. Pokud ne, řeknu nevadí a obojí vysvětlím já. Tahle část trvá krátce, většinou tak do pěti minut a jejím hlavním smyslem je porozumět zadání. A teď přijde to hlavní.

Otevřu notebook a... ukážu kandidátovi "skeleton" projektu natažený v IDE. Vypadá to nějak takhle:

Skeleton Java projektu v IDE

Jak je vidět na obrázku, i na UML diagramu výše, v projektu jsou dvě rozhraní a dvě implementační třídy. Ty konkrétní třídy "implementují" metody z interfaců, ale jsou prázdné. Čili, jde to zkompilovat, ale nic to nedělá.

Rozhraní a jeho prázdná implementace

Malá vsuvka, pokud vás to napadlo - v tom IDE to mám připravený v Eclipse a v IntelliJ IDEA. Dřív jsem to měl připravený i pro NetBeans, ale pak jsem to přestal udržovat - za ty čtyři roky mi na pohovor nepřišel nikdo, kdo by chtěl v NetBeansech dělat.

Zpátky k projektu. Kromě produkčního kódu jsou tam připravený - opět prázdný - třídy pro testy. Pokud by vás zajímalo, jak přesně ten startovní projekt v IDE vypadá, podívejte se na můj repositář na Bitbucketu: https://bitbucket.org/sw-samuraj/hiring/overview

Vysvětlím kandidátovi strukturu projektu a řeknu něco jako:

"Takže, tady máme prázdný projekt (pro návrhový vzor Observer) a zkusíme si ho naimplementovat. Pokud znáte, nebo jste dělal nějakou reálnou implementaci tohoto vzoru, můžete zkusit udělat ji. Anebo můžeme zkusit naimplementovat ten vzor jako takový, dejme tomu ukázkový příklad.

Záleží jen na Vás s čím začnete, jestli s implementací, nebo s testy a já jsem tady proto, abych Vám pomohl v případě problému. A v průběhu toho, jak budete psát, se Vás budu ptát na některé aspekty Vašeho kódu.

V projektu můžete cokoliv změnit, je zde jen jedno pravidlo - nesmíte nijak upravovat interfacy."

A je to. Kandidát začne psát, já se dívám, občas se na něco zeptám. Když se nám to zadrhne, jemně kandidáta navnadím, nebo popostrčím. Občas něco do kódu napíšu i já sám.

Každý kandidát je naprosto jiný. Někdo to celé vystřihne za půl hodiny i s pěknými unit testy. Někdo za stejnou dobu stačí vyrobit jednu metodu, která přidává prvky do kolekce. V průměru strávím touhle částí zhruba 40-50 minut.

A je to. Interview krátce zakončím a rozejdeme se.

Jak workshop vyhodnotit?

V momentě, kdy workshop skončí, už mám většinou jasno, jestli chci mít kandidáta v týmu, nebo ne. Někdy jsem na pochybách a je lepší se na to vyspat, nebo prodiskutovat s někým nezúčastněným.

Jinak vás asi zklamu - neprozradím vám žádné tajemství, jak z té cca hodiny programování udělat výsledek. Pro mne to byla dlouhá cesta, během které jsem mířil k jakémusi ideálu. Proto nepotřebuju nějaký checklist, abych věděl, jestli tam - s kandidátem - jsme, nebo ne.

Pokud vám minulý odstavec nedává smysl, nebo mu nerozumíte a přesto byste chtěli vědět, jak worshop vyhodnotit, zkuste se inspirovat těmihle aspekty:

• Jak kandidát komunikuje? Během vysvětlování zadání a během programování.
• Jak efektivně pracuje v IDE? (Na oblíbené IDE se ptám ještě před pohovorem, takže by to neměl být stresující faktor, že programuju v něčem nezvyklém.)
• Jak hezky/čitelně/čistě/efektivně píše kód?
• Jak designuje/strukturuje metody, třídy, testy?
• Jak píše testy? Jestli vůbec. A kdy? Předtím, potom, zároveň?
• Zajímají vás nějaké seniornější aspekty? Klidně se můžete ponořit do věcí, jako je specifická implementace některého Java API, nebo třeba do Reflection API (fakt, vyplyne to úplně přirozeně).
• Chcete si ověřit znalost konkrétní verze Javy? 6, 7, 8? Žádný problém, jde to.
• Jak kandidát komunikačně a znalostně reagoval na navržené alternativy?

Určitě vás napadne něco dalšího.

Co už nedělám

S odkazem na původní článek, bych vypíchnul věci, od kterých jsem upustil. V první řadě, už se nevrtám v CV. Ani před pohovorem, ani během. Životopis si většinou jen rychle proběhnu před phone screenem, jestli mě tam něco nezaujme - třeba jestli má kandidát zkušenost s (business) analýzou, architekturou, team leadingem apod. Prostě nějaký přesah za vývojařinu.

A potom, už nedávám hlavolam. I když tahle část bývala celkem zábavná, tak jsem ji odstranil - když jsem před těmi čtyřmi lety nově definoval, jak bych chtěl pohovor pojmout, zaměřil jsem se na to, aby to bylo co nejbližší denní realitě. A tam prostě vývojáři mechanické hlavolamy neřeší. (Čest výjimkám.)

Jak dál?

Pohovor tímto způsobem dělám poslední čtyři roky a musím přiznat, že po té době je to pro mne už příliš velká rutina. Chce to změnu. Zatím čekám na inspiraci. Je možné, že tenhle článek čtete v přelomovém období - takže jestli se někdy potkáme spolu na pohovoru, dost možná, že bude vypadat jinak.

No dobře, Java. Ale co .Net?

Z minulých dvou let mám zajímavou zkušenost. Poprvé v životě mě potkalo štěstí, že jsem se stal mentorem. Jako tím opravdovým, kdy se vztah mentor-mentee "samovolně", organicky vytvoří. Pikantní na tom je, že můj mentee není Javista... je to .Neťák!

No. Kromě jiného jsme spolu řešili také .Net pohovory. Z dnešního pohledu to vlastně nebylo nic těžkého - vzali jsme můj Java pohovor, vytvořili .Net workshop a bylo to.

Podstatné je, že to výborně fungovalo a dnes tak máme úspěšný nový .Net tým. Zkušenosti zkrátka občas přijdou ze strany, odkub byste to nečekali.

Předešlé díly

• Jak dělám Java pohovor
• Jak dělám Java pohovor II: proč nedávám testy?
• Jak dělám Java pohovor III: phone screen

Související články

• Jak se nabírají Javisti na Filipínách
• Jak dělají Java pohovor jinde
• Měl by mít vývojář portfolio?
• Kontrakt místo pohovoru, je to reálné?
• Geek, který zapadne

Jak dělám Java pohovor III: phone screen

Technickému recruitingu se věnuji už nějaké čtyři roky. Je to činnost, která mě hodně baví a tak jako u jiných aspektů své práce, jsem si vypěstoval určitý postup. Zároveň se snažím věci pořád zlepšovat a korigovat, jak studiem, tak praxí.

Phone Screen

Jedna z věcí, ke kterým jsem došel a považuji ji za nutnost, je phone screen. Jediný případ, kdy ho nedělám, je buď že mám s daným člověkem přímou pracovní zkušenost, anebo jsme se předtím už osobně setkali - to se stává, pokud třeba někdo zareaguje na můj inzerát.

Poslední dobou si hodně čtu o agilním přístupu (i po těch letech se člověk pořád má co učit) a věc, která se mi stále vrací a furt si ji musím připomínat - každý mítink musí mít smysl. Fajn, jaký je tedy pro mne smysl phone screenu? Podívejme se, co stojí v soukromém samurajském slovníku:

Phone Screen: Je to první, krátký a efektivní kontakt s potencionálním kolegou, který zodpoví jedinou otázku - má smysl se osobně vidět a pokračovat ve vzájemném získávání informací?

Proč používám termín phone screen a ne třeba "telefonní pohovor"? Inu, to proto, že je to krátké a přesně to vystihuje svůj účel. Uznejte - "telefonní filtrování" zní blbě samo o sobě a poslat kandidátovi pozvánku s takovým předmětem by asi nebylo zrovna vstřícné. 

Struktura

Můj phone screen má vždy stejný začátek. Zavolám, představím se jménem a firmou a řeknu: "Tento phone screen by měl trvat 30 minut a projdeme si následující kroky:

1. představím se já,
2. představí se kandidát z hlediska technologií,
3. technické otázky,
4. kandidátovy otázky."

Pak si cca 30 minut povídáme, během té doby bedlivě sleduji čas, a po půl hodině rozhovor ukončím.

Pokud se podívám blíže na jednotlivé body:

Představím se já, tedy, znovu zopakuji svoje jméno, řeknu svoji formální pozici a krátce vysvětlím obsah své práce. Myslím si, že je to fér vůči kandidátovi - dát mu nějaký kontext, aby věděl, s kým asi tak mluví.

Představí se kandidát z hlediska technologií. Jediná informace, kterou o kandidátovi v tento moment mám, je zpravidla pouze jeho CV. Což je dost slabá a nevěrohodná informace. Požádám proto kandidáta, aby se mi představil z hlediska technologií. Zdůrazním, že mě nezajímá klasické "odříkávání" životopisu, stejně tak, jaký byl business význam projektů, nebo aplikací, na kterých se podílel. Co mě zajímá, je jeho současný technologicko-seniorní "snapshot".

Myslím, že je to celkem logické - nenajímám odborníka na nějakou business doménu, ani business analytika, ale vývojáře. Takže mě zajímají technologie, frameworky, architektura atd. Bohužel, lidé dost často tuto otázku ignorují a spustí naučený kolovrátek. Pokud se tak stane (pořád sleduju ten čas), vrátím je zpátky k původní otázce.

Technické otázky. Jedním z cílů předchozí části je zjistit kandidátovy silné technologické stránky. Říkám o sobě (ohledně pohovorů), že jsem hodný, ale spravedlivý. Takže se ho ptám na věci, o kterých říká, že je dobře zná. Samozřejmě, musím ty věci dobře znát i já. Ale vzhledem ke svému stáří a senioritě ;-) vždycky najdeme slušný průnik. Někdy se i kandidáta přímo zeptám: "Jaké jsou momentálně dvě Vaše nejsilnější technologie?".

No a pak začneme na povrchu, u triviálních a základních věcí a jdeme hloub a hloub, až se někde naše znalosti zastaví - narazíme na lokální minumum. Pokud se to stane, nebo se téma vyčerpá, nebo pokud přes veškerou snahu zůstaneme stále na hladině, přejdu k dalšímu (silnému) tématu.

Pro představu jak může tahle část vypadat, dejme tomu, kandidát říká, že dobře zná JPA, či Hibernate. Můžeme začít třeba otázkou "Na jakém principu tahle technologie funguje?", nebo "Jaký je vztah mezi JPA a Hibernate?".

Pak se podíváme na mapování pomocí metadat. Můžou to být otázky typu "Které dvě anotace/XML elementy jsou nezbytně nutné, aby framework mohl používat (POJO) třídu jako entitu?", či "Které anotace při mapování běžně používáte?". Podstatné je, že nevyžaduji přesné názvy, ale jestli kandidát rozumí o čem mluví a principům, na kterých to funguje.

A jdeme hlouběji - jaké mohou být vztahy mezi entitami, jaké jsou strategie pro získávání dat a která z nich je defaultní pro daný typ vztahu? Jak se řeší složené klíče? Na téhle úrovni složitosti často opustíme mapování entit a podíváme se na jiná zajímavá témata - přece jenom, děláme phone screen a času je málo.

Můžeme si popovídat třeba o EntityManageru, nebo o Session. Pokud nám to spolu klape, můžeme se dostat až k transakcím, nebo co to je PersistenceContext a PersistenceUnit. Někdy dokonce dojde i na lifecycle entit :-)

Ať už se dostaneme kamkoliv, je podstané, jak jsme si o tom popovídali. Už jsem zmiňoval, nejde mi o žádné odříkávání slovníkových dat a in-memory znalostí. Jde mi o porozumnění a rozsah, které by mělo odpovídat dané úrovni seniority. Jednotlivé otázky, jak úvodní, tak usměrňující vybírám intuitivně, nemám žádný mustr, podle kterého jedu.

Když se čas nachýlí, je prostor pro kandidátovy otázky. Kandidát mi věnoval cca 25 minut svého času a tak je fér mu otevřeně zodpovědět, co by ho zajímalo. Možná si říkáte, že 5 minut na otázky není moc, ale většinou to bohatě stačí - moje zkušenost je taková, že nadpoloviční většina lidí nemá žádné otázky, nebo tak jednu dvě. Pokud je někdo zvědavější a má otázek víc, i já mu (rád) věnuji víc času.

Zakončení

Jakmile jsou otázky za náma, zbývá říct už jen dvě věci - co bude následovat a rozloučení. Co následuje po rozhovoru? Za pomocí svých poznámek (viz dále) sepíšu jednoduché hodnocení s pozitivním, nebo negativním výsledkem, který se kandidát vzápětí dozví. Pozitivní skóre se rovná pozvání na osobní pohovor.

Jak si píšu poznámky

Když jsem s phone screeny začínal, psával jsem si poznámky přímo do vytištěného CV. Není to dobrý způsob - každé CV je jinak formátované, velikost bílých ploch na psaní je proměnlivá, je to neuspořádané atd. Jedinou výhodou je, že CV a poznámky jsou pohromadě.

Časem jsem ale zakomponoval lepší metodu - přímo během pohovoru si kreslím mind mapu. Stejnou metodu pak používám i u osobního pohovoru (Je to konzistentní a dobře se v tom hledá). Výhodou mind mapy je, že si daleko lépe připomenete, o čem jste si povídali. A taky to lépe vypadá. Navíc, mind mapa se mnou zůstane - zpracovaná CV vyhazuji, ale mind mapy si schovávám a archivuji.

Související články

• Jak dělám Java pohovor
• Jak dělám Java pohovor II: proč nedávám testy?
• Jak se nabírají Javisti na Filipínách
• Jak dělají Java pohovor jinde
• Měl by mít vývojář portfolio?
• Kontrakt místo pohovoru, je to reálné?
• Geek, který zapadne

Jak dělám Java pohovor II: proč nedávám testy?

Image courtesy of Michal Marcol
FreeDigitalPhotos.net

Je to už nějaký pátek, co jsem napsal (úspěšný) článek Jak dělám Java pohovor. Byl to pro mne výsledný stav určitého vývoje a shrnutí zkušeností z vedení technických (převážně Java) pohovorů, kterých jsem měl tehdy za sebou pár desítek.

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.

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

Související články

• Jak dělám Java pohovor
• Jak se nabírají Javisti na Filipínách
• Jak dělají Java pohovor jinde
• Měl by mít vývojář portfolio?
• Kontrakt místo pohovoru, je to reálné?
• Geek, který zapadne

Jak se nabírají Javisti na Filipínách

Tak nějak se přihodilo, že poslední tři, čtyři roky dělám permanentně technické pohovory s Java vývojáři. Za tu dobu to byly desítky pohovorů. V nové práci jsem to povýšil na další stupeň, když jsem začal dělat občasné remote interview přes Skype a mohl si tak popovídat třeba s lidmi z Brazílie, nebo Indie.

Minulý měsíc se to posunulo ještě dál. Naše společnost otevírá nové delivery centrum v Manile na Filipínách. Bude to základna naší divize pro asijské projekty. Jedním z primárních kroků je vytvořit core team - technical lead, Java vývojář, C# vývojár, integrátor a validator (tester) - který bude schopný autonomně fungovat a eventuálně se postupně rozrůstat.

Že dělám Java pohovory se o mně (minimálně interně) ví, takže jsem dostal nabídku podílet se na výběru lidí pro nový core team.

Místo činu

Pokud jste, tak jako já, neabsolvovali zeměpis v 80tých letech (do dneška si pamatuju skoro všechny hlavní města světa), možná vám přijde vhod pár informací pro navození prostředí.

Filipíny jsou lidnatá země (98 mil. obyv.), s Českem má bezvízový styk, uředními jazyky jsou Filipínština a Angličtina. Hlavním městem je Manila, která je jedním ze 16 cities, které tvoří metropolitní oblast Metro Manila (12 mil. obyv.). Každá pořádná metropole má svůj business district - v případě Manily je to Makati City, kde se také nachází pobočka naší firmy.

Panorama Makati City (zdroj Wikipedia)

Makati je celkem bezpečný region, kde se nemusíte, jako Evropan, bát chodit po ulicích. Nevím, nakolik je to pravda, ale byl jsem místními opakovaně varován, ať si dávám pozor (nebrat si taxíka na letišti, nenosit telefon v ruce, neustále sledovat svoje věci). Plus určitých věcí si člověk všimne sám: taxikář ihned po vašem nastoupení zamkne dveře, časté kontroly zavazadel v budovách, strážní se samopaly v mrakodrapech. A v den, kdy jsem odlétal, zastřelili na letišti starostu jednoho z filipínských měst. Zkrátka trochu jiný svět, než na který jsem zvyklý.

Pár nezávazných generalizací

Strávil jsem v Makati jeden týden a byl to můj první výlet mimo Evropu, takže by bylo pošetilé z toho vyvozovat nějaké obecné závěry. Spíš to berte jako něco, s čím se můžete setkat, pokud budete v podobné situaci. Takže...

Úroveň kandidátů je o řád nižší než v Praze. Když v Manile někdo řekne, že je senior (a třeba i má odpovídající léta praxe), bude to z našeho pohledu spíš junior. A to co se týče znalostí, zkušeností a bohužel i možností (viz dále). Setkal jsem se třeba s relativně seniorním člověkem, který rutinně psal unit testy, ale bez jediného assertu!?! Prostě to, že produkční kód provolám, je dostatečný test (vážně, on nevěděl, že asserty existují a byl vděčný, že se na pohovoru něco naučil).

Asie je továrna na code monkeys. Slyšeli jste někdy, že by programátoři dělali na směny? Tak na Filipínách je to běžná praxe. Jeden z nejčastějších důvodů pro změnu zaměstnání je, že nechtějí dělat noční směny. Velice často pracují u firem zvučných jmen (Accenture, Oracle, IBM, Logica/CGI), ale pouze jako offshore potrava pro děla. Analýza a QA jsou téměř vždy dělány onshore (z pohledu Filipínců distribuovaně, vzdáleně) a vývojáři dělají jenom mechanickou implementaci tasků, často bez porozumnění principům a souvislostem.

Holky jsou daleko schopnější, než kluci. Sám pro sebe jsem si to nazval "Asian Girl Power". Přiznám se, mám (pracovní ;-) slabost pro holky programátorky. Jsou zodpovědné, pečlivé, cílevědomé, odvádějí velmi dobrou práci (true story). Přesně takhle na mne zapůsobila většina kandidátek na pohovorech. Navíc, oproti českému IT, na Filipínách je běžné, že se holky věnují počítačům - poměr pohlaví na pohovorech byl lehce nakloněn k mužským účastníkům, ale ne nijak výrazně.

School  matters. Když dělám pohovory v Česku, tak zcela ignoruju, jakou má kandidát školu. Kolikrát ani neregistruju, jestli vůbec má univerzitní vzdělání. Prostě české zglajchšaltované školství. Ne tak na Filipínách, kde je situace dost podobná anglosaskému modelu. Pokud jste absolvent University of the Philippines (UP), patříte do extra ligy. Ještě ucházející je Polytechnic University of the Philippines (PUP). A pak už je to jedno. Hodně taky záleží na studovaném programu - pokud místo Computer Engineeringu studujete Electronics Communications Engineering, budete na tom, jako vývojář, dost špatně (co se týká znalostí, teorie a vyhlídek).

Zajímavé také bylo, že všichni kandidáti, bez výjimky, měli bakalářský titul. Žádný magistr, nikdo bez univerzitního vzdělání. Většinou je to tak, že po dodělání bakaláře jdou hned pracovat a školu si pak už nedodělávají.

Všichni Javisti dělají v Eclipse. No comment. (bez ironie ;-)

Místní Silicon Valley je Singapur. Je to tak, pro Jihovýchodní Asii je Singapur houba, která nasává ty schopné a telentované. A pokud je nasaje, už se nechtějí vrátit zpět.

Jídlo je fantastický! Nemusíte být fanoušek asijské kuchyně. Ale ta bohatost a rozmanitost chutí je v Evropě nepředstavitelná. Jeden příklad za všechny - čerstvé mango, oh yeah!! Navíc, filipínská kuchyně je úlně jiná, než thajská, vietnamská, čínská... Pro mne určitě důvod, proč se vracet.

Krab (900 g) v thajské čili omáčce

Jak dělat interview na druhém konci světa?

Cesta na Filipíny trvá letadlem něco mezi 17 a 22 hodinama. Takže si tam nezaletíte jen tak na otočku. Plus je tady časový posun - Filipíny leží v časovém pásmu GMT +8, což znamená dvě věci: jednak budete mít solidní jet lag a jednak se špatně domlouvají remote interview.

Když dělám pohovory v Praze, mám s každým kandidátem phone screen - je to prvotní filtr, jestli vůbec má smysl se s kandidátem vidět osobně. Vzhledem k časovému posunu Filipín jsme tuto možnost zavrhli a vydali se cestou testu. Nemám rád testy. Nesnáším je jako kandidát a nesnáším je jako pohovorující. Nicméně v tomto výjimečném případě jsem je vzal na milost jako přijatelný způsob screeningu.

Na tomto místě bych rád poděkoval svému kolegovi Banterovi, který velkou část testu vytvořil, já jsem do toho jenom tak filozoficko-strategicky kafral. Test je taková směska vytvořená s ohledem na potřebný profil - takže je tam něco z Java language, Java API, Enterprise Javy, SQL, unit testů, UML a Banterův oblíbený FizzBuzz ;-)

Ayala Avenue, Makati

Pokud byste se náhodou chtěli pouštět do podobného testu a chcete, aby měl nějakou vypovídací hodnotu, nezapomeňte si otázky ohodnotit - ne všechny mají stejnou váhu. Taky je dobrý si test na někom nanečisto vyzkoušet, abyste ověřili, že je splnitelný - dal jsem ho kolegovi tady v Praze, seniornímu Javistovi (stihnul to za předpokládanou hodinu, na plný počet bodů).

Výše, v sekci generalizací, jsem psal o nižší úrovni kandidátů. Pro představu, dva nejlepší výsledky z testu byly 17,5 a 16,5 bodu z 24. Průměr byl kolem 10-12 bodů. A výjimečný nebyly ani výsledky se 4 body.

Kandidáti, které jsem viděl na místě, byli profiltrovaný dvěma způsoby - jednak testem a dále už prošli i HR pohovory. Interview byly naplánovány na celý týden, většinou vycházely tak tři na jeden den. Docela záběr.

Agenda pohovorů byla dosti podobná tomu, jak už jsem popisoval v článku Jak dělám Java pohovor. Od té doby jsem to zase o něco vylepšil (o tom někdy příště), ale pro filipínské prostředí jsem to upravil do podoby:

1. Představení pohovorujících.
2. Představení naší firmy.
3. Představení kandidáta.
4. Technické otázky.
5. Java workshop.

První tři body, předpokládám, není potřeba vysvětlovat. Co se ale skrývá pod termíny technické otázky a Java workshop?

Technické otázky

Technické otázky začínám nabídkou: "Můžete mi popsat Váš poslední, nebo poslední úspěšný projekt, z technického pohledu?" Je to pozvolný přechod od CV k technickým záležitostem. Co mě zajímá, je:

• Architektura daného projektu - chci ji namalovat (ideálně na tabuli, nebo aspoň na papír) a popsat. Je zde široké pole pro diskuzi - nad komponentami (technologie), vztahy mezi nimi (protokoly), plusy a mínusy, performance, v jakém kontextu je aplikace vyvíjena atd.
• Jak vypadal tým a jakým způsobem byl řízen. Sem spadají role v týmu, metodologie a procesy, komunikace v rámci týmu a mimo tým, daily work atd.
• Jak vypadalo řízení projektu z technického pohledu? Čili opět metodiky a procesy, ale i správa issues a nástroje na podporu (a automatizaci) projektu, release management atd., atd.

Hlavním cílem "projektové" otázky je zjistit, jak je kandidát zakotven v softwarovém inženýrství. Pokud není a říká o sobě, že je senior, má u mne docela vážný problém.

Pak už následují čistě technické otázky, které se odvíjejí od kandidátova CV a praxe. Zpravidla se ptám na věci, které by měl kandidát dobře znát. A naopak - neptám se ho na věci, s nimiž nemá zkušenost, byť je bude v budoucí práci u nás potřebovat. Nejčastěji se otázky točí kolem nějaké komponety, či technologie z oblasti "enterprise" Javy, takže buď něco z Java EE, nebo ze Springu.

Někdy se zeptám na věci, které jsou sice minoritně důležité, ale zaujmou mě (catch my eye) - třeba SoapUI, nebo Selenium. Třeba o tom něco ví. Nebo si to tam dali jen tak pro zajímavost. Tak, nebo tak, zajímá mne, jak se k tomu v odpovědi postaví.

Ať už je otázka jakákoliv, začínám zvolna. "Jaký je hlavní princip za technologií XY? Jak to funguje?" A pak jdeme postupně hloubš a hloubš. Na určité úrovni se pak kandidátovy (nebo moje :-) znalosti zastaví. Což je moje ryska na stupnici kandidátovy seniority. A další otázka podobným způsobem. Většinou jsou takové technologické otázky 2 až 3 a strávíme tím zhruba půl hodiny.

Java workshop

Ayala Avenue, Makati

Ohledně Java workshopu se nebudu moc rozepisovat a odkážu vás na budoucí článek. Obecně jde o to, že s kandidátem strávím cca půl až hodinu programováním a diskuzí nad kódem v IDE.

Zadáním je UML diagram "určitého abstraktního řešení" (omlouvám se, zatím nebudu konkrétní). Pokud ho kandidát zná, může ho zkusit vysvětlit. Pokud nezná, vysvětlím ho já. Pak otevřu notebook a to co je na diagramu může kandidát vidět jako kostru projektu v IDE.

Kandidát by měl řešení naimplementovat a napsat k němu unit testy. To, jak kandidát píše kód a jak dobře ovládá IDE je podstatné a zajímavé. Ale daleko důležitější je, jak se mnou komunikuje. Zadání je totiž dosti vágní a tak záleží na kandidátovi, na co se zeptá, s jakým přijden nápadem apod. Jak reaguje na otázky, které průběžně pokládám.

Celá seance by měla ideálně připomínat párové programování, nebo code review. Mým cílem je, aby kandidát nebyl ve stresu a v nejlepším případě si to i užil. Ne vždy se to podaří. Ale to je v pořádku, protože to co hledám, není jen technické ohodnocení.

Minimálně stejně důležitý je i cultural fit. Takže pokud někdo nepíše testy, neumí diskutavat nad designem a neumí zdůvodnit své rozhodnutí/implentaci, vidím to jako závažný problém. Stejně tak, pokud někdo dělá pět let v nějaké IDE a neumí ho adekvátně ovládat (fakt se najdou senioři, kteří neznají Ctrl+Space).

(Více o Java workshopu napíšu ve slibovaném článku, kde bych se chtěl podívat na to, proč si myslím, že je to dobrý způsob, jak si otestovat kandidáta.)

Po interview

Tak a máme po interview. Možná měl kandidát ještě nějaké otázky, pár zdvořilostí na závěr a hotovo! Ne tak docela. Je potřeba si kandidáta ohodnotit, možná udělat předběžné rozhodnutí. Pokud je víc intreview v řadě, je dobré si kandidátovo hodnocení nějak "znormalizovat" a zadasadit do relativního kontextu k ostatním - pokud nabírám (i průběžně) více lidí na stejnou pozici, stačí mi, že kandidát překročí určitou laťku. Pokud ale obsazuji jednu pozici z více kandidátů, je dobré mít možnost nějak si je porovnat.

Já jsem si na Filipínách udělal jednoduchou tabulku:

To je, čistě za mne, hodnocení technického pohovoru. Což je, samozřejmě, pouze část přijímacího a rozhodovacího procesu. Je to podklad, který společně s mými poznámkami na CV používám pro diskuzi a argumenaci s ostatním členy pohovorujícího týmu.

A jak to dopadlo?

Možná čekáte, že vám teď řeknu, kolik kanditátů jsme přijali, jaký je jejich profil atd. Neřeknu. Jednak, tenhle článek není o tom, jak se staví core team, ale jak vypadá interview v mém pojetí. A pak, najmout lidi do týmu není otázka jednoho týdne pohovorů - je tam spousta dalších aspektů a i časově je to daleko náročnější.

Nicméně, pokud by vás takové téma zajímalo, můžu vás navndadit na jeden z budoucích článků, který bude o tom, jak se (v Česku) staví tým vývojářů. Zůstaňte na příjmu!

Jeepney, tradiční veřejná doprava na Filipínách

Související články

• Jak dělám Java pohovor
• Jak dělají Java pohovor jinde
• Měl by mít vývojář portfolio?
• Kontrakt místo pohovoru, je to reálné?