48 hodin do technického pohovoru: přesný plán na tři bloky
Dostali jste pozvánku na technický pohovor a zbývají vám dva dny. Panika nepomůže, ale strukturovaný plán ano.
Pozvánka přišla ve středu večer, pohovor je v pátek dopoledne. Přesně tahle situace potká každého IT kandidáta alespoň jednou. Otázka není, jestli stihnete nastudovat vše od základů. Otázka je, co konkrétně uděláte v příštích 48 hodinách, aby se čas proměnil v sebevědomí, ne v přečtené záložky, které jste nestihli dočíst.
Proč 48 hodin stačí, když víte, jak je rozdělit
Většina kandidátů udělá stejnou chybu: prvních šest hodin leze po YouTube, pak otevře pět záložek o systémovém designu, pak si vzpomene, že by měl procvičit algoritmy, a nakonec usne nad LeetCode Hard úlohou, která s pohovorem nesouvisí. Výsledek je vyčerpání a pocit, že nic neumí.
Lepší přístup je mechanický. Rozdělte 48 hodin na tři stejné bloky po šestnácti hodinách. Každý blok má jiný cíl a jiný typ práce. Nepřeskakujte mezi nimi.
Blok první: technické základy (prvních 16 hodin)
Nezačínejte od nuly. Začněte od toho, co firma skutečně testuje. Projděte GitHub repozitáře s typovými úlohami z minulých pohovorů a vyberte tři úlohy na úrovni LeetCode Medium, které se váží k technologii uvedené v inzerátu. Neřešte deset úloh povrchně, vyřešte tři pořádně a pochopte, proč fungují.
Pak udělejte jednu zdánlivě primitivní věc: vezměte papír a napište tři principy z dané technologie, které opravdu používáte. Pokud jde o React, může to být:
- Virtuální DOM a jak React rozhoduje, co překreslit
- useEffect lifecycle včetně cleanup funkce a závislostního pole
- State management a kdy použít lokální stav versus globální řešení jako Zustand nebo Redux
Psaní rukou na papír není nostalgie. Je to způsob, jak ověřit, jestli látce skutečně rozumíte, nebo ji jen pasivně poznáváte. Pokud se zasekne ruka, zasekne se i řeč u tabule.
Blok druhý: systémový design a reálný scénář (dalších 16 hodin)
Systémový design děsí kandidáty, kteří ho nikdy nezkoušeli nahlas nebo na papíře. Přitom příprava není složitá. Vezměte projekt, na kterém jste reálně pracovali, a nakreslete jeho architekturu. Doma na tabuli, na papíře, na tabletu. Kreslete databázi, API vrstvu, frontend, cache, fronty zpráv, cokoliv, co tam bylo. Nemusí to být dokonalé, musí to být vaše.
Pak si připravte odpověď na otázku, která padá v různých variantách téměř všude:
„Jak byste navrhli systém pro e-shop s deseti tisíci objednávkami denně?"
Necvičte odpověď memorováním. Cvičte přístup: co se ptáte jako první (požadavky, škálovatelnost, konzistence dat), jak rozdělujete problém, kde jsou úzká hrdla. Tazatel chce vidět, jak přemýšlíte, ne jestli znáte správnou odpověď. Správná odpověď neexistuje.
Blok třetí: měkké dovednosti a kulturní fit (posledních 16 hodin)
Tenhle blok kandidáti nejčastěji přeskočí s tím, že na soft skills se přece nedá připravit. Dá. A přeskočením ho ztrácejí body tam, kde je ostatní sbírají.
Konkrétně udělejte dvě věci:
- Připravte si tři otázky na proces v týmu. Například: Jak u vás probíhá code review? Jak řešíte technický dluh? Kdo rozhoduje o architektuře? Otázky ukazují, že přemýšlíte o práci, ne jen o nabídce.
- Natrénujte odpověď na „Proč chcete odejít ze současné práce?" Časový limit je třicet sekund. Kratší odpověď působí připraveně, delší začíná znít jako stěžování.
Co konkrétně do třiceti sekund říct
Nemluvte negativně o současném zaměstnavateli. Mluvte o tom, co hledáte. Funkční šablona vypadá přibližně takto: pojmenujte, čeho jste dosáhli, řekněte, co vám v aktuálním místě chybí pro další růst, a jednou větou propojte to s pozicí, na kterou se hlásíte. Tři věty, třicet sekund, hotovo.
Co z tohoto plánu nejčastěji lidem dělá problém
Na základě zpětné vazby od kandidátů jsou kritická místa dvě. První je systémový design, konkrétně pocit, že nemají dost zkušeností na to, aby navrhovali „velké systémy". Přitom každý, kdo někdy navrhl databázové schéma nebo rozhodl, kde uložit session, již systémový design dělal. Jen ho tak nenazýval.
Druhé kritické místo je odpověď na otázku o odchodu. Kandidáti buď říkají příliš málo (mlčení, vágní formulace), nebo příliš mnoho (dlouhý příběh o toxickém nadřízeném). Třicetisekundový limit je ochrana před oběma extrémy.
Čtyřicet osm hodin není málo. Je to dost na to, aby pohovor proběhl jako rozhovor dvou profesionálů, ne jako zkouška, kterou jste nestihli prostudovat.
Na přípravě textu se podílela umělá inteligence. Obsah prošel redakční kontrolou.