Advanced
How React actually works under the hood, performance engineering, testing strategy, and the security posture interviewers expect you to bring up unprompted.
React Internals
Fiber, reconciliation, hydration, the synthetic event system, StrictMode, batching, concurrent rendering, and the runtime mental model.
Recommended prerequisites: react-basics
Why interviewers ask
Senior interviews drill on internals because they predict whether you can debug subtle bugs (hydration mismatches, stale closures, missed batches) instead of cargo-culting fixes.
Real-world relevance
Concurrent features change when effects fire. Hydration mismatches break SSR in production. Knowing the runtime is the difference between guessing at React Profiler output and reading it.
Common interview patterns
- Explain Fiber's work loop and how reconciliation walks the tree
- Diagnose a hydration mismatch and propose the fix
- Trace why an effect double-fires under StrictMode in development
- Walk through how `useTransition` and `useDeferredValue` change rendering priority
Common mistakes
- Assuming `setState` inside a Promise batches the same as inside an event handler (pre-React 18 it didn't)
- Misreading StrictMode's double-render as a real bug instead of a dev-mode mount/unmount/mount
- Reading state inside a stale closure and assuming React 'lost' the value
- Skipping the dependency array on `useEffect` and creating an infinite loop
Follow-up questions
- How does the Fiber scheduler decide which work to yield?
- What invariant must hold for SSR markup to hydrate cleanly?
- How would you design an error boundary that recovers without remounting siblings?
React Performance
When to memoize and when not to, virtualization, list rendering at scale, stable references, and the React Profiler workflow.
Recommended prerequisites: react-basics, react-internals
Why interviewers ask
Misapplied memo is the most common 'optimization' that hurts perf. Interviewers want to see you measure first, then fix with intent.
Real-world relevance
A 10k-row table, a slow type-ahead, a route transition that drops frames — these are weekly problems. Knowing the right tool (windowing, memo, key stability) avoids weeks of regressions.
Common interview patterns
- Virtualize long lists with `react-window` or a custom windower
- Stabilize callback identity with `useCallback` — only when the consumer is memoized
- Profile with the React Profiler to confirm a render is the bottleneck
- Split context to avoid full-tree re-renders on every change
Common mistakes
- Wrapping every component in `React.memo` without measuring — adds overhead without payoff
- Memoizing with deps that change every render (new object/array literal)
- Virtualizing a list of 50 items where a key fix would have been enough
- Putting frequently-changing values in a context that many consumers subscribe to
Follow-up questions
- How would you render 100k rows without freezing the browser?
- When does `useMemo` actually pay for itself, and when is it noise?
- How does React 18 automatic batching change perf tuning vs React 17?
Testing
Unit, integration, and end-to-end testing strategy with Jest, React Testing Library, Cypress, and Playwright — and what to test vs what to mock.
Recommended prerequisites: react-basics
Why interviewers ask
Tests reveal how a candidate thinks about contracts and regressions. The testing pyramid question separates engineers who write tests from those who write *useful* tests.
Real-world relevance
A flaky CI pipeline costs hours per week. Knowing where to draw the unit/integration/E2E line keeps the suite fast and trustworthy.
Common interview patterns
- Test behavior with RTL queries (`getByRole`) instead of implementation details
- Mock the network at the boundary with MSW, not at the fetch call
- Cover critical user flows in E2E, edge cases in unit
- Snapshot only stable, intentional output — never large trees
Common mistakes
- Querying by `data-testid` when an accessible role would do
- Mocking React itself or RTL internals to make a test pass
- Writing E2E tests for logic that a unit test could cover in 10ms
- Snapshotting everything and treating diffs as 'just update the snapshot'
Follow-up questions
- How would you test a component that depends on a context provider and a router?
- When would you prefer Cypress over Playwright (or vice versa)?
- How do you keep visual regression tests from flaking on font rendering?
Security
XSS, CSRF, CSP, cookie flags, auth token handling, OAuth basics, and the OWASP slice that frontend engineers actually own.
Recommended prerequisites: dom, networking
Why interviewers ask
Security questions filter for engineers who think about threat models, not just features. Senior loops expect you to bring it up before the interviewer does.
Real-world relevance
A token in localStorage is one XSS away from full account takeover. A missing `SameSite` cookie is one CSRF away from a fraudulent transfer. These choices live in code, not in security review.
Common interview patterns
- Store auth tokens in HttpOnly, Secure, SameSite cookies — never localStorage
- Sanitize user input at render, not just at submit; trust no string from the network
- Use CSP with nonces to lock down inline scripts
- Defend against CSRF with same-site cookies + a CSRF token on state-changing requests
Common mistakes
- Storing JWTs in localStorage 'because it's easier'
- Trusting `target="_blank"` without `rel="noopener noreferrer"`
- Relying on framework escaping alone for `dangerouslySetInnerHTML`
- Treating CORS as a security boundary (it's a browser policy, not server auth)
Follow-up questions
- How would you design a token refresh flow that survives XSS exposure?
- What does a strict CSP break, and how do you stage the rollout?
- How would you prevent a malicious parent page from spoofing a postMessage from your widget?
Accessibility
Semantic HTML, ARIA roles, keyboard navigation, focus management, screen reader behavior, and WCAG compliance at the component and app level.
Recommended prerequisites: dom
Why interviewers ask
A11y is a quality signal. Senior interviewers expect you to default to semantic HTML and only reach for ARIA when the platform falls short.
Real-world relevance
Accessibility lawsuits and regulatory pressure have made WCAG a delivery requirement at most large companies. A non-accessible modal blocks shipping in many compliance regimes.
Common interview patterns
- Prefer semantic HTML (`<button>`, `<dialog>`) over ARIA-on-div
- Trap focus inside modals and restore on close
- Announce live regions for dynamic content (toasts, errors)
- Test with keyboard-only navigation and a screen reader, not just axe
Common mistakes
- Using `<div onClick>` instead of `<button>` and losing keyboard + screen reader support
- ARIA-labeling a button that already has a visible label (duplicate announcement)
- Forgetting to update `aria-live` regions when async content arrives
- Relying on color alone to convey state
Follow-up questions
- How would you make a custom dropdown accessible without going full ARIA combobox?
- What does an SR announce differently for `role="alert"` vs `aria-live="polite"`?
- How would you enforce a11y across a 200-engineer org without slowing teams down?