React Interview Questions and Answers

What interviewers are testing: Whether you understand React's declarative, component-based model and can explain what React provides versus what a framework such as Next.js adds.

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.

What interviewers are testing: Whether you can explain JSX as compile-time syntax sugar, automatic vs classic transforms, and why it is not HTML.

JSX is syntax sugar that looks like HTML inside JavaScript. Build tools transform it into JavaScript calls understood by the React JSX runtime. Older tooling used explicit React.createElement() calls; modern projects normally use the automatic JSX transform, so importing React solely for createElement is no longer required.

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.

What interviewers are testing: Whether you can explain reconciliation and Fiber without overstating React as always computing the smallest possible DOM patch set.

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. React reconciles the new element tree against the previous tree and commits the necessary host/DOM changes

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

A strong answer is:

React builds a new element tree each render, reconciles it against the previous tree, and commits the necessary DOM changes—keys and structure determine whether list updates stay efficient.

What interviewers are testing: whether you treat props as read-only parent input and state as component-owned data that triggers re-renders.

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.

What interviewers are testing: whether you choose controlled inputs when React must own form state and uncontrolled refs for simple file or legacy integrations.

// 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.

What interviewers are testing: Whether you understand state as a render snapshot, batching, and when functional updates are required.

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
}

Calling the setter schedules another render; it does not change the state variable captured by the currently executing render.

A strong answer is:

useState gives each render a snapshot of local state. I use functional updates when the next state depends on the previous value, especially when updates may be batched.

What interviewers are testing: whether you model effect dependencies, cleanup, and stale-closure pitfalls—not just when effects run.

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((error) => {
      if (error.name !== "AbortError") {
        handleError(error);
      }
    });
  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. In React 19.2, useEffectEvent separates event-like logic inside Effects from reactive dependencies—useful when an Effect should see the latest values without re-synchronizing for those values. Do not use it merely to silence dependency lint errors. Effect Events can only be called from Effects or other Effect Events—do not pass them to child components or call them from regular event handlers.

A strong answer is:

useEffect runs after React commits the update. I declare honest dependencies, clean up subscriptions and abort fetches, and use useEffectEvent in React 19.2 when Effect-triggered logic needs the latest props/state without becoming a dependency. I reach for query libraries instead of hand-rolled fetch effects when data is server-backed.

What interviewers are testing: Whether you know why hook call order matters and when the React 19 use() API is an exception.

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.

React 19 exception: use() is a React API rather than a normal Hook. It may be called conditionally or in loops, although it still must be called while React renders a component or Hook.

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 except for use(), which React documents as a special API, and I extract reusable logic into custom hooks instead of copying stateful patterns.

What interviewers are testing: Whether you justify memoization with measured re-render cost—not blanket useCallback on every handler.

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—manual memoization has complexity and runtime overhead of its own, so it should solve an actual identity or computation problem.

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.

The React Compiler can automatically memoize values, functions, and components where safe, reducing routine manual useMemo/useCallback/memo. Understand them anyway because existing codebases and library boundaries still rely on them—do not mechanically add manual memoization when the compiler/toolchain already handles it.

A strong answer is:

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

What interviewers are testing: Whether you distinguish mutable non-rendering state from UI state and know when refs are appropriate for DOM access or imperative integration.

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:

I use refs for DOM nodes and mutable values that should survive renders without causing a render. If the value belongs in visible UI, it should normally be state instead.

What interviewers are testing: Whether you know when Context subscriptions become too broad and how to split or memoize provider values.

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:

A provider value change updates components subscribed to that context, so I avoid one large frequently changing context and split concerns when needed.

What interviewers are testing: Whether you can implement a real custom Hook—not only a standalone debounce utility—and explain how it composes with effects.

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

function useDebounce(value, delay) {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const timer = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    return () => clearTimeout(timer);
  }, [value, delay]);

  return debouncedValue;
}

// Usage
const debouncedQuery = useDebounce(query, 300);

Pair debounced values with fetch effects or query libraries—cleanup clears the timeout on unmount or when value changes.

A strong answer is:

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

What interviewers are testing: whether you keep UI state local, lift only when siblings need it, and put server cache in TanStack Query—not Redux by default.

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.

What interviewers are testing: Whether you justify TanStack Query for server-state caching and when raw useEffect fetch is still appropriate.

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. TanStack Query is not mandatory for every fetch—the decision depends on server-state complexity and framework architecture.

A strong answer is:

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

What interviewers are testing: Whether you know when shared client state complexity justifies Redux Toolkit over lighter stores and query libraries.

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.

