V Profinitu není náborový proces výlučnou doménou HR oddělení, klíčovou roli v něm sehrávají naši softwaroví inženýři a inženýrky. Je to potřeba, protože cílem většiny našich pohovorů není nalézt člověka, který co nejlépe zapadá do předem definované škatulky (=pozice), nýbrž zhodnotit, jak by se daný kandidát mohl v Profinitu uplatnit a na jaké typy projektů by se hodil. Pohovor se tedy intenzivně zaměřuje na znalosti i praktické zkušenosti a jde hodně do šířky i do hloubky. A přestože nás častokrát kandidáti příjemně překvapí, dnešní příspěvek bude věnován odpovědím z opačného spektra.
Níže jsme pro vás připravili TOP 5 nejčastějších odpovědí, které nás spolehlivě zarmoutí.
To si „vygooglím“
Nikdo z nás určitě nerozporuje, že na Internetu se dá najít (téměř) vše. Nicméně pokud většinu pracovní doby trávíme hledáním bez základního ponětí, co vlastně hledáme, není to dobře. Navíc „vygooglit“ si úplně všechno občas vede na populární techniku „copy&paste“, aniž bychom rozuměli, co vlastně děláme. Čili „vygooglit“ ano, ale nelze takto odpovídat ve většině případů.
Nevím, jak to funguje, to za mě řeší framework
Nevynalézat kolo a místo toho využívat knihovny a frameworky je rozhodně chvályhodné (mimochodem víte jaký je rozdíl mezi knihovnou a frameworkem?), ale stejně jako u ohně platí, že framework je „dobrý sluha, ale zlý pán“. Krásný příklad je použití ORM, kde si teoreticky vývojář vůbec nemusí relačními databázemi „špinit ruce“, ale pak zpravidla musí řešit problémy s výkonností (a to už se bez znalosti SQL a obecně principů relačních databází obvykle neobejde).
Jo, to jsme ve škole měli. Ale teď už jsme to semestr nepoužili
Netvrdíme, že je nutné si ze školy vše pamatovat. Nicméně podobné odpovědi jsou typicky spojeny například s problematikou synchronizace vláken, grafy nebo SQL. Ano, možná to nyní nepotřebujete, ale jedná se o základy, které se neučí pro nic za nic. Navíc přijít na pohovor s tím, že si nepamatujete učivo staré 3-4 měsíce, není nejlepší nápad.
Na to nebyl čas
Ať už se jedná o psaní dokumentace, verzování kódu, automatizaci testů či, v horším případě, o testování samotné, srdce softwarového inženýra zapláče, když slyší, že na to nebyl na projektu čas. Samozřejmě existují výjimky – fakt, že se na projektu nepíše dokumentace, neverzuje se kód nebo že neexistují automatické testy, nemusí nutně znamenat špatný projekt, ale v takovém případě musí jít o vědomé rozhodnutí, že se daná činnost v daném případě nevyplatí nebo nedává smysl a nikoliv o důsledek nedostatku času. Nedostatek času se totiž ignorováním daných činností ještě prohlubuje (například nedostatečné testování => více chyb z produkce => více času na opravu chyb => méně času na testování a cyklus se uzavře).
Specifikace? To už dneska v rámci agilního vývoje není potřeba
Kéž by to byla pravda. V rámci čistého Scrum dostává tým zadán problém a ten má za úkol vyřešit. Nicméně začíná pomalu platit obecná shoda, že alespoň nějaký základní popis spojený s minimální analýzou je fajn (například rozmyšlení vhodné architektury, atd.). Můžeme se bavit o terminologii a zda se jedná o specifikaci nebo user-story, ideu, atd. Nikdy by ale agilní vývoj neměl být zástěrkou pro „nevíme, co chceme, budeme vyvíjet agilně“. To je pak absolutní anti-teze.
Autoři:
Delivery Manager
Michal Petřík