Jak hodnotit kandidáty na vývojáře bez CTO

Martin investoval tři měsíce a 400 000 Kč do vývojáře, který dodal React aplikaci padající pokaždé, když se přihlásilo víc než 50 uživatelů. Portfolio vypadalo solidně. Pohovor proběhl skvěle. Reference seděly. Jenže nikdo v Martinově týmu nedokázal rozlišit kvalitně navrženou aplikaci od chaotického kódu slepeného provizorními záplatami. Když aplikace zkolabovala při první marketingové kampani, musel celý projekt zahodit, najít někoho nového a začít od nuly.

Tento příběh se opakuje ve stovkách rostoucích firem každý rok. Potřebujete hodnotit kandidáty na vývojáře, ale nemáte CTO ani seniorního inženýra, který by oddělil skutečný talent od sebevědomých řečníků. Špatný technický nábor vás může stát až pětinásobek ročního platu zaměstnance, když započítáte ztracený čas na vývoji, zmeškané termíny a přestavbu, která nevyhnutelně následuje.

Dobrá zpráva: nepotřebujete diplom z informatiky, abyste vývojáře dokázali efektivně prověřit. Stačí mít systém, správné otázky a vědět, na čem skutečně záleží. Pokud chcete celý proces přeskočit, služba IT talent screeningu od Bitvea zajistí kompletní technické hodnocení za vás, od code review po posouzení architektury. Pokud si ale chcete vybudovat vlastní proces, přinášíme přesný návod.

Proč netechničtí zakladatelé při výběru vývojářů naráží

Hlavním problémem je informační nerovnováha. Vývojáři vědí o svých dovednostech mnohem víc, než dokážete ověřit. Kandidát napíše do životopisu „5 let Python, microservices, AWS", a pokud se nedokážete dostat pod povrch těchto klíčových slov, berete ho za slovo.

Z toho plynou tři konkrétní rizika.

Sebevědomí vs. schopnosti. Výřeční kandidáti, kteří skvěle zvládají pohovory, ale špatně programují. Terminologii znají. Dokážou mluvit o návrhu systémů na vysoké úrovni. Jakmile si ale sednou k práci, výsledný kód je křehký, netestovaný a obtížně udržovatelný.

Past přeinženýrování. Enterprise vývojáři, kteří automaticky vše překomplikují. Navrhují Kubernetes clustery a microservice architektury pro aplikaci sloužící 200 uživatelům. Jeden komentátor na Hacker News popsal vývojáře, který prosadil „škálovatelné mikroslužby" a přidal šest měsíců k projektu, který měl být hotový za osm týdnů.

Iluze portfolia. GitHub profily plné tutoriálových projektů a nedokončených vedlejších projektů, které nikdy nesloužily reálným uživatelům. Portfolio bez živých produkčních aplikací o skutečných schopnostech kandidáta vypovídá jen velmi málo.

Netechničtí zakladatelé to často kompenzují spoléháním na intuici. Tak skončí s vývojářem, který skvěle působí u pohovoru, ale nedokáže dodat funkční software.

Pětikrokový framework pro hodnocení kandidátů na vývojáře

Nemusíte rozumět kódu, abyste vývojáře hodnotili systematicky. Potřebujete strukturovaný proces, který vynese na povrch informace, na kterých vám skutečně záleží.

Krok 1: definujte roli ještě před zveřejněním nabídky

Většina náborových chyb začíná ještě před prvním pohovorem. Pokud nedokážete popsat, co potřebujete vytvořit, vývojáři si mezery doplní vlastními předpoklady -- a ty zřídkakdy odpovídají vašim obchodním cílům.

Než zveřejníte nabídku práce, sepište jednostránkový dokument, který odpoví na tyto otázky:

• Jaký konkrétní problém má software řešit?
• Jak vypadá minimální funkční verze produktu?
• S jakými nástroji a systémy se musí propojit?
• Jde o vývoj na zelené louce, nebo o práci s existujícím kódem?
• Potřebujete generalistu, nebo specialistu?

Pokud stavíte softwarovou aplikaci na míru od nuly, potřebujete někoho se zkušenostmi s architekturou. Pokud rozšiřujete existující systém, hledáte člověka, který se orientuje ve čtení a úpravě cizího kódu. Jde o dvě zásadně odlišné dovednosti.

Krok 2: prověřte portfolia a GitHub profily

Z veřejně dostupné práce vývojáře se dozvíte překvapivě hodně, i když nerozumíte jedinému řádku kódu. Na co se zaměřit:

