React Interview Questions and Answers

React interviews test whether you can build interactive UIs that stay correct as state and data change—not whether you memorized every API from 2018.

Theory rounds ask definitions—Virtual DOM, lifecycle in a hooks world, controlled inputs.

Coding rounds ask you to ship in 30–45 minutes:

Strong candidates think aloud, state assumptions, and write tests or edge-case handling when time allows.

Take-home UIs often include README trade-offs and test coverage—not only pixels.

Build one small app (dashboard, catalog, or admin table) you can demo and defend.

React is a JavaScript library for building user interfaces with a component-based model and declarative rendering—you describe UI as a function of state, React updates the DOM when state changes.

React is a library, not a full framework—you choose routing, data layer, and styling.

A strong answer is:

React lets teams compose UIs from components with predictable one-way data flow; I use it when rich client interactivity and a large ecosystem matter more than a batteries-included monolith framework.

JSX is syntax sugar that looks like HTML inside JavaScript. Build tools (Babel, SWC) transform it to React.createElement calls.

function Greeting({ name }) {
  return <h1>Hello, {name}</h1>;
}

Rules interviewers mention:

• One parent element or Fragment (<>...</>)
• className instead of class
• JavaScript expressions in {curly braces}
• Self-closing tags required (<img />)

JSX is not HTML—attributes and casing follow React conventions.

A strong answer is:

JSX is declarative syntax compiled to JavaScript function calls—it keeps UI structure readable while staying in the JavaScript type and tooling world.

React keeps a lightweight tree representing UI. On state change:

1. React calls your component functions to produce a new element tree
2. Diffs new tree vs previous (reconciliation)
3. Applies minimal DOM updates

Fiber (React 16+) enables incremental work, priorities, and concurrent rendering—reconciliation can pause and resume.

A strong answer is:

Virtual DOM is React's in-memory UI representation; reconciliation diffs trees and patches the real DOM—keys and component structure determine whether updates are efficient.

One-way data flow: parent state → child props → events call parent setters.

Anti-pattern: child mutates props object directly.

A strong answer is:

Props are inputs from parents; state is local mutable UI data updated immutably through setters—data flows down, events flow up.

// Controlled
const [email, setEmail] = useState("");
<input value={email} onChange={(e) => setEmail(e.target.value)} />

// Uncontrolled
const inputRef = useRef(null);
<input ref={inputRef} defaultValue="" />

Prefer controlled for validation, instant feedback, and predictable tests. Uncontrolled fits simple forms or file inputs.

A strong answer is:

Controlled inputs bind value to state for validation and single source of truth; uncontrolled defer to the DOM and refs when that is simpler.

useState returns [value, setter]. Updates are scheduled—React may batch multiple setters in one render.

const [count, setCount] = useState(0);

function increment() {
  setCount((c) => c + 1); // functional update — safe when next state depends on previous
}

State updates are asynchronous—do not assume count changes immediately after setCount.

A strong answer is:

useState stores local UI data; I use functional updates when the next value depends on the previous and remember setters batch for performance.

useEffect synchronizes your component with external systems—fetch, subscriptions, DOM APIs—not "lifecycle replacement" only.

useEffect(() => {
  const controller = new AbortController();
  fetch(url, { signal: controller.signal })
    .then((r) => r.json())
    .then(setData)
    .catch(handleError);
  return () => controller.abort(); // cleanup on dep change or unmount
}, [url]);

Prefer TanStack Query or framework data loaders over raw fetch effects for server data in 2026 interviews.

A strong answer is:

useEffect runs after paint to sync with externals—I declare honest dependencies, always clean up subscriptions and abort fetches, and reach for query libraries instead of hand-rolled fetch effects when data is server-backed.

1. Only call hooks at the top level — not inside loops, conditions, or nested functions
2. Only call hooks from React functions — components or custom hooks

Why: React relies on call order to associate state with each hook instance.

Breaking rules causes "Rendered more hooks than previous render" bugs—impossible to debug casually.

Custom hooks must also follow these rules and name with use prefix.

A strong answer is:

Hooks run in a fixed order every render—I never call them conditionally and I extract reusable logic into custom hooks instead of copying stateful patterns.

Helpful when:

• Passing callbacks to React.memo children that would re-render on reference change
• Heavy derived data (large list filtering) proven slow in profiler

Not needed for every inline function—memoization has memory cost.

