Interview Questions on React JS for Experienced Developers

What interviewers are testing: Whether you understand React's declarative state→UI model and what React provides versus what frameworks provide. React is a JavaScript library for building user interfaces with a component-based, declarative model—you describe UI as a function of state; React updates the DOM when state changes.

React is not a full framework—you choose routing, global state, and styling.

A strong answer is:

React is a component library for declarative UIs with predictable data flow—I use it when rich client interactivity and ecosystem depth matter.

What interviewers are testing: Whether you know JSX is syntax transformed into React element/runtime calls, not HTML executed by the browser. JSX embeds HTML-like syntax in 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.

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

Rules: one parent (or Fragment), className not class, expressions in {}, close all tags.

A strong answer is:

JSX is syntax sugar for readable component trees—it compiles to JavaScript and is not a separate language or browser feature.

What interviewers are testing: Whether you design reusable, composable UI boundaries rather than giant page components. A component is a function (or class) that returns UI. Function components are standard in 2026; hooks supply state and effects.

function Counter() {
  const [count, setCount] = React.useState(0);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

Components compose—pages are trees of smaller components.

A strong answer is:

A component is a reusable UI function with optional state—composition lets me build pages from small pieces instead of monolithic templates.

What interviewers are testing: Whether you understand parent-owned inputs, immutability, and one-way ownership. Props (properties) are read-only inputs from parent to child—one-way data flow.

function Avatar({ src, alt }) {
  return <img src={src} alt={alt} />;
}

Children can be passed as props.children. Props must not be mutated by the child.

A strong answer is:

Props flow down and are immutable in the child—I treat them as function arguments for UI rendering.

What interviewers are testing: Whether you know what data actually belongs in state versus derived values or external/server state.

Lift state up when siblings need to share it.

A strong answer is:

State is mutable local data that drives UI—when it changes, React re-renders; I lift state to the lowest common ancestor when siblings must share it.

What interviewers are testing: Whether you can choose between React-owned and DOM-owned form state based on behavior and integration needs.

Basic interviews favor controlled inputs—predictable, testable, easy validation.

A strong answer is:

Controlled components keep form state in React—I default to them for forms unless I need file inputs or third-party widgets that fight controlled mode.

What interviewers are testing: Whether you understand reconciliation and identity, not repeat "Virtual DOM makes React fast." React builds an in-memory element tree representing UI. On update, React reconciles the next UI tree with the previous one and commits the DOM mutations needed to make the rendered output match.

Fiber (React 16+) is React's reconciliation architecture—Fiber's architecture enables React to prioritize, pause, resume, or abandon render work used by concurrent features.

A strong answer is:

Virtual DOM is React's lightweight UI representation for efficient diffing—Fiber underneath enables priorities and concurrent features, not just a simple full-tree compare.

What interviewers are testing: Whether you understand that keys preserve component identity and state across list changes. Keys help React identify which items changed, were added, or removed—stable identity across renders.

{items.map((item) => <li key={item.id}>{item.name}</li>)}

A strong answer is:

Keys must be stable unique ids—not array index when the list can reorder or delete, or React reuses wrong component state.

What interviewers are testing: Whether you can trace data and events through a component tree without hidden mutation. Data flows down via props; events flow up via callbacks. Parents own shared state; children request changes through handlers.

This predictability simplifies debugging—trace props from root.

A strong answer is:

One-way flow means parents own state and pass callbacks—no child silently mutating parent data, which keeps large trees debuggable.

What interviewers are testing: Whether you can structure branching UI without creating unreadable render logic. Patterns:

{isLoggedIn ? <Dashboard /> : <Login />}
{error && <ErrorBanner message={error} />}
{items.length === 0 ? <Empty /> : <List items={items} />}

Prefer explicit branches for complex cases over nested ternaries.

A strong answer is:

I use ternary or short-circuit for simple cases and early returns or small subcomponents when conditional UI grows—readability beats clever one-liners.

What interviewers are testing: Whether you understand when an extra DOM wrapper would alter layout or semantics. Fragments group children without extra DOM nodes:

return (
  <>
    <Title />
    <Body />
  </>
);

Avoids wrapper <div> that breaks CSS layout or semantics.

A strong answer is:

Fragments let me return multiple siblings without a useless wrapper div that would break flex or grid layouts.

What interviewers are testing: Whether you know normal Hook rules and the documented exception for React's use API.

1. Call hooks only at the top level—not inside loops, conditions, or nested functions (for normal Hooks such as useState and useEffect)
2. Call hooks only from React function components or custom hooks

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

Exception: React's use API is different from normal Hooks: it may be called conditionally or in loops, but it still must be called from a component/Hook and cannot be wrapped in try/catch.

A strong answer is:

Normal Hooks such as useState and useEffect must run at the top level in a consistent order and only from React components or custom Hooks. The use API is a documented exception that can appear conditionally or in loops.

What interviewers are testing: Whether you understand render snapshots, queued updates, and functional updaters. useState returns [value, setter]. Updates schedule a re-render. Setters accept a value or functional updater prev => next.

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

  function incrementTwiceWrong() {
    setCount(count + 1);
    setCount(count + 1);
  }

  function incrementTwiceCorrect() {
    setCount(c => c + 1);
    setCount(c => c + 1);
  }

  return <button onClick={incrementTwiceCorrect}>{count}</button>;
}

