Během posledních tří let jsem se v našem teamu vypracoval na jednoho z hlavních náborčích. Za tu dobu jsem se účastnil okolo stovky příjímacích pohovorů. Feedback, který jsem dostal od úspěšných kandidátů mi dodal odvahy napsat tento článek.

Prvně je třeba říci, že provést přijímací pohovor tak, aby byl co nejvíce objektivní je nesmírně těžká věc. Na přijímací pohovor jsem se musel vždy připravit. Přípravu na přijímací pohovor vidím dle svých zkušeností ve třech bodech:

• Seznámení se kandidátem. Především výpis klíčových či zajímavých údajů z životopisu kandidáta. Za povšimnutí rozhodně stojí web aplikace, na kterých kandidát v minulosti pracoval.
• Seznámení se s rolí, na kterou bude úspěšný kandidát přijat. V tomto případě je vhodné naplánovat schůzku s vedoucím, který bude kandidáta přijímat (pokud to zní zvláštně, tak čtěte dále). Důležité je mít jasno ve vstupních očekáváních (s čím by měl kandidát přijít do firmy, s jakými znalostmi, zkušenostmi, vzděláním apod.), s náplní práce úspěšného kandidáta a s kariérním růstem, který je s danou pozicí spojen.
• Strategie otázek při pohovoru.

Příjímací pohovory ve firmě Microsoft

Pokud byste měli zájem pracovat ve firmě Microsoft, tak zde je šablona přijímacího pohovoru, kterou budete muset projít. Vlastní příjímací pohovor se skládá ze tří, popřípadě čtyř samostatných pohovorů. U každého pohovoru jsou za firmu Microsoft dva přísedící. Celého procesu se za firmu Microsoft účastní šest, popřípadě osm různých lidí. Tito lidé jsou vybrání tak, aby pokryli různé role ve firmě.

První pohovor je zaměřen na technické znalosti (hard skills) a základní komunikační vlastnosti kandidáta (soft skills). Právě těchto pohovorů jsem se účastnil. Pokud je kandidát ze zahraničí, tak jsou technické pohovory dva, telefonický a další poté, co je kandidát přizván k osobnímu pohovoru. Následuje pohovor ze zástupci personálního oddělení. Tito lidé se především zaměřují na komunikační schopnosti klienta. Výsledkem těchto dvou pohovorů je doporučení pro vedoucího, který je odpovědný za danou otevřenou pozici. Pokud personální oddělení a účastníci technického pohovoru doporučí daného kandidáta, je kandidát pozván k pohovoru, kterého se účastní samotný vedoucí a jím zvolený přísedící.  Na základě tohoto pohovoru je kandidát přijat či poslán na další doplňující pohovor, který obvykle provádí osoba na úrovni řízení vedoucího. Každý takovýto pohovor trvá zhruba hodinu až hodinu a půl.

Ze strany firmy Microsoft se můžete spolehnout na naprostou korektnost vlastního přijímacího řízení. Existují otázky, na které se vás nikdo nikdy nezeptá. Otázky typu kolik je vám let, odkud jste, zda máte rodinu a podobně jsou naprostým tabu. Na školení, které jsem kdysi absolvoval, nám dokonce říkali, že i tak nevinná otázka jako "Jak dlouho jste sem jel?" může být vnímána jako diskriminační a žalovatelná. Radši si s kadidátem při cestě ve výtahu povídám o fotbale nebo o nějakém novém filmu, zkrátka o něčem naprosto neutrálním.

Grif technického pohovoru

Jedna z nejtěžších věcí na příjímacím pohovoru je multitasking. Zde je seznam, který musíte mít jako zkoušející souběžně na zřeteli:

• Dovídám se danou otázkou něco nového o kandidátovi? Každá otázka by měla nějakým způsobem vést k  jednoznačnému závěru pro přijetí či nepřijetí kandidáta. 
• Jaká bude další otázka? Jak budu v pohovoru pokračovat?
• Odpovídá kandidát na otázku? Odpovídá správně?

Na pohovor je obvykle vyhrazen daný čas a vše probíhá poměrně rychle. To, že musíte při pohovoru poslouchat, co vám kandidát odpovídá, a zároveň si musíte připravovat další smysluplnou otázku, je opravdu velmi náročné.