const visible = useMemo(() => items.filter((i) => i.active), [items]);
const onSelect = useCallback((id) => setSelected(id), []);

Interview trap: wrapping everything in useCallback without memoized children buys nothing.

A strong answer is:

I use useMemo and useCallback when profiling shows wasted child renders or expensive derivations—not by default on every handler.

useRef holds a mutable box that persists across renders without triggering re-render when .current changes.

const inputRef = useRef(null);
useEffect(() => inputRef.current?.focus(), []);

Unlike state, updating ref.current does not schedule render.

A strong answer is:

useRef stores mutable values and DOM nodes across renders without causing re-renders—I use it for focus, timers, and escaping stale closure traps in effects.

Context shares values deep in the tree without prop drilling—theme, locale, auth snapshot.

Pattern:

const ThemeContext = createContext("light");

function App() {
  return (
    <ThemeContext.Provider value="dark">
      <Toolbar />
    </ThemeContext.Provider>
  );
}

For complex client state, consider Zustand, Redux Toolkit, or colocated state + query library.

A strong answer is:

Context is for stable global values like theme or auth—I avoid putting fast-changing data in context because it re-renders every consumer.

Custom hooks extract stateful logic reusable across components—they must follow Rules of Hooks.

Debounce logic (testable without React runtime):

function debounce(fn, delayMs) {
  let timer;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delayMs);
  };
}

let callCount = 0;
const debounced = debounce(() => { callCount += 1; }, 50);
debounced();
debounced();
debounced();
setTimeout(() => {
  console.log(callCount);
}, 100);

When you click Run, after a short wait you should see 1 printed once—multiple rapid calls collapse into one execution after the delay.

In React, pair debounced values with useEffect to drive API search—cleanup clears timeout on unmount.

A strong answer is:

Custom hooks share stateful behavior—I extract debounce, fetch, and media-query logic into use* functions so components stay declarative.

Colocation principle: keep state as low as possible until multiple distant components need it.

Server state is async, cached, and shared—different from client UI toggles. Do not copy server lists into Redux by default in 2026 greenfield apps.

A strong answer is:

Local state for UI, global client libraries only when prop drilling hurts, and dedicated server-state tools for API data with cache and invalidation.

const { data, isLoading, error } = useQuery({
  queryKey: ["orders", page],
  queryFn: () => fetchOrders(page),
});

Interviewers want you to mention query keys, stale-while-revalidate, and mutations with optimistic updates.

A strong answer is:

TanStack Query handles caching, deduplication, and refetch policies—I use effects for true externals like subscriptions, not routine GET requests.

Redux shines when:

• Many features read/write shared client state with traceable updates
• You need devtools, time-travel debugging, middleware
• Complex cross-feature workflows (multi-step wizards, offline sync)

Often overkill for apps where server state dominates—Query + light Context/Zustand covers many products.

Redux Toolkit reduces boilerplate with slices and createAsyncThunk—know it even if you prefer simpler stores.

A strong answer is:

I reach for Redux when client state is complex and many modules need predictable updates; otherwise Query plus minimal local/global state is enough.

When two siblings need the same data, move state to their common parent and pass props down + callbacks up.

Parent (owns `filter`)
       /      \
   List      FilterBar

Alternative: shared store or URL search params for bookmarkable filter state.

A strong answer is:

I lift state to the lowest common ancestor when siblings must stay in sync, or use URL/query state when users should share or bookmark it.

React favors composition—pass children or render props instead of deep class hierarchies.

function Card({ title, children }) {
  return (
    <section>
      <h2>{title}</h2>
      {children}
    </section>
  );
}

Patterns: compound components, slots, higher-order components (less common now), custom hooks (preferred reuse in hooks era).

A strong answer is:

I compose behavior with children and hooks rather than subclassing components—composition keeps trees flexible and types clearer.

React.memo wraps a component to skip re-render if props are shallow-equal to last render.

Requires stable props—inline object/function props defeat memo unless parent uses useMemo/useCallback.

Use when profiler shows expensive pure presentational children re-rendering often.

A strong answer is:

React.memo avoids re-rendering when props are unchanged—I pair it with stable callbacks only after profiling proves child render cost matters.

Keys help React identify which items changed, were added, or removed.

Wrong keys cause state bugs (wrong row stays checked) and inefficient DOM updates.

A strong answer is:

Keys must be stable per entity— I use database ids, not array indexes, for dynamic lists so React matches the right row across renders.