Direct updates both use the current render's count; functional updates are applied in sequence. That teaches render snapshots—the value you read during a render is fixed until the next render.

A strong answer is:

useState queues re-renders on update—I use functional setState when the next value depends on the previous, especially in async or batched callbacks.

What interviewers are testing: Whether you use Effects to synchronize with external systems, rather than as a general "run code after render" tool. useEffect runs side effects after React commits an update—for fetch, subscriptions, and DOM sync.

useEffect(() => {
  document.title = `Count: ${count}`;
}, [count]);

Return a cleanup function for teardown.

A strong answer is:

useEffect is for synchronizing with external systems after render—I declare dependencies explicitly and return cleanup for subscriptions and abort controllers.

What interviewers are testing: Whether you can fix stale Effect closures with dependencies, functional updates, refs, or useEffectEvent. Effects close over values from the render when they were created. If dependencies are wrong, the effect sees old state/props.

Fix:

• Correct dependencies when the value should trigger resynchronization
• Functional updates when only previous state is needed
• useEffectEvent when Effect logic should read the latest committed value without making it reactive
• Refs for imperative/non-render state where appropriate

A strong answer is:

Stale closures happen when code captures an older render. I fix reactive dependencies properly, use functional state updates when the next value depends on previous state, and use useEffectEvent for non-reactive Effect logic that needs the latest committed values. Refs remain useful for imperative mutable state.

What interviewers are testing: Whether you memoize for measured benefit or precise control—not by default everywhere.

React Compiler is a separate build-time tool, not something built into React 19 automatically. It works best with React 19 but also supports React 17 and 18.

Do not wrap everything—memo has cost.

A strong answer is:

I memoize manually when I need precise control or profiling justifies it. Where React Compiler is enabled, I generally let the compiler handle routine memoization rather than adding useMemo and useCallback everywhere.

What interviewers are testing: Whether you distinguish mutable non-render state from UI-driving state. useRef holds a mutable box that persists across renders without causing re-render when .current changes.

Uses: DOM refs, timer ids, AbortController, latest value for callbacks.

A strong answer is:

useRef stores values that survive renders but shouldn't trigger them—DOM nodes, interval ids, or latest props for event handlers.

What interviewers are testing: Whether you can extract reusable stateful behavior without accidentally sharing state. Functions starting with use that compose built-in hooks—reusable stateful logic.

function useDebounce(value, delayMs) {
  const [debounced, setDebounced] = useState(value);
  useEffect(() => {
    const id = setTimeout(() => setDebounced(value), delayMs);
    return () => clearTimeout(id);
  }, [value, delayMs]);
  return debounced;
}

Custom hooks share logic, not state—each call gets isolated state.

A strong answer is:

Custom hooks extract reusable behavior—debounce, fetch, media query—without duplicating effect logic across components.

What interviewers are testing: Whether state complexity is driven by explicit transitions/actions rather than number of fields alone. useReducer suits complex state transitions with multiple actions—forms with many fields, wizards, state machines.

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

let state = [];
state = todosReducer(state, { type: "add", id: 1, text: "learn" });
state = todosReducer(state, { type: "toggle", id: 1 });
console.log(state[0].done);

