AI pohovor pre React vývojárov — Automatizujte screening a nábor

Otázky na AI pohovor pre React vývojárov: Čo sa pýtať a aké odpovede očakávať

Pri pohovoroch s React vývojármi — či už manuálnych alebo s AI Screenr — správne otázky oddelia povrchné znalosti od skutočných produkčných skúseností. Nižšie sú uvedené kľúčové oblasti hodnotenia, založené na oficiálnej dokumentácii Reactu a reálnych vzoroch screeningu.

1. Hooks a správa stavu

Otázka: „Vysvetlite rozdiel medzi useMemo a useCallback. Kedy by ste použili ktorý?“

Očakávaná odpoveď: „useMemo kešuje vypočítanú hodnotu, useCallback kešuje referenciu funkcie. useMemo používam na nákladné výpočty — napríklad filtrovanie veľkého zoznamu — aby sa neprepočítavali pri každom rendere. useCallback slúži na stabilizáciu referencií funkcií odovzdávaných podriadeným komponentom obaleným v React.memo, čím sa zabráni zbytočným re-renderom. V praxi najprv profilujem pomocou React DevTools, skôr než pridám čokoľvek z toho — predčasná memoizácia pridáva zložitosť bez merateľného prínosu.“

Varovný signál: Kandidát povie „sú to v podstate to isté“ alebo nevie vysvetliť, kedy ich NEPOUŽIŤ.

Otázka: „Ako by ste implementovali vlastný hook na validáciu formulára? Prejdite ma návrhom API.“

Očakávaná odpoveď: „Vytvoril by som hook useFormValidation, ktorý prijíma validačnú schému a vracia stavy polí, chybové hlásenia a handlery. API by vyzeralo takto: const { values, errors, handleChange, handleSubmit, isValid } = useFormValidation({ schema, initialValues }). Interne používa useState pre hodnoty polí, useEffect pre asynchrónnu validáciu (napríklad kontrolu unikátnosti e-mailu) a useCallback pre memoizované handlery. Na definíciu schémy by som použil Zod alebo Yup. Kľúčové rozhodnutie pri návrhu je, či validovať pri zmene, pri opustení poľa alebo pri odoslaní — uprednostňujem on-blur pre UX a on-submit ako záložnú možnosť.“

Varovný signál: Kandidát preskočí rovno k odporúčaniam knižníc (Formik, React Hook Form) bez toho, aby vysvetlil základný vzor.

Otázka: „Kedy Context API prestáva stačiť? Aké signály vám povedia, že je čas na externú knižnicu pre stav?“

Očakávaná odpoveď: „Context funguje dobre pre dáta, ktoré sa menia zriedkavo, ako témy, autentifikácia alebo locale. Signál na prechod je, keď si všimnete: (1) príliš veľa re-renderov, pretože Context spustí aktualizácie u všetkých konzumentov, aj keď sa zmenila len časť stavu, (2) objekt hodnoty kontextu sa rozrastá do zložitosti s mnohými nesúvisiacimi poľami alebo (3) potrebujete odvodený stav alebo middleware vzory. V tom bode by som zvážil Zustand pre jednoduchosť alebo Redux Toolkit pre zložité flow. Kľúčová metrika je, či rozdelenie na viacero kontextov rieši problém s re-rendermi — ak potrebujete 5+ kontextov, knižnica na stav je čistejšia.“

Varovný signál: Kandidát povie „Context je vždy zlý na výkon“ (prílišné zjednodušenie) alebo sa s týmto obmedzením nikdy nestretol.

2. Komponentová architektúra — kritická pri screeningu senior React vývojárov

Otázka: „Ako štruktúrujete veľkú React aplikáciu? Aká je vaša stratégia súborov/priečinkov?“

Očakávaná odpoveď: „Organizujem podľa feature, nie podľa typu. Namiesto priečinkov /components, /hooks, /utils používam /features/auth, /features/dashboard atď. Každý feature priečinok obsahuje svoje komponenty, hooks, typy a testy. Zdieľaný kód ide do /shared. Používam barrel exporty (index.ts) na kontrolu verejného API každej feature. Pre routing kolokujem route komponenty s ich feature. Tento prístup škáluje lepšie, pretože pridanie novej feature nevyžaduje zásah do 5 rôznych top-level priečinkov.“

Varovný signál: Kandidát opíše iba vzor „podľa typu“ (/components, /pages, /services) alebo nikdy nepracoval na projekte dostatočne veľkom na to, aby vyžadoval štruktúru.

Otázka: „Vysvetlite compound component pattern. Kedy je lepší než prop drilling?“

Očakávaná odpoveď: „Compound components zdieľajú implicitný stav cez React Context. Predstavte si to ako HTML select/option — rodič spravuje stav a deti ho konzumujú. Použil by som to pre zložité UI ako Tabs, Accordion alebo Dropdown, kde rodič potrebuje koordinovať viacero detí. API sa stáva <Tabs><Tab label='...'><Panel>...</Panel></Tab></Tabs> namiesto odovzdávania polí konfiguračných objektov. Je lepší než prop drilling, keď je hierarchia komponentov hlboká a medziľahlé komponenty props nepotrebujú. Pre jednoduché rodič-dieťa vzťahy je to zbytočné.“