Common causes:

Tools: React DevTools Profiler, why-did-you-render (dev), logging render counts.

A strong answer is:

I profile first, then fix the actual source—unstable props, fat context, or state living too high—not blanket memo everywhere.

Code splitting loads JavaScript chunks on demand—smaller initial bundle.

const AdminPanel = lazy(() => import("./AdminPanel"));

function App() {
  return (
    <Suspense fallback={<Spinner />}>
      <AdminPanel />
    </Suspense>
  );
}

Route-based splitting (React Router, Next.js) is the most common production pattern.

A strong answer is:

I lazy-load heavy routes and admin surfaces behind Suspense so first paint ships only what most users need.

React Strict Mode intentionally double-invokes mounts, effects, and certain lifecycles in development to surface missing cleanup and side-effect bugs.

It does not run twice in production.

Your effect cleanup must abort fetches and clear timers—double invoke proves that works.

A strong answer is:

Strict Mode double-runs effects in dev on purpose—I write idempotent effects with proper cleanup so production and dev stay reliable.

React Router maps URL paths to component trees without full page reload.

Protect routes with auth wrappers—redirect unauthenticated users.

Pair with full stack interviews for end-to-end auth flows.

A strong answer is:

React Router keeps URL and UI in sync on the client—I use nested routes, loaders where appropriate, and guarded routes for auth.

Error boundaries catch render errors in child tree and show fallback UI—they must be class components (still in 2026) or framework equivalents.

They do not catch:

• Event handler errors (use try/catch)
• Async errors outside render
• Errors in the boundary itself

class ErrorBoundary extends React.Component {
  state = { hasError: false };
  static getDerivedStateFromError() { return { hasError: true }; }
  componentDidCatch(error, info) { log(error, info); }
  render() {
    return this.state.hasError ? <Fallback /> : this.props.children;
  }
}

A strong answer is:

Error boundaries isolate render failures so the whole app does not white-screen—I log to monitoring and still handle event and async errors separately.

Actions are async functions passed to <form action={submitAction}> that integrate pending and error state without manual preventDefault boilerplate.

Related APIs:

async function saveOrder(prevState, formData) {
  "use server"; // in Server Actions context (Next.js)
  // validate and persist
  return { ok: true };
}

Even without Next.js, interviewers expect you to know Actions reduce hand-rolled loading flags.

A strong answer is:

React 19 Actions standardize form submissions with built-in pending and error handling—I prefer them over manual useState toggles for mutations when the stack supports them.

React Testing Library encourages tests that resemble user behavior:

import { render, screen, fireEvent } from "@testing-library/react";

test("increments counter", () => {
  render(<Counter />);
  fireEvent.click(screen.getByRole("button", { name: /increment/i }));
  expect(screen.getByText("1")).toBeInTheDocument();
});

Test behavior and accessibility roles—not implementation details like internal state variable names.

A strong answer is:

I test what users see and do with Testing Library, mock APIs with MSW, and reserve E2E for critical flows like checkout or login.

React does not fix a11y automatically—see front end interviews for broader WCAG depth.

A strong answer is:

I use semantic elements, label every control, manage focus in dialogs, and test with keyboard and screen reader checks—not bolt-on ARIA only.

Concurrent rendering lets React interrupt low-priority updates to keep UI responsive.

const [isPending, startTransition] = useTransition();
startTransition(() => setFilter(text)); // keeps input snappy

A strong answer is:

Concurrent features prioritize urgent UI like typing over heavy re-renders—I use transitions and Suspense to keep interactions smooth under load.

Server Components run only on the server—they never ship component JavaScript to the browser.

Not the same as SSR: SSR still hydrates client components; RSC sends rendered output without hydrating that component code.

Popular in Next.js App Router—know the boundary interview answer even if your team uses Vite SPA.

A strong answer is:

Server Components render on the server to shrink bundles and access data directly; client components handle interactivity behind the use client boundary.

use() reads a Promise or Context during render—can be called conditionally (unlike other hooks).

Integrates with Suspense—component suspends until Promise resolves.

function Comments({ commentsPromise }) {
  const comments = use(commentsPromise);
  return comments.map((c) => <p key={c.id}>{c.text}</p>);
}

Prefer framework data patterns you can explain—RSC, Query, or use() with Suspense boundaries.

A strong answer is:

use() lets render read promises with Suspense—I use it where the framework supports streaming data, otherwise TanStack Query on the client.

