25 React interview questions

Listen for: A strong answer starts by reproducing the issue, checking whether inputs are controlled or uncontrolled, and inspecting state updates around the API response. Listen for use of React DevTools, console logging of state transitions, attention to stale closures, keys that remount fields, and separating local typing state from server validation state.

Red flag: They immediately blame React or suggest rewriting the form without first isolating the state transition.

Listen for: Look for awareness of race conditions and cleanup. Good candidates mention AbortController, tracking request identity, moving fetching to TanStack Query or React Router loaders, and rendering loading and error states per filter. They should understand that dependency arrays are not enough when responses can arrive out of order.

Red flag: They say to remove dependencies from the effect to stop it from running.

Listen for: A strong junior answer is practical: local state for isolated UI, lifted state for sibling coordination, context for stable cross-tree values such as theme or current user, and a state library for complex shared client state. They should mention avoiding context for frequently changing large objects without considering re-render impact.

Red flag: They say all state should go into Redux or all state should stay local.

Listen for: Listen for measuring first with React DevTools Profiler and browser performance tools. Good signals include checking expensive filtering, unstable props, oversized DOM output, unnecessary parent re-renders, and network latency. They may suggest debouncing input, useDeferredValue, pagination or virtualization, and memoization only around proven expensive work.

Red flag: They present React.memo as a default fix without profiling or identifying the expensive work.

Listen for: The answer should cover focus management, Escape and arrow-key behavior, Enter or Space selection, visible focus styles, labels, roles only when they understand the pattern, and testing with keyboard and at least one screen reader. A strong candidate may prefer a native select when requirements allow it.

Red flag: They only mention adding aria-label and consider the component accessible.

Listen for: Look for user-focused tests with React Testing Library: editing fields, validation messages, disabled or pending save state, success and error responses, and avoiding implementation details like internal state names. They should mention mocking network calls with MSW or equivalent and keeping tests resilient to markup refactors.

Red flag: They focus only on snapshot tests or testing every hook call directly.

Listen for: Strong answers separate server state from UI state and use a tool such as TanStack Query 5, React Router 7 data APIs, or framework loaders. Listen for query keys that include filters, cancellation, stale and invalidation strategy, optimistic rollback, error boundaries, and keeping URL search params shareable.

Red flag: They store fetched data in a global client store and manually synchronize every request.

Listen for: Good candidates clarify the shape of state, write frequency, debugging needs, persistence, derived data, async workflows, and team familiarity. They distinguish server cache from client state and consider devtools, selectors, testing, and bundle cost. The strongest answers choose the smallest abstraction that still supports maintainability.

Red flag: They pick their favorite library before understanding the state model.

Listen for: Listen for comparing server-rendered and client-rendered output, checking nondeterministic values like dates, random IDs, locale formatting, feature flags, and browser-only APIs. Strong answers inspect Server and Client Component boundaries, deployment environment variables, streaming or Suspense behavior, and reproduce with a production build rather than dev mode.

Red flag: They suppress the hydration warning without finding the mismatch.

Listen for: Strong answers mention profiling first, splitting context by update frequency, memoizing provider values carefully, using selectors or an external store when appropriate, and keeping large mutable objects out of context. They understand that useMemo is not a complete fix if consumers still subscribe to broad changing values.

Red flag: They wrap every component in memo and expect the problem to disappear.

Listen for: Look for clear separation between step UI, form schema, persisted draft state, and submission side effects. Candidates may mention React Hook Form, Zod or Valibot, resumable uploads, server error mapping to fields, unsaved-change handling, accessibility of errors, and tests for back/forward navigation.

Red flag: They treat it as one giant component with one submit handler and no recovery path.

Listen for: Strong candidates distinguish client-side conditional rendering from real authorization on the server. They consider token storage, session refresh, CSRF depending on cookie strategy, loading states while session is unknown, route protection, avoiding sensitive data in bundles or logs, and handling expired sessions without losing user work.

Red flag: They say hiding a button in React is enough to enforce permissions.

Listen for: Listen for an incremental plan: inventory dependencies, add tests around critical flows, update React and React DOM, replace CRA scripts with Vite 7 config, handle environment variable differences, check Strict Mode effects, update testing setup, and migrate JavaScript files gradually with practical TypeScript settings.