Varovný signál: Kandidát si ho pomýli s render props alebo HOC, alebo nevie uviesť praktický príklad.

Otázka: „Ako pristupujete k budovaniu znovupoužiteľnej knižnice komponentov?“

Očakávaná odpoveď: „Začnem auditom design systému — identifikujem 10 – 15 najčastejšie používaných UI vzorov. Najprv postavím atómy (Button, Input, Badge), potom molekuly (FormField, Card, Modal). Každý komponent získa: TypeScript props interface, podporu forwardRef, spájanie className (cez clsx/cn), rozumné predvolené hodnoty a Storybook dokumentáciu. Používam kompozíciu namiesto konfigurácie — Button nemá 20 variantov cez props, namiesto toho skladáte ButtonIcon + ButtonText. Na distribúciu by som použil monorepo so samostatnými balíkmi alebo jediný balík s exportmi priateľskými k tree-shakingu.“

Varovný signál: Kandidát začne slovami „nainštaloval by som UI knižnicu ako MUI“ bez toho, aby rozumel princípom.

3. Optimalizácia výkonu — kľúčová screeningová oblasť pre React vývojárov

Otázka: „Aké nástroje používate na diagnostiku problémov s výkonom Reactu?“

Očakávaná odpoveď: „Môj postup je: (1) React DevTools Profiler na zistenie, ktoré komponenty sa re-renderujú a ako dlho im to trvá, (2) Chrome Performance tab na zachytenie dlhých úloh a layout thrashingu, (3) Lighthouse pre celkové metriky stránky (LCP, FID, CLS), (4) bundle analyzer (webpack-bundle-analyzer alebo source-map-explorer) pre problémy s veľkosťou balíka a (5) knižnicu why-did-you-render počas vývoja na skoré zachytenie zbytočných re-renderov. Tiež nastavujem výkonnostné rozpočty v CI — ak hlavný balík prekročí prah, build zlyhá.“

Varovný signál: Kandidát spomenie iba „console.log timing“ alebo nemá systematický prístup.

Otázka: „Ako by ste optimalizovali vykresľovanie zoznamu s 5 000+ položkami?“

Očakávaná odpoveď: „Virtualizácia je primárne riešenie — renderovať iba viditeľné riadky. Použil by som react-window alebo react-virtuoso. Kľúčom je meranie výšok riadkov: pevné výšky sú triviálne, premenlivé výšky potrebujú cache meraní. Okrem virtualizácie by som tiež: (1) memoizoval row komponenty cez React.memo, (2) použil stabilné kľúče (ID, nie indexy), (3) debounceoval scroll handlery, (4) implementoval stránkovanie alebo infinite scroll ako alternatívne UX. V našom dátovom gride virtualizácia znížila počiatočný render z viac než 3 sekúnd na pod 200 ms.“

Varovný signál: Kandidát navrhne „len použite stránkovanie“ bez pochopenia virtualizácie, alebo spomenie virtualizáciu, no nevie vysvetliť implementáciu.

Otázka: „Vysvetlite, ako funguje reconciliation algoritmus Reactu a ako ovplyvňuje vaše kódovacie rozhodnutia.“

Očakávaná odpoveď: „React porovnáva predchádzajúci a aktuálny strom virtuálneho DOMu pomocou diffing algoritmu. Dve kľúčové heuristiky: (1) elementy rôznych typov produkujú rozdielne stromy (úplný remount) a (2) kľúče identifikujú, ktoré deti sa v zozname zmenili. To ovplyvňuje moje kódovanie takto: vyhýbam sa podmienečnej zmene typov komponentov (spôsobuje remount), v zoznamoch vždy používam stabilné kľúče (nie index poľa), komponenty štruktúrujem tak, aby sa nákladné podstromy neprerenderovali pri zmene nesúvisiaceho stavu (kompozičný vzor alebo memo) a stav dvíham len tak vysoko, ako je potrebné, aby som minimalizoval dosah aktualizácií.“

Varovný signál: Kandidát povie „React re-renderuje všetko“ alebo nerozumie kľúčom nad rámec „React na ne upozorňuje“.

4. Testovanie — často prehliadané pri screeningu React vývojárov

Otázka: „Aký je váš prístup k testovaniu React aplikácií?“

Očakávaná odpoveď: „Riadim sa testovacou trofejou: väčšinou integračné testy, niektoré unit testy, málo E2E. Pre komponenty používam React Testing Library s princípom testovania správania používateľa, nie detailov implementácie — dopytujem sa podľa role, labelu alebo textu, nikdy podľa className alebo test-id, ak sa tomu dá vyhnúť. Pre hooks používam renderHook. Pre zložitú logiku stavu testujem reducery samostatne cez unit testy. E2E s Playwright pre kritické používateľské toky (registrácia, checkout). Mierim na pokrytie 70 – 80 %, ale zameriavam sa skôr na dôveru než na percentá — jeden test pre šťastný scenár a jeden pre hlavný chybový prípad na feature.“

Varovný signál: Kandidát píše testy, ktoré tvrdia wrapper.find('.button-class').length === 1 (testuje implementáciu, nie správanie).