Nejlepší obranou proti multitaskingu je pohovor ve formě dialogu. V tomto případě se snažíte kandidáta "nastavit" tak, aby vás poučil. Otázka je pak postavena v tomto tónu: "Zajímavé. To jsem nevěděl. Nesetkal jste se tím, jak by se to dalo vyřešit pomocí více vláken?" Kandidát, pokud ví, získá sevěvědomí a odvahu se s vámi pustit do debaty. Pak pokračujete: "A řešil jste někdy přístup více vláken aplikace do databáze?"

Dostat se do atmosféry debaty je ale nesmírně těžké a zdaleka ne vždy se mi to povedlo. Prvním problémem je, že kandidát musí spolupracovat :-). A tedy něco vědět. Druhým problémem je to, že jako zkoušející jste přece jen vnímán jako boss, ten kdo má vždycky pravdu a všechno ví a všechno zná. Postavení kandidáta a zkoušejícího při pohovoru není rovné. Třetím problémem je cvik. Tím, jak rostou vaše zkušenosti z minulých pohovorů, se dle mých zkušeností mění způsob vedení celého pohovoru. Představuji si to takto:

Na počátku cesty je důraz kladen na seznam otázek. Každý si tím musí projít. Mé první pohovory byly především o tom, abych měl zásobu "správných" otázek. Otázky jsem kladl v daném pořadí a jednoduše jsem si dělal fajfky na co mi kandidát odpověděl a na co ne. To bylo mé stádium "Vyptávání" - jinak řečeno, otázky jsou nadevše, otázky jsou Bůh. Postupně jsem došel k tomu, že některé otázky jsou těžší než jiné a nemá smysl je klást tehdy, pokud kandidát neznal odpověď na nějakou jednodušší otázku. Tento filtr "težší" a "lehčí" je zcela určitě subjektivní, ale s tím, jak zkoušíte více a více kandidátů získáte přehled o tom, na co jsou schopni kandidáti odpovědět. "Težší" a "lehčí" se tedy časem stává spíše "Méně pravděpodobné, že kandidát bude znát odpovět" a "Vice pravděpodobné, že kandidát bude znát odpověť".

S rostoucími zkušenostmi se posouváte z fáze "Vyptávání" do fáze "Naslouchání". Čím více jste schopni naslouchat, tím více je pohovor interaktivní. Otázky zde nehrají až tak klíčovou roli. Důležité je spíše schopnost poslouchat a přímo reagovat na to, co kadidát říká. Otázky přestávají mít absolutní formu typu: "Co je to deadlock?". Místo toho jsou otázky více neurčité: "Proč si to myslíte? Co se stane v případě, když budete mít vlákna dvě?"

Dalším problémem z pohledu zkoušejícího je "syndrom svalové horečky". Pokud jste někdy chodili do posilovny tak víte, jaké to je, když si po pravidelném cvičení dáte i sebemenší, několikadenní přestávku. Pak musíte počítat s tím, že vás při prvním následném tréningu bude všechno bolet. S pohory je to dle mých zkušeností podobné. V jednu dobu jsme měli otevřeno pět pozic a to v praxi znamenalo tak třicet pohovorů. Dva denně, několik týdnů za sebou. Po určité době je to rutina. Pak ale nastane hladové obdoví. Přeci jen, nové spolupracovníky nepřijímáte zase až tak často. Pak příjde nová vlna. Během období půstu však odezní automatika, grif schopnosti naslouchání se oslabí. Naštěstí to není tak, že byste úplně ztratítili vaše předchozí zkušenosti. Spíše je to něco podobného, jako když přestanete na delší dobu řídit auto. Nezapomenete řídit, ale na určitou dobu ztratíte jistotu, cit pro situaci.

Struktura pohovoru

Možná čekáte na to, jaké jsou mé oblíbené otázky a jaká je struktura mého pohovoru. Díky pohovorům, kterých jsem se zůčastnil mám sice jisté seběvědomí, ale rozhodně se necítím na to, abych o sobě tvrdil, že jsem v tomto borec. Naopak, výše uvedené myšlenky měly být spíše o tom, že udělat dobrý pohovor, a to především znamená rozpoznat talent, potenciál, je nesmírně těžké. Zde je tedy několik mých oblíbených témat.