Running prints true—immutable updates in the reducer keep state predictable.

A strong answer is:

useReducer when next state depends on action type and prior state in non-trivial ways—todo apps, multi-step flows—not for a single boolean toggle.

What interviewers are testing: Whether you place shared state at the lowest common ancestor without duplicating sources of truth. Move shared state to the closest common ancestor of components that need it; pass data and callbacks down.

Avoids duplicate sources of truth and sync bugs between siblings.

A strong answer is:

I lift state to the parent that owns the shared truth—two siblings editing the same filter share one state object and callbacks, not duplicated useState.

What interviewers are testing: Whether you can avoid both prop-drilling dogma and global-context re-render problems. Context passes data through the tree without prop drilling—theme, locale, auth session.

Split contexts by update frequency when needed.

A strong answer is:

Context for rarely changing cross-cutting data—I split contexts or use selectors/stores when updates are frequent to avoid re-rendering the whole tree.

What interviewers are testing: Whether you understand Fiber as React's internal work/reconciliation architecture, not an API developers manipulate. Fiber is React's reconciliation engine—each unit of work is a fiber node representing a component instance.

Enables:

• Incremental rendering — pause and resume
• Priorities — urgent updates (input) before transitions
• Concurrent features — useTransition, useDeferredValue

Fiber is the reconciler/work architecture for interruptible render work, prioritization, scheduling, and reconciliation units. Use useEffect documentation when discussing effect timing—not Fiber directly.

A strong answer is:

Fiber is the work unit for reconciliation—it enables concurrent rendering and priority scheduling for interruptible updates.

What interviewers are testing: Whether you distinguish interruptible scheduling from parallel JavaScript execution. React can start, pause, and abandon renders to keep UI responsive. useTransition marks non-urgent updates; useDeferredValue lags behind fast-changing input.

const deferredQuery = useDeferredValue(query);

const filtered = useMemo(
  () => hugeFilter(deferredQuery),
  [deferredQuery]
);

startTransition marks a state update as non-urgent, but synchronous work inside the callback—such as hugeFilter(query)—can still block the main thread. For expensive filtering, defer the input value and memoize, or move heavy computation to a Web Worker or a better data strategy.

Not the same as async/await—it's scheduling, not parallelism.

A strong answer is:

Concurrent rendering keeps typing responsive while heavy filters catch up—I use transitions for non-urgent UI updates, not as a replacement for proper data fetching architecture.

What interviewers are testing: Whether you can decide what belongs on the server versus the client boundary. Server Components render ahead of time in a server/build environment and their component code is not sent to the browser. They can access server-side data sources directly when the framework/runtime environment permits it.

Frameworks like Next.js App Router compose both in one tree.

A strong answer is:

RSC moves data-heavy, non-interactive UI to the server—client components handle interactivity; I don't put useEffect fetch on server components.

What interviewers are testing: Whether you understand React's mutation/action lifecycle, not just a replacement syntax for fetch. Actions are functions executed in React's transition/action lifecycle and may perform side effects. React DOM integrates Actions particularly well with forms. useActionState tracks the resulting state and pending status.

const [state, formAction, isPending] = useActionState(saveUser, null);
// <form action={formAction}>...</form>

useFormStatus lets child buttons read parent form pending state without prop drilling.

Known/validation errors may be returned as state; thrown errors can be handled by an Error Boundary.

A strong answer is:

Actions integrate mutations with React's transition lifecycle. I use useActionState when I need mutation result and pending state, especially for forms; expected validation errors can be returned as state and unexpected failures can surface through an Error Boundary.

What interviewers are testing: Whether you understand optimistic UI as temporary presentation while authoritative state settles. useOptimistic temporarily presents the anticipated state while an Action is pending. After the underlying state/action settles, the UI resolves back to the authoritative state. Error presentation and retry UX are still your responsibility.

A strong answer is:

useOptimistic gives first-class optimistic UI while an Action is pending—the authoritative state still wins, so I still handle failure and retry explicitly.

What interviewers are testing: Whether you distinguish server-state lifecycle/caching from generic Effects and client state.

