React-specific interview questions covering hooks, state management, component patterns, and the modern React ecosystem.
Focus on the pain points hooks solved: "Logic reuse required HOCs or render props which created wrapper hell. Custom hooks let me extract and share stateful logic as plain functions."
Hooks solve logic reuse (custom hooks replace HOCs and render props), avoid the confusion of "this" binding, and allow related code to be grouped together instead of split across lifecycle methods. Strong candidates mention that hooks compose better, reduce boilerplate, and make testing easier. They should also note that class components still work and are not deprecated.
Baseline React knowledge. Candidates who cannot explain why hooks exist may have adopted them without understanding the motivation. Those who dismiss class components entirely may lack experience with older codebases.
Show you understand the trade-off: "I use context for auth and theme. For complex app state with frequent updates, I reach for Zustand because it avoids the re-render problem and has a simpler API than Redux."
Context is good for low-frequency updates shared across many components (theme, auth, locale). It is poor for high-frequency updates because every consumer re-renders. Redux/Zustand are better for complex state with many updates, devtools support, and middleware. Strong candidates discuss the re-render cost of context, the complexity cost of Redux, and newer lightweight options like Zustand or Jotai.
Tests practical state management experience. Candidates who put everything in Redux or everything in context are showing a lack of nuance. Look for the ability to match tools to problems.
Show evolution: "The container/presentational split taught us separation of concerns. Now custom hooks achieve the same goal more naturally, letting any component be both smart and focused."
Container components handle data fetching and logic; presentational components handle rendering. With hooks, this pattern is less strictly necessary because custom hooks can extract the logic layer. However, the separation of concerns principle still applies. Strong candidates discuss how custom hooks replaced containers for logic extraction while keeping components focused on rendering.
Tests architectural thinking in React. Candidates who rigidly follow old patterns or completely ignore separation of concerns both raise flags. Best answers show pragmatic evolution.
Lead with measurement: "I open React DevTools Profiler, record an interaction, and look for components that re-render without their props changing. Then I apply React.memo or restructure the component tree."
Strong answers follow a systematic approach: use React DevTools Profiler to identify unnecessary re-renders, check component tree depth, look for missing keys in lists, and identify expensive computations. Solutions: React.memo for pure components, useMemo/useCallback for expensive calculations and stable references, code splitting with React.lazy, virtualisation for long lists. Best candidates measure before optimising.
Senior-level question. Developers who immediately reach for memo without profiling are cargo-culting. Those who can systematically diagnose re-render chains and apply targeted fixes are strong.
Emphasise user-centric testing: "I use React Testing Library with getByRole queries, test what the user sees and does, and mock API calls with MSW to test realistic flows."
Best practice: test behaviour, not implementation. Use React Testing Library to render components and interact with them as a user would. Unit test custom hooks in isolation. Integration test key user flows. Avoid testing implementation details like internal state or DOM structure. Strong candidates mention accessibility queries (getByRole, getByLabelText) and mock APIs at the network level (MSW).
Tests professional frontend practices. Candidates who test implementation details (checking state values, counting renders) are writing brittle tests. Those who use RTL idiomatically and focus on behaviour are strong.
Match the tool to the need: "For a marketing site I would use Next.js with static generation. For an internal dashboard, client-side rendering is fine because SEO and initial load time matter less."
SSR benefits: better SEO, faster first contentful paint, works without JS. Trade-offs: increased server load, hydration complexity, slower time-to-interactive, no access to browser APIs during render. Strong candidates discuss Next.js/Remix, static generation vs SSR, and streaming with React Server Components. They should know when SSR is overkill (internal dashboards) and when it is essential (content sites, e-commerce).
Tests architectural decision-making. Candidates who always or never choose SSR lack judgment. Those who consider the specific requirements (SEO, performance, complexity budget) make better decisions.
Cover the basics and go deeper: "React Router uses the History API to match URLs to components. I code-split per route with React.lazy and use route loaders for data fetching."
Client-side routing intercepts navigation, updates the URL via the History API, and renders the matching component without a full page reload. Key considerations: code splitting per route, handling 404s, protecting authenticated routes, scroll restoration, and deep linking. Strong candidates mention data loading strategies (loaders in React Router v6/Remix) and the UX of loading states.
Fundamental SPA knowledge. Candidates who cannot explain how client-side routing works lack core web development understanding. Those who mention modern features like route loaders show current awareness.
Show practical awareness: "I use React Hook Form for most forms because it uses uncontrolled inputs for performance and integrates well with Zod for schema validation."
Controlled components sync form state with React state on every change; uncontrolled components use refs to read values on submit. Libraries: React Hook Form (uncontrolled, performant), Formik (controlled, full-featured), or native HTML validation. Strong candidates discuss trade-offs: controlled gives full control but can cause excessive re-renders; uncontrolled is more performant but harder to validate in real-time.
Common React challenge. Candidates who write all form logic from scratch may not know the ecosystem. Those who blindly use a library without understanding controlled vs uncontrolled lack fundamentals.
Name specific tools and patterns: "I use eslint-plugin-jsx-a11y in CI, test with axe DevTools, trap focus in modals with a custom hook, and use aria-live for toast notifications."
Key practices: semantic HTML elements, proper ARIA attributes, keyboard navigation, focus management (especially with modals and dynamic content), accessible forms with labels, and colour contrast. Tools: eslint-plugin-jsx-a11y, axe DevTools, screen reader testing. Strong candidates mention specific patterns like focus trapping in modals and live regions for dynamic updates.
Increasingly expected of frontend developers. Candidates who never consider accessibility in React are missing a fundamental skill. Ask for a specific example of an accessibility challenge they solved in a React app.
Ground decisions in requirements: "For an SEO-heavy content site I would choose Next.js with static generation. For an internal tool, Vite with React Router keeps things simpler."
Key decisions: framework (Next.js, Remix, Vite+React), state management, styling (CSS Modules, Tailwind, styled-components), data fetching (TanStack Query, SWR), form handling, testing setup, and build tooling. Strong candidates explain their reasoning based on project requirements (SSR needs, team size, performance requirements) rather than just listing trendy tools.
Tests senior-level decision-making. Candidates who always choose the same stack regardless of requirements lack flexibility. Those who can articulate trade-offs between options and tailor choices to the project show maturity.