1. Praktický test prakticky – Takhle ne

interview-icon

Pohovory jsou fajn a chodím na ně rád. I když zrovna nic aktivně nehledám a firmy si mě pouze pozvou jen „kdyby náhodou“, tak nemám nic proti oboustrannému rozšíření obzorů, jak to může fungovat jinde.

Mám rád, když jsou v uvolněném stylu a víc než pohovor připomínají malý dev meet up, kde se obě strany baví o tom co dělají, jak řeší různé výzvy a jak se můžou navzájem posunout dál. Pak většinou příjde na řadu praktická část a tu už tak rád nemám.

Čím to je? Programuji rád a výzvy v podobě zadání, při kterém jsem nucen rozšířit své know how, mám ještě raději.

Odpověď je docela jednoduchá, ale její pochopení a zároveň správné uchycení celé problematiky, už tak jednoduché není.

Je to tím, že se firmy nezamýšlí, co jim vlastně tato část přijímacího řízení má o dotyčném říct. … Výsledkem bývá zadání, které může kdejaký začátečník zvládnout na 100% a „prodat“ se na seniorní pozici nebo že člověk, který by byl díky dlouholetým zkušenostem nejspíše přínosem, neprojde a firma o tuto příležitost příjde.

V prvním případě se nekompetentní člověk dostane na pozici, kde se stane přítěží, protože vyžaduje neustálou pozornost jiných členů týmu a tím může narušit jeho produktivitu jako celku. V tom druhém se pro kandidáta nic moc závažného neděje. Zkušených seniorů je jako šafránu a nabídek pro jejich uplatnění je nespočetněkrát více. V obou tím ale trpí firma a přímo i nepřímo ztrácí prostředky. A přitom by se stačilo jenom zamyslet, co vlastně od kandidáta požadujeme a proč to tak chceme.

Nejčastější omyly

Pohled na pohovory mám z obou stran. Občas vedu pohovory na nové developery k sobě do týmu a vím, že s nimi budu denně v kontaktu. A poměrně často si mě pak firmy zvou jako nezávislého oponenta při jejich pohovorech. Ale jak jsem zmiňoval, tak mnohem častěji chodím na pohovory, abych si sedl na opačnou stranu stolu, jakožto kandidát.

„Jde nám pouze o logicky uvažující jedince“

Myšlenka je to hezká. Určitě je nadmíru důležité, aby programátor uvažoval logicky. Setkal jsem se a hlavně jsem musel pracovat také s takovými, kteří tuto vlastnost postrádali a proto si to uvědomuji ještě víc.

Na tom tedy nic špatného není. Špatné je ale to, že je to jediné, co firmu zajímá. Takže na pohovoru mají 2 zadání pro řazení polí, časovou náročnost algoritmu a … Mno a nic víc.

Zadání, které se většinou řeší na tabuli formou pseudokódu, přičemž se nahlas diskutuje o myšlenkových pochodech a proč k úkolu přistupujete právě takto. Žádná velká věda a skvěle tímto odfiltrujete lidi, kteří nedokáží ve stresu a pod tlakem vymyslet nejoptimálnější řešení problému, pokud vůbec nějaké najdou. Požadavkem o definování náročnosti poté zjistíte, kdo dával na vysoké pozor a ještě si to do dnes pamatuje. Protože v praxy víte, že cyklus v cyklu trvá déle, tak nazvání problematiky „kvadratická náročnost“ je jen zbytečná a nic neříkající formalita.

Myšlenka je to dobrá a určitě je třeba obdobné věci testovat. Ale správnou formou a určitě byste na tom neměli zakládat celý pohovor. Navíc ne každá firma má dostatečně velké jméno, aby tam kandidát chtěl strávit víc než jednu hodinu, takže než testovat jenom toto, raději netestovat vůbec a vypozorovat schopnost logického přemýšlení jinak.

„Zkušený člověk zná všechny chytáky jazyka“

Když programujete v nějakém jazyku dost dlouho, tak byste logicky měli znát všechny jeho neduhy. Toto je způsob jakým velice často uvažují programátoři, když připravují testy pro své nové potenciální kolegy. Pak kandidát dostane kód 20 řádků a má říct, jaký je jeho výstup. Například předávání pointerů v f-ci nebo nějaké chování datových typů.

Jestli to má programátor vědět je asi diskutabilní. V praxy by to vypadalo tak, že když se program nechová jak má, tak debugováním zjistím, že je to tento konkrétní „chyták“,zadám to do googlu a za pár minut pokačuji dál v práci. Většinou poté taky tuto informaci vypustím, protože na ni nejspíše dalších pár let nenarazím.

Skutečně se mi stalo, že jsem na pohovoru nevěděl o chytáku v jazyce, ve kterém dělám přes 10 let a nikdy jsem na něj nenarazil. Poté, co jsem to zmínil, mi oponent řekl, že toto oni řeší každý den. Předpokládám, že to bylo tím, že jsem nestandardní chování předpokládal a tudíž jsem problém vždy automaticky řešit alternativní, ale také správnou, cestou.

Vědět na co si dávat pozor při vývoji je vždy výhoda, ale je potřeba rozlišovat, zda je to něco na čem zakládat celý pohovor. Pro mě by bylo například mnohem zajímavější, kandidátovi ukázat kód a očekávaný výsledek a ať klidně s dopomocí strejdy Googla vysvětlí, proč se to chová nestandardně.

„Když kandidát vyřeší naše zadání, umí automaticky vše“

Stává se, že se dostanu na pohovor pro pozici, která by jakoby vypadla z mé vizitky. Při osobním setkání probereme maximálně vizi a vzájemná očekávání podmínek a tak čekám, že zbytek se dozví při praktickém testu. Ten se mi dostane do ruky a připomíná spíš zadání pololetního testu prvního ročníku programování na střední škole.

Když hledáte juniora, je to asi taky cesta. Pro přijímací řízení na seniorní pozici je to ale absolutně nedostačující.

Samozřejmě každé zadání se dá napsat „korektně“ a vždy se zeptám, zda očekávají takové řešení. Kdyby ale takové čekali, tak zadání vypadá jinak. Ba naopak když vše rozepíšete tak jak se má, můžete získat mínusové body za „overengeneering“.

Tím se opět dostáváme k situaci, kdy se nekvalifikovaný junior dostane na pozici, kde nemá co dělat a i kdyby se před tím kvalifikovaný senior na stejnou pozici dostal, tak musí se zmíněným juniorem pracovat a dohlížet na něj.

Závěr

Je to smutné, ale setkal jsem se se s mnohem více podobně nic neříkajícími testy. Bylo by ale zbytečné je zde vypisovat a proto jsem vybral ty nejvíce diskutabilní. Vždy se ptám, proč to testují zrovna takto a pokaždé dostanu docela rozumnou odpověď, protože úplně bez důvodu nikdo nic nikdy nedělá. Ale je důležité se zamyslet, zda konkrétní věc opravdu říká o developerovi, zda je nebo není dobrý programátor a jestli by nebylo vhodnější zvolit jinou cestu.

V ideální světě, kde by všichni říkali a psali objektivní pravdu, by se stačilo podívat na vzdělání, zkušenosti a praxy v životopise a ze souhrnu už byste dostatečně věděli, jak na tom dotyčný je.

Příště zkusím popsat, jak k problematice praktického pohovoru přistupuji já a jak by to aspoň podle mě mělo vypadat.

Pokračování: 2. Praktický test prakticky – Takto už vůbec ne