Živé projekty. Zeptejte se každého kandidáta: „Můžete mi ukázat něco, co jste vytvořili a co právě teď používají skuteční uživatelé?" Pokud nedokáže ukázat jedinou živou aplikaci, je to varovný signál. Je zarážející, kolik firem se na to nikdy nezeptá.

Pravidelná aktivita. Na GitHubu se podívejte na graf příspěvků (zelené čtverečky na profilu). Pravidelná aktivita v průběhu měsíců nebo let svědčí o skutečném zájmu. Náhlý nárůst dva týdny před podáním přihlášky spíše znamená účelové vylepšování profilu.

Organizace kódu. I bez čtení kódu poznáte, jestli je někdo pořádný. Mají repozitáře soubory README? Jsou projekty pojmenovány srozumitelně? Existuje logická adresářová struktura? Nepořádek v organizaci projektů často signalizuje nepořádek v kódu.

Zapojení do komunity. Přispívají do open-source projektů? Odpovídají na otázky na Stack Overflow? Píší technické články? Aktivní účast v komunitě často koreluje s hlubšími znalostmi.

Krok 3: pokládejte otázky odhalující myšlení, ne jen znalosti

Nemůžete vývojáře zkoušet z algoritmů. Ale můžete klást otázky, které odhalí, jak přemýšlejí, komunikují a rozhodují se. Následující otázky fungují bez ohledu na vaše technické zázemí.

„Popište mi, jak byste vytvořili [funkci vašeho produktu]." Sledujte, jestli kandidát pokládá upřesňující otázky, než se pustí do řešení. Silní vývojáři se ptají na omezení, objem uživatelů a okrajové případy. Slabí vývojáři okamžitě začnou jmenovat technologie.

„Řekněte mi o projektu, který se nepovedl, a co jste si z toho odnesli." Upřímní vývojáři mají příběhy o selháních. Pokud někdo tvrdí, že každý projekt dopadl perfektně, buď lže, nebo nepracoval na ničem náročném.

„Vysvětlete [koncept z jejich životopisu], jako bych byl majitel firmy, ne inženýr." Tím přímo testujete komunikační dovednosti. Pokud kandidát nedokáže vlastní odbornost vysvětlit srozumitelně, bude mít potíže spolupracovat s vaším netechnickým týmem.

„Proč jste si na poslední projekt vybrali [technologii X]?" Hledáte schopnost zvažovat kompromisy. Dobré odpovědi zmiňují alternativy a konkrétní důvody pro danou volbu. Špatné odpovědi znějí „protože je to nejlepší" nebo „protože to umím."

Krok 4: použijte praktické úkoly, ne hádankové testy

Tradiční LeetCode úlohy, kde kandidáti obracejí binární stromy nebo optimalizují třídící algoritmy, ztrácejí relevanci. Výzkum z několika náborových platforem ukazuje, že tyto hádanky špatně korelují s reálným pracovním výkonem.

Raději zvolte hodnocení odrážející skutečnou práci:

Placené zkušební projekty. Dejte kandidátovi malý, reálný úkol z vašeho product backlogu. Zaplaťte mu za 8 až 16 hodin práce. Sledováním toho, jak řeší skutečný problém, se dozvíte víc než z jakékoli otázky na pohovoru.

Code review na zkoušku. Připravte kus kódu (případně požádejte konzultanta) a nechte kandidáta udělat code review. Jaké chyby najde? Jaká vylepšení navrhne? V roce 2026 je tato dovednost důležitější než kdy dříve, protože vývojáři stále častěji potřebují validovat kód generovaný AI na drobné chyby, race conditions a bezpečnostní nedostatky.

Diskuse o návrhu systému. Popište obchodní problém a zeptejte se, jak by navrhli řešení. Nemusíte rozumět každému technickému detailu. Ale poznáte, zda pokládají chytré otázky a zvažují praktická omezení jako rozpočet, časový plán a udržovatelnost.

Krok 5: řádně ověřte reference

Většina ověřování referencí nepřinese nic, protože lidé pokládají příliš obecné otázky. Zkuste se raději zeptat takto:

• „Najali byste tohoto člověka znovu na stejnou pozici?"
• „Kolik dohledu potřeboval?"
• „Jak řešil neshody ohledně technických rozhodnutí?"
• „V čem by se mohl zlepšit?"

Zaváhání před odpovědí „ano" na první otázku vám řekne vše podstatné.

