AI pohovor pro React vývojáře — Automatizujte screening a nábor

Otázky na AI pohovor pro React vývojáře: Co se ptát a jaké odpovědi očekávat

Při pohovorech s React vývojáři — ať už manuálních nebo s AI Screenr — správné otázky oddělí povrchní znalosti od skutečných produkčních zkušeností. Níže jsou uvedeny klíčové oblasti hodnocení, založené na oficiální dokumentaci Reactu a reálných vzorech screeningu.

1. Hooks a správa stavu

Otázka: „Vysvětlete rozdíl mezi useMemo a useCallback. Kdy byste použil co?“

Očekávaná odpověď: „useMemo cachuje vypočtenou hodnotu, useCallback cachuje referenci funkce. useMemo používám na nákladné výpočty — například filtrování velkého seznamu — aby se nepřepočítávaly při každém renderu. useCallback slouží ke stabilizaci referencí funkcí předávaných podřízeným komponentům zabaleným v React.memo, čímž se zabrání zbytečným re-renderům. V praxi nejprve profiluji pomocí React DevTools, než přidám cokoli z toho — předčasná memoizace přidává složitost bez měřitelného přínosu.“

Varovný signál: Kandidát řekne „jsou to v podstatě totéž“ nebo neumí vysvětlit, kdy je NEPOUŽÍT.

Otázka: „Jak byste implementoval vlastní hook pro validaci formuláře? Projděte mě návrhem API.“

Očekávaná odpověď: „Vytvořil bych hook useFormValidation, který přijímá validační schéma a vrací stavy polí, chybové zprávy a handlery. API by vypadalo takto: const { values, errors, handleChange, handleSubmit, isValid } = useFormValidation({ schema, initialValues }). Interně používá useState pro hodnoty polí, useEffect pro asynchronní validaci (například kontrolu jedinečnosti e-mailu) a useCallback pro memoizované handlery. Pro definici schématu bych použil Zod nebo Yup. Klíčové rozhodnutí při návrhu je, zda validovat při změně, při opuštění pole nebo při odeslání — preferuji on-blur pro UX a on-submit jako záložní možnost.“

Varovný signál: Kandidát přeskočí rovnou k doporučením knihoven (Formik, React Hook Form), aniž by vysvětlil základní vzor.

Otázka: „Kdy přestává Context API stačit? Jaké signály vám řeknou, že je čas na externí knihovnu pro stav?“

Očekávaná odpověď: „Context funguje dobře pro data, která se mění zřídka, jako témata, autentizace nebo locale. Signál k přechodu je, když si všimnete: (1) příliš mnoho re-renderů, protože Context spustí aktualizace u všech konzumentů, i když se změnila jen část stavu, (2) objekt hodnoty kontextu se rozrůstá do složitosti s mnoha nesouvisejícími poli, nebo (3) potřebujete odvozený stav nebo middleware vzory. V tom bodě bych zvážil Zustand pro jednoduchost nebo Redux Toolkit pro složité flow. Klíčovou metrikou je, zda rozdělení na více kontextů řeší problém s re-rendery — pokud potřebujete 5+ kontextů, knihovna pro stav je čistší.“

Varovný signál: Kandidát řekne „Context je vždy špatný pro výkon“ (přílišné zjednodušení) nebo se s tímto omezením nikdy nesetkal.

2. Komponentová architektura — klíčová při screeningu senior React vývojářů

Otázka: „Jak strukturujete velkou React aplikaci? Jaká je vaše strategie souborů/složek?“

Očekávaná odpověď: „Organizuji podle feature, ne podle typu. Místo složek /components, /hooks, /utils používám /features/auth, /features/dashboard atd. Každá feature složka obsahuje své komponenty, hooks, typy a testy. Sdílený kód jde do /shared. Používám barrel exporty (index.ts) ke kontrole veřejného API každé feature. Pro routing kolokuji route komponenty s jejich feature. Tento přístup škáluje lépe, protože přidání nové feature nevyžaduje zásah do 5 různých top-level složek.“

Varovný signál: Kandidát popíše pouze vzor „podle typu“ (/components, /pages, /services) nebo nikdy nepracoval na projektu dostatečně velkém na to, aby vyžadoval strukturu.

Otázka: „Vysvětlete compound component pattern. Kdy je lepší než prop drilling?“

Očekávaná odpověď: „Compound components sdílejí implicitní stav přes React Context. Představte si to jako HTML select/option — rodič spravuje stav a děti jej konzumují. Použil bych to pro složité UI jako Tabs, Accordion nebo Dropdown, kde rodič potřebuje koordinovat více dětí. API se stává <Tabs><Tab label='...'><Panel>...</Panel></Tab></Tabs> místo předávání polí konfiguračních objektů. Je lepší než prop drilling, když je hierarchie komponentů hluboká a mezilehlé komponenty props nepotřebují. Pro jednoduché rodič-dítě vztahy je to zbytečné.“