For reusable server-state fetching, caching, invalidation, retries, and deduplication, use a framework data layer or client cache such as TanStack Query. Direct Effect-based fetching remains valid for client-only cases, but you must handle races, cancellation, caching, and lifecycle yourself. Framework loaders/RSC may remove the need for either in many routes.

A strong answer is:

I avoid treating server data as ordinary component Effects when a framework loader, RSC data layer, or Query cache already owns that lifecycle. For client-side server state, TanStack Query gives caching, invalidation, dedupe, and retry semantics I would otherwise rebuild.

What interviewers are testing: Whether you know which failures they isolate and which they do not. Class components (or library wrappers) implementing getDerivedStateFromError / componentDidCatch catch render errors in children—show fallback UI instead of white screen.

Traditional Error Boundaries catch errors thrown while rendering descendant React trees and in lifecycle methods. They do not automatically catch arbitrary errors thrown from event handlers or unrelated asynchronous callbacks. Server/framework error handling has its own boundary semantics.

A strong answer is:

Error boundaries isolate render failures per route or widget—I pair them with route-level fallbacks and logging, not try/catch around every onClick.

What interviewers are testing: Whether tests verify observable behavior/accessibility rather than implementation details. React Testing Library — test behavior users see, not implementation details.

A strong answer is:

I test what users see—roles, labels, outcomes—not component state or hook call counts, so refactors don't break tests unnecessarily.

What interviewers are testing: Whether you measure and split expensive delivery boundaries before micro-optimizing rendering.

Measure with webpack/vite analyzer before micro-optimizing hooks.

A strong answer is:

I split by route and heavy widgets first—lazy charts and admin pages—then analyze bundle; memoization is not a substitute for code splitting.

What interviewers are testing: Whether you understand why development Strict Mode stress-tests Effects and rendering. In development, Strict Mode intentionally performs extra render checks and runs an additional Effect setup → cleanup → setup cycle to expose impure rendering and missing cleanup.

In production, Effects run according to their dependencies—after initial commit, again when dependencies change, with cleanup before the next setup and on unmount. Development Strict Mode additionally performs an extra setup/cleanup/setup cycle on initial mount to expose missing cleanup and non-idempotent logic.

A strong answer is:

Strict Mode double effects in dev expose missing cleanup—I write idempotent effects with teardown, not hacks to disable Strict Mode.

What interviewers are testing: Whether you understand that initial server/client output must be deterministic. Hydration attaches client React to server-rendered HTML. Mismatch when server HTML ≠ client first render—causes warnings and broken UI.

Common causes: Date.now(), Math.random(), browser-only APIs in SSR, invalid HTML nesting.

A strong answer is:

Hydration requires server and client first paint to match—I gate browser-only values behind useEffect or suppress only when truly unavoidable with clear comments.

What interviewers are testing: Whether you can identify an Effect that updates state which changes one of its own dependencies, or a dependency whose identity changes every render.

Symptoms: Browser tab hangs; Network tab shows repeated identical requests.

Walkthrough: Open component → find useEffect → check dependency array → check if setState inside always runs → move derivation to render or narrow deps.

A strong answer is:

I find the effect writing state that retriggers itself—fix deps, use functional updates, or compute during render instead of syncing state in an effect.

What interviewers are testing: Whether you can stop request storms with debounce, cancellation, and appropriate client/server data tooling.

Diagnosis: No debounce; possibly no request cancellation.

Fix stack:

1. Debounce input—for example 250–400 ms depending on UX/query cost (useDebounce custom hook)
2. AbortController in effect cleanup
3. useTransition if filtering large local lists (keeps expensive React updates non-urgent—it does not debounce API calls)
4. TanStack Query with enabled: debouncedQuery.length > 0

function debounce(fn, ms) {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), ms);
  };
}
let calls = 0;
const search = debounce(() => { calls += 1; }, 100);
search(); search(); search();
setTimeout(() => console.log(calls), 150);

After ~150 ms, calls is 1—only the trailing keystroke fired.

A strong answer is:

Debounce the query, abort stale fetches, show loading state—or use Query with debounced key; I'd never fire raw onChange directly to the API.

What interviewers are testing: Whether you can diagnose memo failures from changing context values or unstable prop references. Checklist:

Fix: useCallback/useMemo only after profiling, move state down, split context, or pass primitive props.

A strong answer is:

Unstable callback or object props break memo—I stabilize with useCallback when profiling proves it, or colocate state so the child isn't under a hot parent.

What interviewers are testing: Whether you profile network, render, and interaction bottlenecks before sprinkling memoization.

Prioritize user-visible wins before hook micro-optimization.

A strong answer is:

Profiler plus network first—I fix overfetch and unvirtualized lists before sprinkling useMemo; verify with Core Web Vitals, not gut feel.

What interviewers are testing: Whether you design auth bootstrap, protected routes, and session handling without flash or token exposure. Approach:

• Auth context or lightweight store with { user, status: 'loading' | 'authenticated' | 'anonymous' }
• Bootstrap — single /me fetch on app load; avoid flash of wrong route
• Protected route — render skeleton while loading; redirect only when status known
• Token storage — for browser-based sessions, HttpOnly, Secure, appropriately configured SameSite cookies reduce token exposure to JavaScript, but cookie-based authentication also requires an explicit CSRF strategy where applicable
• Refresh — handle session expiry/refresh according to the backend authentication model

Mention coordination with full stack API auth patterns.

A strong answer is:

Loading gate before redirect, single source of auth truth, httpOnly cookies when backend allows—I never redirect unauthenticated users before bootstrap finishes.

What interviewers are testing: Whether you structure multi-step form state with one source of truth and step validation. Options:

Keep one source of truth; validate per step; persist draft to sessionStorage if UX requires.

A strong answer is:

useReducer or RHF with schema validation—one state machine for steps, persist optional draft, disable Next until step valid.

What interviewers are testing: Whether you migrate classes to hooks by responsibility—not by mechanical lifecycle-to-Effect mapping.

Do not big-bang rewrite—strangle by route or feature flag.

A strong answer is:

I migrate leaf components behind behavior tests, but I don't mechanically translate lifecycle methods into Effects. I separate render derivation, user events, and true external synchronization, then extract reusable behavior into custom Hooks.

What interviewers are testing: Whether you know what senior reviewers evaluate in a take-home beyond feature completeness.

Over-engineering Redux for three fields scores poorly.

A strong answer is:

I ship clear README trade-offs, loading/error paths, a few meaningful tests, and accessible forms—polish on architecture judgment, not animation libraries on day one.

What interviewers are testing: Whether you place Suspense boundaries only around integrations that actually suspend.

A Suspense boundary only helps for code/data sources integrated with Suspense; wrapping arbitrary useEffect fetching in <Suspense> does not make it suspend.

A strong answer is:

I use granular Suspense boundaries so one slow chart does not blank the entire dashboard, and I keep filters/chrome outside the suspended regions.

What interviewers are testing: Whether you can separate reactive Effect dependencies from non-reactive logic using useEffectEvent. useEffectEvent lets Effect logic read the latest committed props/state without making those values reactive dependencies.

const onConnected = useEffectEvent(() => {
  showNotification('Connected', theme);
});

useEffect(() => {
  const connection = createConnection(roomId);
  connection.on('connected', onConnected);
  connection.connect();

  return () => connection.disconnect();
}, [roomId]);

A strong answer is:

I keep values that should resynchronize the Effect in its dependency list. For non-reactive Effect logic that needs the latest committed values, React 19.2's useEffectEvent lets me read them without restarting the subscription.

What interviewers are testing: Whether you can profile interaction delay and distinguish rendering, JS, and layout bottlenecks.

A strong answer is:

I profile the exact interaction, identify the long task—rendering, JavaScript, layout, parsing, or event-handler work—and remove or chunk the bottleneck. I use transitions only when the delay comes from non-urgent React rendering; CPU-heavy work may need chunking or a Web Worker.

What interviewers are testing: Whether you migrate toward RSC through framework-supported incremental slices.

A strong answer is:

I first choose a framework architecture that supports Server Components. Then I migrate read-heavy, server-safe surfaces incrementally, keep interactive islands client-side, and measure client-JS/hydration improvements rather than attempting a whole-SPA rewrite.

What interviewers are testing: Whether you know when React Compiler handles memoization and when manual memo remains appropriate.

A strong answer is:

I rely on the React Compiler where enabled, but I still understand manual memo for uncompiled code, unstable library boundaries, and profiler-proven hot paths.