What interviewers are testing: Whether you know when to lift shared state to a common ancestor versus URL or store patterns.

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.

What interviewers are testing: Whether you favor composition—children, render props, and hooks—over class inheritance for reuse.

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.

What interviewers are testing: Whether you understand prop comparison and can justify memoization based on measured render cost rather than applying it everywhere.

React.memo wraps a component to skip re-render when each prop compares equal to its previous value using Object.is, unless a custom comparator is supplied.

memo only optimizes re-renders caused by unchanged parent props; the component still renders when its own state or a Context it consumes changes.

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 skips re-render when props are unchanged by Object.is—I pair it with stable callbacks only after profiling proves child render cost matters.

What interviewers are testing: whether you use stable unique keys so React reconciles lists without remounting or state loss.

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 key must be stable and unique among its siblings—it does not need to be globally unique across the application.

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.

What interviewers are testing: Whether you can trace re-render causes to state placement, context, and unstable identities at memo or effect boundaries.

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.

What interviewers are testing: Whether you understand bundle splitting with lazy() and when the lazy component is actually rendered—not only how to import it.

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

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

function App() {
  const [showAdmin, setShowAdmin] = useState(false);

  return (
  <>
    <button onClick={() => setShowAdmin(true)}>Open admin</button>
    {showAdmin && (
      <Suspense fallback={<Spinner />}>
        <AdminPanel />
      </Suspense>
    )}
  </>
  );
}

lazy() splits the component into another bundle; actual deferral depends on when that lazy component is rendered. 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.

What interviewers are testing: Whether you know Strict Mode's development-only extra Effect cycle at mount and why cleanup must be correct.

React Strict Mode in development intentionally stress-tests components and effects:

• components re-render an extra time in development
• In development Strict Mode, React runs an extra setup→cleanup→setup cycle when an Effect mounts to expose missing cleanup bugs
• ref callbacks are re-run with an extra setup/cleanup cycle in development

These extra checks are development-only. Normal production effects still rerun whenever their dependencies change.

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

A strong answer is:

Strict Mode stress-tests effects and cleanup in dev on purpose—I write idempotent effects with proper cleanup so production behavior stays reliable when dependencies change.

What interviewers are testing: Whether you can explain client-side routing, nested routes, and route-level data loading in modern React Router.

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

Use route guards or loaders to redirect unauthenticated users for UX, but enforce authentication and authorization again on the server/API—the client-side route guard is not a security boundary.

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.

What interviewers are testing: Whether you know what error boundaries catch in render—and what they do not catch in events or async code.

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.

What interviewers are testing: Whether you understand how Actions integrate async mutations with transitions—not automatic error handling for every thrown failure.

Actions are async functions passed to <form action={submitAction}> that integrate async updates with React's transition model.

Related APIs:

function OrderForm() {
  const [state, submitAction, isPending] = useActionState(saveOrder, {
    ok: false,
  });

  return (
    <form action={submitAction}>
      {/* fields */}
      <button disabled={isPending}>Save</button>
    </form>
  );
}

async function saveOrder(prevState, formData) {
  // validate and persist
  return { ok: true };
}

A function passed directly to <form action={saveOrder}> receives formData as its single argument—the (prevState, formData) signature is for actions wired through useActionState.

Actions integrate async mutations with React's transition model. useActionState can expose action result state and pending status, useFormStatus exposes form submission status, and useOptimistic supports optimistic UI. Thrown errors still interact with error handling and boundaries.

React Actions are the broader React form/action model. "use server" belongs to frameworks/environments that support Server Functions (for example Next.js); it is not required for every React Action.

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

A strong answer is:

React 19 Actions integrate async mutations with forms and transitions, reducing hand-rolled pending-state orchestration. I use useActionState, useFormStatus, and useOptimistic where they simplify the mutation flow.

What interviewers are testing: Whether you understand visible vs hidden UI modes, preserved state, Effect lifecycle, and update prioritization—not as a generic layout wrapper.

<Activity /> (React 19.2) controls whether a subtree is visible or hidden:

Useful for preserving navigation or tab state, pre-rendering likely next UI, or keeping expensive subtrees warm without treating them as actively visible.

A strong answer is:

<Activity /> lets me hide UI while preserving state—hidden mode unmounts Effects and deprioritizes updates, which is useful for tabs or pre-rendered panels without losing user progress.

What interviewers are testing: Whether you test behavior through accessible queries and realistic user interactions—not implementation details.

React Testing Library encourages tests that resemble user behavior:

import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";

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

Use fireEvent only when you need lower-level event dispatch.

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.