Hydration mismatch is a common production bug—server HTML must match client first render.

A strong answer is:

I pick rendering mode by SEO, personalization, and interactivity—SSG/SSR for public content, CSR or hybrid for authenticated apps with heavy client state.

The React Compiler (rolling out with React 19 ecosystem) automatically memoizes components and values when safe—reducing manual useMemo/useCallback/memo.

Interview angle: compiler does not remove need to understand rendering—it optimizes proven patterns.

Teams enable gradually with lint rules and compatibility checks.

A strong answer is:

The React Compiler auto-memoizes where safe—I still understand render flow because compiler coverage is not universal overnight.

Options:

Do not reach for global state before trying composition and colocation.

A strong answer is:

I colocate state and compose children first; Context or a small store only when many distant components need the same client data.

Portals render children into a different DOM node—typically document.body for modals and tooltips.

createPortal(<Modal />, document.getElementById("modal-root"));

Event bubbling still follows React tree (not DOM tree)—important for delegation tests.

A strong answer is:

Portals render UI elsewhere in the DOM while keeping React event bubbling logical—essential for accessible modals and overlays.

React compares references to detect changes. Mutating arrays/objects in place may skip re-render or cause subtle bugs.

// Wrong — mutates
state.push(item);

// Right — new reference
setState([...state, item]);
setState({ ...state, count: state.count + 1 });

Immutability enables time-travel debugging and predictable memoization.

A strong answer is:

I always return new objects and arrays when updating state so React detects changes and memoization stays trustworthy.

React wraps browser events in SyntheticEvent for cross-browser normalization and event pooling (legacy optimization mostly irrelevant now).

Prefer controlled patterns over reading DOM after async without storing values.

A strong answer is:

Synthetic events normalize browser differences—I use controlled components and read values synchronously or from state, not stale events after await.

Expected features: add, toggle complete, filter (all/active/done), delete.

function todosReducer(state, action) {
  switch (action.type) {
    case "add":
      return [...state, { id: crypto.randomUUID(), text: action.text, done: false }];
    case "toggle":
      return state.map((t) => (t.id === action.id ? { ...t, done: !t.done } : t));
    default:
      return state;
  }
}

Mention useReducer when transitions multiply—shows structure for growing state machines.

A strong answer is:

I model todos as an immutable array with stable ids, use reducer or useState clearly, filter without mutating, and wire accessible controls—not a quick DOM hack.

Checklist:

1. Controlled input
2. Debounce query (300–400 ms)
3. AbortController cancel stale requests
4. Loading / error / empty UI states
5. Do not set state after unmount

useEffect(() => {
  if (!debouncedQuery) return;
  const controller = new AbortController();
  setLoading(true);
  fetch(`/api/search?q=${debouncedQuery}`, { signal: controller.signal })
    .then((r) => r.json())
    .then(setResults)
    .catch((e) => { if (e.name !== "AbortError") setError(e); })
    .finally(() => setLoading(false));
  return () => controller.abort();
}, [debouncedQuery]);

Senior mention: TanStack Query replaces most of this boilerplate with keepPreviousData and built-in cancellation patterns.

A strong answer is:

I debounce input, abort in-flight fetches on change, and render loading and error explicitly—or use TanStack Query if the stack allows.

Fix patterns:

• Narrow dependencies to primitives
• Functional updates: setItems((prev) => ...)
• Move object creation outside effect or memoize
• Do not derive state from state in effect when render can compute it

A strong answer is:

Infinite loops usually mean an effect writes state that retriggers itself—I fix dependency arrays, derive values in render instead of effects, and use functional updates.

Connect to front end performance topics (LCP, INP).

A strong answer is:

I profile renders and network, fix the biggest measurable bottleneck—usually data fetching or list rendering—and verify with metrics before micro-optimizing hooks.

Checklist:

• Explain Virtual DOM, keys, and one-way data flow
• useEffect deps, cleanup, Strict Mode double invoke
• useMemo/useCallback only with justification
• Server vs Client Components and when you would use each
• TanStack Query vs raw fetch
• Timed todo and debounced search coding reps
• Error boundaries and testing with RTL
• One performance and one production bug STAR story
• Front end fundamentals refresh
• Full stack integration if role is end-to-end

A strong answer is:

I rehearse hooks and coding exercises until they are muscle memory, then practice narrating trade-offs for data fetching and rendering like I would in a senior design review.