Varovné signály, které by měly kandidáta vyřadit

Některé varovné signály rozpoznáte i bez technických znalostí. Každý z nich by vás měl přimět k vážnému zamyšlení.

Žádné zkušenosti s verzováním kódu. Pokud vývojář nepoužívá Git (nebo jiný verzovací systém), chybí mu základní profesionální návyky. Je to jako najímat účetního, který nepoužívá tabulkový procesor.

Žádná praxe s automatickými testy. Vývojáři, kteří nepíší testy, dodávají chyby. Zeptejte se: „Jak si ověříte, že váš kód funguje, když něco změníte?" Pokud odpověď nezahrnuje automatické testování, jděte dál.

Nemohou ukázat živý projekt. Portfolia plná screenshotů a popisů, ale žádná funkční URL. Pokud nic z toho, co vytvořili, stále neběží, zeptejte se proč.

Nulový zájem o váš byznys. Vývojáři, kteří mluví pouze o technologiích a nikdy se nezeptají na vaše uživatele, trh nebo obchodní model. Vaše první vývojáře musí zajímat, co vytvářejí, ne jen jak.

Opakované podceňování termínů. Ptejte se na odhady projektů versus skutečné dodání. Každý vývojář občas podcení termín, ale ti dobří dokážou vysvětlit proč a co si z toho odnesli.

Neochota vysvětlovat rozhodnutí. Pokud kandidáta rozčílí otázka „proč?" nebo vám řekne „to je příliš technické na vysvětlování", je to komunikační problém, se kterým budete žít každý den.

Jak posoudit technické dovednosti bez technických znalostí

I bez CTO dokážete technickou úroveň kandidáta posoudit nepřímými metodami.

Test srozumitelnosti

Požádejte kandidáta, aby vám vysvětlil technický koncept ze svého životopisu. Hodnoťte srozumitelnost, ne správnost (tu stejně neposoudíte). Silný vývojář dokáže složité věci zjednodušit. Slabý se schovává za žargon.

Nejlepší techničtí komunikátoři používají analogie. Pokud někdo dokáže přirovnat indexování databáze k obsahu knihy nebo vysvětlit návrh API na příkladu jídelního lístku v restauraci, rozumí tématu dostatečně hluboko na to, aby ho dokázal předat dál.

Pozorování řešení problémů

Zadejte kandidátovi během pohovoru netechnický problém. Například: „Náš tým zákaznické podpory zpracovává 200 tiketů denně a doba odezvy je příliš pomalá. Jak byste to řešili?" Sledujte strukturované myšlení, otázky na omezení a praktické návrhy řešení.

Posouzení referenční architektury

Požádejte kandidáta, aby nakreslil nebo popsal architekturu něčeho, co vytvořil. Tyto materiály pak předejte technickému poradci na 30minutovou konzultaci. Nepotřebujete k tomu CTO na plný úvazek. Freelance seniorní vývojář nebo služba technického screeningu dokáže materiály kandidáta posoudit a dodat vám odborné hodnocení během několika dní.

Audit ukázky práce

Pokud kandidát v rámci výběrového řízení předloží kód, nechte ho posoudit externím technickým expertem. Už tento jediný krok odhalí většinu nevhodných kandidátů. Dvouhodinové code review od seniorního vývojáře stojí nesrovnatelně méně než šestiměsíční omyl.

Kdy zapojit externího technického odborníka

Přijde chvíle, kdy přestává dávat smysl dělat vše sami. Pokud nabíráte na seniorní pozici, stavíte klíčový produkt nebo děláte svůj první technický nábor, je v sázce příliš mnoho na to, abyste se spoléhali na odhad.

Externí technické hodnocení se vyplatí v těchto situacích:

• Obsazujete seniorní nebo vedoucí pozici. Špatný seniorní nábor neznamená jen promarněný plat. Přináší špatná architektonická rozhodnutí, která vás stojí roky.
• Budujete první vývojářský tým. Vaši první 2 až 3 vývojáři nastavují technický směr pro vše, co přijde. Pokud se netrefíte, čeká vás kompletní přestavba.
• Už jste se spálili. Pokud předchozí nábor nevyšel, opakováním stejného procesu dosáhnete stejných výsledků.
• Tvrzení kandidáta nelze snadno ověřit. Když někdo říká, že „navrhl architekturu systému zpracovávajícího miliony požadavků", potřebujete někoho, kdo to dokáže prověřit.