Náš team je složen z několika pracovních skupin, které vyžadují různou kvalifikaci. Na jedné škále se jedná o stážisty. Ti u nás obvykle pracují jeden rok. Firma Microsoft je sponzorem programu, jehož snahou je umožnit studentům IT získat praxi v oboru. Další skupinou jsou kolegové, kteří maji na starosti automatizaci testování produktu Office. Od těchto lidí se očekává aspoň dvouletá praxe. Třetí skupinou jsou kolegové, kteří buďto vyvíjí interní nástroje pro testování a lokalizaci, a nebo vyvíjí Office Add-iny specifické pro daný trh. Od těchto lidí se očekává aspoň pět let praxe, znalost C++ je v tomto případě častou podmínkou (tito lidé obvykle pracují s kódem Office).

V mém repertoáru otázek jsou zásadně otázky koncepční. Otázky typu "Vyjmenujte mi třídy, které můžete použít k nastavení formátu pro serializaci" či "Namalujte mi UML diagram návrhového vzoru Strategy" považuji za nic neříkající a nefér. A to hlavně proto, že tyto otázky nesimulují problémy, se kterými se vývojář v praxi zabývá. Na obě otázky existuje snadná odpověď - první odpověď je MSDN\Reflector a druhá odpověď je kniha GoF. Smysluplnější otázka by pak mohla být: "Kde můžu najít seznam tříd, které mohou použít k nastavení formátu pro serializaci?" Sami cítíte, že takto položená otázka nemá žádný smysl, protože nic neřekne o kvalitě kandidáta. Z tohoto důvodu považuji "encyklopediční" otázky za nic neříkající.

Jaké otázky tedy považuji za smysluplné? Zde je příklad, jak by mohl vypadat můj pohovor. "Můžete mi řict, jaký je rozdíl mezi statickou virtuální metodou?" Pokud nemá kandidát problém s odpovědí, pokračuji. "Dobrá, a může být statická metoda zároveň metodou virtuální?" Pokud nemá kandidát problém s odpovědí, pokračuji. "Proč ne, můžete mi to vysvětlit?" Tím se dostanu až do bodu, kdy kadidát ví, jak fungují virtuální metody. Pak mohu pokračovat dále, podle kontextu: "Jaká virtuální funkce v hierarchii tříd se zavolá, pokud provedu volání této virtualní funkce z destruktoru v jazyce C++?"

Jiný příklad. "Můžete mi říci, k čemu slouží v .NET idiom Dispose()?" Pokud kandidát ví, tak pokračuji. "Co je to tedy garbage collector?" Pokud kandidát ví, tak pokračuji: "A víte, jak funguje garbage collector v .NET?" Pokud kandidát ví, pokračuji "Může být finalizator volán vícekrát?", "Ano, v jakém případě?" Error handling je další oblast, ve které lze nalézt celou řadu otázek, od jednodušších až po záludnější.

Další mé oblíbené otázky jsou otázky srovnávací: "Jaké rozdíly vidíte mezi programovacími jazyky Java a C#?" (kontext: mnoho uchazečů uvádí znalost C# a Java), "Znáte nové funkce jazyka C# (verze 2.0). O kterých jste slyšel?", "Jaké rozdíly vidíte mezi šablonou v C++ a generic v CLR?", "V jaké situaci byste použil návrhový vzor Strategy a v jaké situaci byste použil Decorator?", "HTTP je bezstavový protokol. Řekněte mi všechny způsoby, které znáte, pro uchování stavu mezi klientem a serverem." (kontext: uchazeč deklaruje zkušenost s ASP\ASP.NET).  

Další skupinou otázek jsou otázky praktické. "Potřebujete krokovat kód v určité iteraci cyklu. Jakým způsobem můžete zastavit program tak, aby došlo k "záseku" přesně v požadované iteraci?", "Jakým způsobem byste ladil vyjímku Access Denied?" Oblíbené otázky jsou otázky s otevřeným koncem, otázky, na které v podstatě neexistuje  jednoznačná odpověď. Nejlepší otázky tohoto typu jsou otázky kontroverzní. Ano všichni je známe: "Je lepší uložit data do databáze jako binární BLOB nebo jako referenci na zkutečná data?", "Co si myslite o použítí bloku catch {}. Použil byste ho někdy?"

Nakonec je to kód. Uchazeč je postaven před určitý rozumně složitý problém. Například setřídit pole, rozpoznat palidrom apod. Nebo je uchazeči předložena ukázka existujícího kódu s cílem najít v kódu chybu. Například "Co je špatně na tomto kódu?"