2. Praktický test prakticky – Takto už vůbec ne

interview-icon

V minulém článku jsem sepsal pár věcí, které firmy dělají na technických pohovorech vyloženě špatně a určitě by se všichni měli při hledání kandidáta těmto chybám vyhnout. Ale ještě než se dostanu k tomu, jak by to mělo vypat, rozhodl jsem se napsat pokračování v podobném duchu.

Posledních pár měsíců jsem strávil tím, že jsem se aktivně snažil zefektivnit pohovory u svých klientů se zaměřením hlavně na technické kolo a při pozorování jsem si uvědomil, že jsem vynechal dvě velice důležité oblasti, na které neustále narážím a určitě stojí za zmínku a zamyšlení.

„Developer musí držet tempo“

Už se vám stalo na pohovoru, že jste očekávali otázky pro otestování vašich zkušeností, ale místo toho se zdálo, že na druhé straně oponent otevřel change log s nejnovějšími featurami jazyka a ptal se pouze a jen na ně?

V tomto případě si je třeba opět položit otázku „Co nám toto může říct o kvalitě developera?“

Znám takové, kteří jsou nadšení z každé novinky a dychtivě se ji snaží zařadit do své práce a v celém vývojovém flow aplikace mají jistě své místo. Takoví ale málokdy mají čas poznat věci do hloubky a v případě vyhrocených edge casů nejsou schopni adekvátně reagovat. S využitím všech novinek dokážou svou práci odvést rychle a také funkčně, nicméně úpravy a deep debugging se poté stává nesplnitelný úkol i pro zkušené developery, protože v magicky psaných kompilovaných knihovách, které měly sloužit pro ušetření času, se nedá vyznat.

Pokud tedy hledáte zkušeného developera, tomuto přístupu se vyhněte. Protože takový zná věci do hloubky a používá je, až jsou ověřené a hlavně dává smysl je použít. Pro hraní a objevování slouží pískoviště a ne produkční prostředí. ;-).

„Zkušenost === rychlejší vývoj“

Před nějakým časem jsem vyvíjel docela komplikovanou komponentu, kde příprava, samotný vývoj a hlavně promyšlení veškerých možných rizik, které můžou nastat, zabrali cca měsíc a půl.

Podobná problematika se řešila už milionkrát a vygooglit šlo tisíce řešení. Žádné z těch co jsem našel, ale nebylo natolik škálovatelné a ohebné, aby se dalo připojit k již hotové architektuře, které nesla značný technický dluh a byla velice specifická.

Když jsem si nedávno projížděl process přijímacího pohovoru firmy, kam si mě pozvali, našel jsem v něm zadání pro kandidáty, které bylo z hodně velké části dost podobné tomu, co jsem řešil v rámci zmíněné komponenty. Hned po rozsahu zadání mi vyrazilo i dech to, že kandidát na řešení má pouze 2 hodiny.

Ano. Zmínil jsem, že existuje nezměrné množství dohledatelných a vyhotovených řešení, ale pokud bych byl v pozici developera, chtěl bych asi ukázat víc než jen to, že umím nainstalovat balíček a spustit ho.

Zkusil jsem tedy zadání vyhotovit a i když jsem nesl v hlavě velice čerstvé know how a cca 50% kódu jsem zrecykloval z mé hotové komponenty, nakonec jsem splnil ani ne půlku. A to jsem byl s problematikou seznámen. … Když by testovaný developer nikdy nepřišel do kontaktu s podobným zadáním, za dvě hodiny by ani nepochopil, co se po něm chce.

S tímto přístupem se ale setkávám velice často. Moc konkrétní zadání a nesmyslné nároky na časové vyhotovení, zbytečně odrazují kandidáty a nebo jsou přímo zamítnuti.

Ano chápu. Firma chce mít jistotu, že si vybrala správně. Ale absolutní jistotu může získat jen a pouze, když developera na delší čas zařadí do práce a pozoruje, zda jeho výstupy odpovídají požadavům. A od toho je zkušební doba, případně její ekvivalent.