Varovný signál: Kandidát si jej plete s render props nebo HOC, nebo neumí uvést praktický příklad.

Otázka: „Jak přistupujete k budování znovupoužitelné knihovny komponentů?“

Očekávaná odpověď: „Začnu auditem design systému — identifikuji 10–15 nejčastěji používaných UI vzorů. Nejprve postavím atomy (Button, Input, Badge), poté molekuly (FormField, Card, Modal). Každý komponent získá: TypeScript props interface, podporu forwardRef, spojování className (přes clsx/cn), rozumné výchozí hodnoty a Storybook dokumentaci. Používám kompozici místo konfigurace — Button nemá 20 variant přes props, místo toho skládáte ButtonIcon + ButtonText. Pro distribuci bych použil monorepo se samostatnými balíky nebo jediný balík s exporty přátelskými k tree-shakingu.“

Varovný signál: Kandidát začne slovy „nainstaloval bych UI knihovnu jako MUI“, aniž by rozuměl principům.

3. Optimalizace výkonu — klíčová screeningová oblast pro React vývojáře

Otázka: „Jaké nástroje používáte k diagnostice problémů s výkonem Reactu?“

Očekávaná odpověď: „Můj postup je: (1) React DevTools Profiler ke zjištění, které komponenty se re-renderují a jak dlouho jim to trvá, (2) Chrome Performance tab k zachycení dlouhých úloh a layout thrashingu, (3) Lighthouse pro celkové metriky stránky (LCP, FID, CLS), (4) bundle analyzer (webpack-bundle-analyzer nebo source-map-explorer) pro problémy s velikostí balíku a (5) knihovnu why-did-you-render během vývoje k časnému zachycení zbytečných re-renderů. Také nastavuji výkonnostní rozpočty v CI — pokud hlavní balík překročí práh, build selže.“

Varovný signál: Kandidát zmíní pouze „console.log timing“ nebo nemá systematický přístup.

Otázka: „Jak byste optimalizoval vykreslování seznamu s 5 000+ položkami?“

Očekávaná odpověď: „Virtualizace je primárním řešením — renderovat pouze viditelné řádky. Použil bych react-window nebo react-virtuoso. Klíčem je měření výšek řádků: pevné výšky jsou triviální, proměnné výšky potřebují cache měření. Kromě virtualizace bych také: (1) memoizoval row komponenty přes React.memo, (2) použil stabilní klíče (ID, ne indexy), (3) debounceoval scroll handlery, (4) implementoval stránkování nebo infinite scroll jako alternativní UX. V našem datovém gridu v práci virtualizace snížila počáteční render z více než 3 sekund na méně než 200 ms.“

Varovný signál: Kandidát navrhne „prostě použijte stránkování“ bez pochopení virtualizace, nebo zmíní virtualizaci, ale neumí vysvětlit implementaci.

Otázka: „Vysvětlete, jak funguje reconciliation algoritmus Reactu a jak ovlivňuje vaše kódovací rozhodnutí.“

Očekávaná odpověď: „React porovnává předchozí a aktuální strom virtuálního DOMu pomocí diffing algoritmu. Dvě klíčové heuristiky: (1) elementy různých typů produkují odlišné stromy (úplný remount) a (2) klíče identifikují, které děti se v seznamu změnily. To ovlivňuje mé kódování takto: vyhýbám se podmíněné změně typů komponentů (způsobuje remount), v seznamech vždy používám stabilní klíče (ne index pole), komponenty strukturuji tak, aby se nákladné podstromy nepřerenderovaly při změně nesouvisejícího stavu (kompoziční vzor nebo memo) a stav zvedám jen tak vysoko, jak je potřeba, abych minimalizoval dosah aktualizací.“

Varovný signál: Kandidát řekne „React re-renderuje všechno“ nebo nerozumí klíčům nad rámec „React na ně upozorňuje“.

4. Testování — často přehlížené při screeningu React vývojářů

Otázka: „Jaký je váš přístup k testování React aplikací?“

Očekávaná odpověď: „Řídím se testovací trofejí: většinou integrační testy, některé unit testy, málo E2E. Pro komponenty používám React Testing Library s principem testování chování uživatele, ne detailů implementace — dotazuji se podle role, labelu nebo textu, nikdy podle className nebo test-id, pokud se tomu dá vyhnout. Pro hooks používám renderHook. Pro složitou logiku stavu testuji reducery samostatně přes unit testy. E2E s Playwright pro kritické uživatelské toky (registrace, checkout). Mířím na pokrytí 70–80 %, ale zaměřuji se spíše na jistotu než na procenta — jeden test pro šťastný scénář a jeden pro hlavní chybový případ na feature.“

Varovný signál: Kandidát píše testy, které tvrdí wrapper.find('.button-class').length === 1 (testuje implementaci, ne chování).