AI Interview for React Developers — Automate Screening & Hiring

AI Interview Questions for React Developers: What to Ask & Expected Answers

When interviewing React developers — whether manually or with AI Screenr — the right questions separate surface-level knowledge from real production experience. Below are the key areas to assess, based on the official React documentation and real-world screening patterns.

1. Hooks & State Management

Q: "Explain the difference between useMemo and useCallback. When would you use each?"

Expected answer: "useMemo caches a computed value, useCallback caches a function reference. I use useMemo for expensive calculations — like filtering a large list — so it doesn't recompute on every render. useCallback is for stabilizing function references passed to child components wrapped in React.memo, preventing unnecessary re-renders. In practice, I profile first with React DevTools before adding either — premature memoization adds complexity without measurable benefit."

Red flag: Candidate says "they're basically the same thing" or can't explain when NOT to use them.

Q: "How would you implement a custom hook for form validation? Walk me through the API design."

Expected answer: "I'd create a useFormValidation hook that accepts a validation schema and returns field states, error messages, and handlers. The API would look like: const { values, errors, handleChange, handleSubmit, isValid } = useFormValidation({ schema, initialValues }). Internally, it uses useState for field values, useEffect for async validation (like checking email uniqueness), and useCallback for memoized handlers. I'd use Zod or Yup for schema definition. The key design decision is whether to validate on change, on blur, or on submit — I prefer on-blur for UX with on-submit as a fallback."

Red flag: Candidate jumps straight to library recommendations (Formik, React Hook Form) without explaining the underlying pattern.

Q: "When does Context API become insufficient? What signals tell you it's time for an external state library?"

Expected answer: "Context works well for infrequently-changing data like themes, auth, or locale. The signal to migrate is when you notice: (1) too many re-renders because Context triggers updates for all consumers even when only part of the state changed, (2) the context value object grows complex with many unrelated fields, or (3) you need derived state or middleware patterns. At that point, I'd consider Zustand for simplicity or Redux Toolkit for complex flows. The key metric is whether splitting into multiple contexts solves the re-render problem — if you need 5+ contexts, a state library is cleaner."

Red flag: Candidate says "Context is always bad for performance" (oversimplification) or has never encountered the limitation.

2. Component Architecture — Critical for Screening Senior React Developers

Q: "How do you structure a large React application? What's your file/folder strategy?"

Expected answer: "I organize by feature, not by type. Instead of /components, /hooks, /utils folders, I use /features/auth, /features/dashboard, etc. Each feature folder contains its components, hooks, types, and tests. Shared code goes in /shared. I use barrel exports (index.ts) to control the public API of each feature. For routing, I colocate route components with their feature. This scales better because adding a feature doesn't require touching 5 different top-level folders."

Red flag: Candidate describes only the "by type" pattern (/components, /pages, /services) or has never worked on a project large enough to need structure.

Q: "Explain the compound component pattern. When is it better than prop drilling?"

Expected answer: "Compound components share implicit state through React Context. Think of it like HTML's select/option — the parent manages state and children consume it. I'd use this for complex UI like Tabs, Accordion, or Dropdown where the parent needs to coordinate multiple children. The API becomes <Tabs><Tab label='...'><Panel>...</Panel></Tab></Tabs> instead of passing arrays of config objects. It's better than prop drilling when the component hierarchy is deep and the intermediate components don't need the props. It's overkill for simple parent-child relationships."

Red flag: Candidate confuses this with render props or HOCs, or can't give a practical example.

Q: "How do you approach building a reusable component library?"

Expected answer: "Start with a design system audit — identify the 10-15 most-used UI patterns. Build atoms first (Button, Input, Badge), then molecules (FormField, Card, Modal). Each component gets: TypeScript props interface, forwardRef support, className merging (via clsx/cn), sensible defaults, and Storybook documentation. I use composition over configuration — a Button doesn't have 20 variants via props, instead you compose ButtonIcon + ButtonText. For distribution, I'd use a monorepo with separate packages or a single package with tree-shaking-friendly exports."

Red flag: Candidate starts with "I'd install a UI library like MUI" without understanding the principles.

3. Performance Optimization — Key Screening Area for React Developers

Q: "What tools do you use to diagnose React performance issues?"

Expected answer: "My workflow is: (1) React DevTools Profiler to identify which components re-render and how long they take, (2) Chrome Performance tab to spot long tasks and layout thrashing, (3) Lighthouse for overall page metrics (LCP, FID, CLS), (4) bundle analyzer (webpack-bundle-analyzer or source-map-explorer) for bundle size issues, and (5) why-did-you-render library during development to catch unnecessary re-renders early. I also set up performance budgets in CI — if the main bundle grows past a threshold, the build fails."

Red flag: Candidate only mentions "console.log timing" or has no systematic approach.

Q: "How would you optimize a list rendering 5,000+ items?"

Expected answer: "Virtualization is the primary solution — only render visible rows. I'd use react-window or react-virtuoso. The key is measuring row heights: fixed-height rows are trivial, variable heights need a measurement cache. Beyond virtualization, I'd also: (1) memoize row components with React.memo, (2) use stable keys (IDs, not indices), (3) debounce scroll handlers, (4) implement pagination or infinite scroll as an alternative UX. For our data grid at work, virtualization reduced initial render from 3+ seconds to under 200ms."

Red flag: Candidate suggests "just use pagination" without understanding virtualization, or mentions virtualization but can't explain the implementation.

Q: "Explain how React's reconciliation algorithm works and how it affects your coding decisions."

Expected answer: "React compares the previous and current virtual DOM trees using a diffing algorithm. Two key heuristics: (1) elements of different types produce different trees (full remount), and (2) keys identify which children changed in a list. This affects my coding because: I avoid changing component types conditionally (causes remount), I always use stable keys in lists (not array index), I structure components so expensive subtrees don't re-render when unrelated state changes (composition pattern or memo), and I lift state up only as far as needed to minimize the blast radius of updates."

Red flag: Candidate says "React re-renders everything" or doesn't understand keys beyond "React warns about them."

4. Testing — Often Overlooked When Screening React Developers

Q: "What's your approach to testing React applications?"

Expected answer: "I follow the testing trophy: mostly integration tests, some unit tests, few E2E. For components, I use React Testing Library with the principle of testing user behavior, not implementation details — I query by role, label, or text, never by className or test-id if avoidable. For hooks, I use renderHook. For complex state logic, I unit-test reducers separately. E2E with Playwright for critical user flows (signup, checkout). I aim for 70-80% coverage but focus on confidence over percentage — one test for the happy path and one for the main error case per feature."

Red flag: Candidate writes tests that assert wrapper.find('.button-class').length === 1 (testing implementation, not behavior).