What interviewers are testing: Whether you prioritize semantics, labels, keyboard behavior, and focus management—not ARIA alone.

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.

What interviewers are testing: Whether you understand urgent vs non-urgent updates and do not put controlled text input values inside transitions.

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

const [text, setText] = useState("");
const [filter, setFilter] = useState("");
const [, startTransition] = useTransition();

function handleChange(e) {
  const next = e.target.value;
  setText(next); // urgent: controls input
  startTransition(() => {
    setFilter(next); // non-urgent: expensive results
  });
}

Transitions cannot control text inputs—keep the input value in urgent state and transition downstream work.

A strong answer is:

Concurrent features prioritize urgent UI like typing over heavy re-renders—I keep controlled inputs urgent and use transitions or useDeferredValue for expensive downstream updates.

What interviewers are testing: Whether you understand the server/client boundary and that Client Components in the tree still ship JavaScript.

Server Components run only on the server—their implementation does not ship to the browser.

Not the same as SSR: SSR still hydrates client components; RSC sends rendered output without hydrating Server 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 Component code stays on the server and can access server-side data directly; interactive islands cross the boundary into Client Components and ship their own JavaScript.

What interviewers are testing: Whether you know use() is not a Hook, can be conditional, and works with framework-created Suspense-compatible Promises.

use() reads a Promise or Context during render—despite its name, it is not a Hook and 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>);
}

In Client Components, do not create a new uncached Promise during render and immediately pass it to use()—framework/server-created or cached Suspense-compatible Promises are the usual pattern. use(context) can be conditional, but current React docs state reading context with use(context) is not supported in Server Components.

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

A strong answer is:

use() is a React API that reads promises or context during render with Suspense—it can be conditional unlike Hooks, but I rely on framework-created promises rather than ad hoc render-time fetches.

What interviewers are testing: whether you pick SSR for SEO and first paint, CSR for highly interactive apps, and SSG for mostly static content.

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.

What interviewers are testing: Whether you understand what React Compiler 1.0 automates and why manual memoization knowledge still matters.

The React Compiler reached 1.0 in October 2025 and 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 identity and dependencies because compilation can be incrementally adopted, and existing uncompiled code still uses the same React semantics.

What interviewers are testing: Whether you try composition and colocation before reaching for Context or a global store.

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.

What interviewers are testing: Whether you know portals escape DOM layout constraints while remaining in the same React tree.

Portals render children into a different DOM node—typically document.body for modals and tooltips. They are common for modals and overlays because they can escape DOM layout/stacking constraints while remaining in the same React tree; accessibility still requires correct dialog semantics and focus management.

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—they escape layout and stacking constraints, but accessibility still requires correct dialog semantics and focus management.

What interviewers are testing: Whether you treat state as an immutable snapshot and understand why mutation breaks reconciliation and memoization.

React state should be treated as an immutable snapshot. Mutating an existing object and passing the same reference back can prevent an expected update and also breaks assumptions used by memoization and concurrent rendering.

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

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

A strong answer is:

I treat state as an immutable snapshot and create new objects or arrays for updates. Mutating old state can break update detection, memoization, and assumptions used by concurrent rendering.

What interviewers are testing: Whether you understand React's event abstraction, root-level delegation, and how modern SyntheticEvents differ from the old pooled-event model.

React wraps browser events in SyntheticEvent for cross-browser normalization.

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

A strong answer is:

SyntheticEvent gives React a consistent event interface while preserving browser event access through nativeEvent. In modern React DOM, event objects are no longer pooled; I mainly care about propagation, default prevention, and React's delegated event model.

What interviewers are testing: Whether you can structure state, keys, immutability, and accessibility for a small list feature under time pressure.

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.

What interviewers are testing: Whether you can debounce input, abort stale requests, and avoid loading/error races—not only set state after unmount.

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 or after a superseded request

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

Senior mention: A server-state library can centralize query caching, cancellation signals, previous-data behavior, retries, and request status.

A strong answer is:

I debounce input, abort in-flight fetches on change, guard loading state against aborted requests, and render loading and error explicitly—or use a query library if the stack allows.

What interviewers are testing: Whether you can diagnose self-triggering effects from dependency arrays and unstable identities.

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.

What interviewers are testing: Whether you start from user-visible impact and classify the bottleneck before jumping to React Profiler—rendering is only one possible cause.

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

A strong answer is:

I reproduce the symptom, check real-user metrics and network first, then profile renders if UI work is implicated—I fix the biggest measurable bottleneck before micro-optimizing hooks.