Red flag: They propose a big-bang rewrite before assessing risk and dependencies.

Listen for: Strong answers combine technical and organizational strategy: start with high-value primitives, tokens, documentation, accessibility requirements, versioning, migration paths, and contribution rules. Listen for avoiding a component dumping ground, measuring adoption through code review patterns, and supporting both product flexibility and consistency.

Red flag: They focus only on publishing a component library package and ignore governance or migration.

Listen for: Look for trade-offs around SEO, personalization, cacheability, latency, data sensitivity, interactivity, and operational complexity. A strong answer may use Next.js App Router, React Server Components, streaming, and client boundaries selectively while avoiding server rendering for highly dynamic private UI that gains little from it.

Red flag: They say everything should be server-rendered or everything should be client-rendered.

Listen for: Senior candidates define signals first: Core Web Vitals, interaction responsiveness, bundle analysis, API timing, long tasks, and React Profiler traces. They prioritize changes such as route splitting, virtualization, server aggregation, caching, Suspense boundaries, and reducing third-party scripts. They also describe ownership, rollout, and regression prevention.

Red flag: They jump to one optimization technique without establishing where time is spent.

Listen for: Listen for layered handling: component-level validation, route-level error boundaries, Suspense fallbacks, API error normalization, retry policies, offline handling where needed, and correlation IDs in logs. Strong answers include user-friendly recovery actions, not leaking internals, and integrating telemetry without collecting sensitive data.

Red flag: They rely on a single top-level error boundary and generic toast messages.

Listen for: Strong answers cover semantic versioning, changelogs, visual regression tests, contract tests, Storybook, codemods for breaking changes, prerelease channels, and clear ownership. They also question whether every component belongs in the shared package and may separate stable primitives from product-specific composites.

Red flag: They solve it by freezing the package or requiring every consumer to update immediately.

Listen for: Look for explicit standards: TypeScript strictness, ESLint flat config, Prettier, testing guidelines, accessibility checks, component boundaries, and review checklists. Strong seniors automate formatting and simple rules, reserve review energy for design and risk, and coach through examples rather than personal preference.

Red flag: They rely on senior approval for every decision instead of building shared standards.

Listen for: Good answers include pairing on discovery, asking engineers to write small RFCs, exposing trade-offs, reviewing production incidents, and giving scoped ownership before larger decisions. Listen for feedback loops, psychological safety, and accountability. The strongest answers develop judgment rather than just handing out patterns.

Red flag: They equate mentoring with telling people exactly how to implement features.

Listen for: A strong design separates server state, streaming updates, and local UI state. Listen for WebSocket or SSE reconnection strategy, TanStack Query cache integration, virtualization for large tables, chart rendering costs, permission checks backed by the API, accessibility for alerts, and graceful degradation when real-time updates fail.

Red flag: They push every event into one global store and re-render the entire dashboard on each update.

Listen for: Look for tenant configuration loading, routing driven by capabilities, clear separation of branding tokens from logic, server-enforced authorization, and safe feature-flag evaluation. Strong answers address caching boundaries, avoiding tenant data leakage, testing representative tenant configs, and keeping bundle splitting compatible with optional modules.

Red flag: They treat tenant configuration as simple theme data and overlook authorization and isolation.

Listen for: Strong answers discuss package boundaries, ESM builds, peer dependencies for React 19, CSS strategy, tokens, tree shaking, SSR compatibility, accessibility, Storybook documentation, and release channels. They should consider how Server Components affect exported APIs and avoid components that assume browser-only globals at import time.

Red flag: They design components that only work in one app’s bundler and runtime assumptions.

Listen for: Listen for route-by-route migration, preserving user flows, moving suitable data fetching to server components or loaders, defining client boundaries for interactive islands, handling authentication and cookies, validating SEO needs, and monitoring hydration or caching issues. Strong answers keep rollback options and avoid rewriting everything at once.

Red flag: They propose migrating every route to Server Components before understanding product value or risk.

Listen for: A strong answer recognizes that React is the view layer, not the collaboration engine. Listen for CRDT or operational transform consideration, local persistence, sync status UI, presence throttling, conflict visualization, command-based editing, performance isolation from frequent cursor updates, and tests around reconnect and merge scenarios.

Red flag: They store the whole document in React state and broadcast it on every keystroke.