IT talent screening od Bitvea pokrývá přesně tuto mezeru. Služba zahrnuje strukturované technické pohovory, code review a analýzu kvality kódu, hodnocení architektury, analýzu GitHubu a portfolia a podrobnou zprávu s hodnocením a doporučeními. Od 15 000 Kč za kandidáta s dodáním do 1 až 2 týdnů stojí zlomek toho, co vás stojí špatný nábor.

Berte to jako pojistku. Pokud se chystáte platit vývojáři 80 000 Kč měsíčně nebo více, investice 15 000 Kč do ověření, že skutečně dokáže dělat svou práci, patří k nejrozumnějším rozhodnutím.

Jak vytvořit opakovatelný náborový proces

Jednorázová náborová rozhodnutí jsou vždy riziková. Opakovatelný proces toto riziko snižuje s každým dalším použitím.

Vytvořte hodnoticí kartu

Sestavte jednoduchou hodnoticí matici s těmito kategoriemi:

Ohodnoťte každého kandidáta 1 až 5 v každé kategorii. Vynásobte váhou. Porovnávejte kandidáty podle celkového skóre, ne podle pocitů.

Standardizujte otázky k pohovoru

Pokládejte každému kandidátovi stejné klíčové otázky. Odstraníte tím zkreslení plynoucí z odlišných rozhovorů s různými kandidáty. Otázky specifické pro danou roli můžete přidat, ale základ by měl být vždy stejný.

Dokumentujte vše

Po každém pohovoru si do 30 minut zapište konkrétní postřehy. „Působil chytře" je k ničemu. „Vysvětlil strategii migrace databáze pomocí srozumitelných analogií, položil tři otázky ohledně objemu uživatelů, než navrhl řešení" je užitečné. Tyto záznamy vás navíc chrání, pokud bude náborové rozhodnutí někdy zpochybněno.

Získejte druhý názor

O technickém náboru nikdy nerozhodujte sami. I pokud jste jediný rozhodovatel, přizvěte důvěryhodného poradce, technického konzultanta nebo screeningovou službu, která nabídne nezávislý pohled. Dva úhly pohledu zachytí to, co jeden přehlédne.

Co následuje po náboru

Hodnocení nekončí podpisem smlouvy. Prvních 90 dní ukáže, jestli váš výběrový proces skutečně fungoval.

Nastavte jasné milníky pro první týden, první měsíc a první čtvrtletí. Definujte „úspěch" v konkrétních měřitelných pojmech: dodané funkce, zrevidovaný kód, zdokumentované systémy. Pokud očekávání nenastavíte včas, nepoznáte, jestli nový zaměstnanec plní svou roli, dokud nebude pozdě na nápravu.

Dávejte pozor na varovné signály v prvních týdnech: zmeškané termíny bez komunikace, odpor ke code review, neschopnost vysvětlit, na čem pracují, nebo kód, který se po nasazení opakovaně rozbíjí. Tyto vzorce z prvního měsíce mají tendenci přetrvávat.

Pokud věci nefungují, jednejte rychle. Utopené náklady na výběrové řízení nejsou důvodem ponechat si nevhodného člověka. Každý týden, který odkládáte, stojí víc než ten předchozí.

Pro firmy bez interního technického vedení doporučujeme doplnit práci nového vývojáře pravidelnými externími code review. Čtvrtletní kontrola kódu externím odborníkem, například přes službu rozšíření a integrace systémů od Bitvea, zachytí architektonické problémy dříve, než se stanou nákladnými. Zároveň ověří, že bezpečnostní postupy ve vašem kódu odpovídají profesionálním standardům.

Váš další krok

Najímat vývojáře bez CTO je náročné, ale ne nemožné. Zakladatelé, kterým se to daří, mají strukturovaný proces, pokládají správné otázky a vědí, kdy přizvat pomoc.

Začněte pětikrokovým frameworkem, který jsme popsali. Jasně definujte roli. Prověřte portfolia, zda obsahují živé projekty. Pokládejte otázky testující myšlení, ne triviální znalosti. Zadejte praktické úkoly. Ověřte reference cílenými otázkami.

A pokud je nábor natolik zásadní, že by špatný krok vrátil vaši firmu o měsíce zpět, nenechávejte to náhodě. Ozvěte se nám a zajistíme profesionální technické hodnocení, které vám dá jistotu v náborovém rozhodnutí.

Náklady na prověření kandidáta jsou vždy nižší než náklady na špatný nábor.