React Interview Questions and Answers

React is a JavaScript library for building user interfaces from small reusable components. You describe what the UI should look like for a given state. When the state changes, React updates the DOM efficiently.

Why teams use it:

• Declarative, component-based code that is easy to reason about and reuse.
• A virtual DOM and reconciliation that avoid manual DOM updates.
• One-way data flow, which makes bugs easier to trace.
• A large ecosystem (routing, data fetching, testing) and frameworks like Next.js on top.
• The same model for web and mobile (React Native).

React is a library, not a full framework: routing, data fetching and build setup come from other tools.

What they are checking: Whether you can state the core idea beyond 'it is fast'

The virtual DOM is a lightweight JavaScript representation of the UI. When state changes, React renders a new tree and compares it with the previous one (diffing). Then it applies only the needed changes to the real DOM.

The diffing rules keep it linear in cost:

• Elements of different types are replaced, and their subtrees are rebuilt.
• Same type: update only changed attributes and recurse into children.
• Lists use key to match old and new children.

It is not magic speed: the real benefit is a declarative model with batched, minimal DOM updates. React's Fiber architecture splits rendering into units of work, which allows concurrent features like transitions and Suspense.

What they are checking: Whether you understand diffing and the role of keys

Props are inputs passed from a parent to a child; they are read-only inside the child. State is data a component owns and can change over time, and changing it triggers a re-render.

• Data flows down through props; events flow up through callback props.
• Do not copy props into state without a reason. The copy can become out of date.
• If two components need the same state, lift it to their closest common parent.

What they are checking: Whether you understand one-way data flow

useState(initial) returns [value, setValue]. Calling the setter schedules a re-render with the new value. State is kept between renders by React, per component instance.

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

// wrong when updating multiple times from the same value
setCount(count + 1);
setCount(count + 1);   // still +1 in total

// right: derive from the latest state
setCount(c => c + 1);
setCount(c => c + 1);  // +2

Other points:

• Updates are batched and asynchronous; the variable keeps its old value in the current render.
• Never change objects or arrays directly: create new ones (setItems([...items, x])).
• Pass a function for expensive initial values: useState(() => compute()).
• Setting the same value (by Object.is) bails out.

What they are checking: Whether you know about batching and out-of-date values

useEffect runs side effects (fetching, subscriptions, timers, DOM work) after React commits a render.

• No array: runs after every render.
• []: runs once after mount (twice in development with Strict Mode).
• [a, b]: runs after mount and whenever a or b change.
• The returned function is cleanup. It runs before the next effect and on unmount.

useEffect(() => {
  const id = setInterval(() => setSeconds(s => s + 1), 1000);
  return () => clearInterval(id);
}, []);

List every reactive value you use in the array (the lint rule react-hooks/exhaustive-deps helps). Do not use effects for things you can compute during render or in event handlers.

What they are checking: Whether you handle cleanup and dependencies correctly

Keys let React match items between renders. So it can reorder, add or remove the right elements and keep their state.

{todos.map(t => <TodoItem key={t.id} todo={t} />)}

Index keys are fine for static lists that never reorder. If items can be inserted, deleted or sorted, an index key makes React reuse the wrong component instance. This causes wrong input values, lost focus or old state.

Rules for keys:

• Unique among siblings, stable, and not generated during render (Math.random() forces a remount every time).
• Use a database id or a stable unique field.
• Changing a component's key deliberately resets its state.

What they are checking: Whether you understand identity in reconciliation

JSX is a syntax extension that lets you write HTML-like markup inside JavaScript. A compiler (Babel, SWC, TypeScript) turns it into function calls (jsx()), producing React elements.

useRef(initial) returns a mutable object { current } that stays the same across renders. Changing ref.current does not cause a re-render.

Uses:

• Access a DOM node: <input ref={inputRef} /> then inputRef.current.focus().
• Store values that should not trigger renders (timer ids, previous value, mutable flags).

Context lets you pass data through the component tree without passing props at every level (avoiding prop drilling). Use it for things like theme, locale or the current user.

In a controlled component, React state is the single source of truth for the input value. In an uncontrolled one, the DOM holds the value. You read it with a ref or on submit.

React.memo(Component) skips re-rendering a component when its props are shallowly equal to the previous props.

Two rules:

1. Call hooks only at the top level of a component or custom hook: never inside loops, conditions or nested functions.
2. Call hooks only from React function components or other hooks.

A custom hook is a function whose name starts with use and that calls other hooks. It lets components reuse stateful logic. Each call gets its own independent state.

React detects changes by comparing references. If you change an object or array directly and pass the same reference to the setter, React sees no change. Memoised children skip updates too, so the UI does not update correctly.

When two or more components need the same changing data, move the state to their closest common parent. Pass it down as props (plus callbacks to update it).

Prop drilling is passing props through several middle components that do not use them, just to reach a deep child. It makes code brittle and noisy.

<StrictMode> is a development-only wrapper that highlights problems. In development it renders components twice. Since React 18, it also mounts, unmounts and remounts each component once, to check that effects clean up properly. It has no effect in production.

Class components use this.state, setState and lifecycle methods. Function components with hooks do the same with less code and easier logic reuse. New code uses function components; classes remain for error boundaries.

Keep the remaining seconds and a running flag in state. Run a setInterval inside useEffect and clear it on cleanup. Use the functional form of the state setter so the interval never reads an old value.

A Fragment lets a component return several elements without adding an extra DOM node: <>...</> or <Fragment key={id}> when a key is needed.

A Portal renders children into a different DOM node outside the parent's hierarchy. React tree rules still apply: context and event bubbling follow the React tree.

Synthetic events are React's cross-browser wrapper around native DOM events. They expose the same interface (target, preventDefault(), stopPropagation()) in every browser.

Both memoise a value between renders and only recompute when dependencies change.

• useMemo(() => compute(a, b), [a, b]) caches a computed value.
• useCallback(fn, [deps]) caches a function; it equals useMemo(() => fn, [deps]).

const sorted = useMemo(() => items.slice().sort(cmp), [items]);
const onSelect = useCallback((id) => setSelected(id), []);

Use them when:

• A calculation is genuinely expensive.
• You pass a function or object to a React.memo child, or use it as a hook dependency, and need a stable reference.

Do not wrap everything: memoisation costs memory and comparison time. Measure with the Profiler first. The React Compiler can add much of this automatically.

What they are checking: Whether you know they are for referential stability and cost, not default habits

A component re-renders when its state changes. It also re-renders when its parent re-renders (even with the same props), or when a context it uses changes.

Ways to reduce it, roughly in order of preference:

1. Move state down, closer to where it is used, so fewer components sit under the changing state.
2. Pass expensive parts as children or props (composition), so they keep the same element identity.
3. Split contexts, or use a store with selectors.
4. Use React.memo on heavy children, with stable props through useMemo and useCallback.
5. Virtualise long lists, and use useDeferredValue or transitions for expensive updates.

Measure first with React DevTools Profiler ("why did this render") rather than guessing. A re-render alone is cheap; the problem is slow work during it.

What they are checking: Whether you diagnose before optimising

Context is a delivery mechanism for a value, not a state manager. Redux (and Zustand, Jotai) provide a store, update patterns and selective subscriptions.

Use Context for low-frequency, app-wide values: theme, locale, auth user, feature flags.

Server Components render only on the server (at build time or per request). They send serialised output to the browser, with no component JavaScript shipped for them.

• CSR (client-side rendering): the browser downloads JavaScript and builds the page. Slow first paint, weak for SEO without extras.
• SSR (server-side rendering): HTML is generated on each request. Fresh data, good SEO, but needs a server and costs time per request.
• SSG (static site generation): HTML is built once...

Main additions:

• Actions: functions (often async) passed to <form action={fn}> or transitions, with built-in pending, error and optimistic handling.
• useActionState for form state from an action, useFormStatus for pending state inside a form, and useOptimistic for instant optimistic UI.
• use() to read a...

An error boundary is a component that catches errors thrown while rendering its children, in lifecycle methods and in constructors. It shows a fallback UI instead of crashing the whole app.

Use useReducer when state has several related fields, when the next state depends on complex rules, or when many different actions update it. It centralises updates in a pure reducer, which is easy to test.

Both run after React updates the DOM, but at different times.

React.lazy loads a component's code only when it is first rendered. Suspense shows a fallback while the component (or data) is not ready.

Both mark updates as non-urgent so React keeps the UI responsive.

• useTransition returns [isPending, startTransition]. Wrap a state update in startTransition so React can interrupt it for urgent input.
• useDeferredValue(value) returns a lagging copy of a value that updates after urgent work finishes.

Hydration is when React attaches event handlers and state to HTML that the server already rendered. It reuses the existing DOM instead of rebuilding it.

React groups multiple state updates that happen in the same event or tick into a single re-render. Since React 18 this automatic batching also works inside promises, timeouts and native event handlers, not only React events.

Server Actions are async functions marked with "use server". They run on the server but can be called from client code, usually as a form action or from an event handler. The framework creates the network endpoint for you.

Treat it as a product: a versioned package with a clear API, documentation and tests, built on shared design tokens.

Test how a user sees the behaviour, not implementation details.

The React Compiler is a build-time tool (Babel/SWC plugin). It analyses components and memoises values and functions for you, so you rarely write useMemo, useCallback or React.memo by hand.

Micro frontends split a large web application into smaller frontends. Separate teams build, test and deploy them independently. They are then combined into one page for the user. It is the frontend version of the microservices idea.

Find the problem first with the React Profiler and the browser Performance tab. Then reduce what is rendered and re-rendered.

1. Virtualise (windowing): render only visible rows using react-window, @tanstack/react-virtual or similar. This is usually the biggest win.
2. Paginate or filter on the server if users never need all rows at once.
3. Stop needless re-renders: stable keys, React.memo on the row, useCallback for handlers, and keep per-row state inside the row.
4. Move fast-changing state (like a search input) so it does not re-render the list; use useDeferredValue for filtering.
5. Avoid expensive work in render: precompute or memoise sorting and formatting.
6. Keep row DOM small and avoid layout thrash.

Confirm with before-and-after measurements.

What they are checking: Whether you measure and reach for virtualisation

Causes are usually one of these:

• Calling a setter during render: <button onClick={setOpen(true)}> runs immediately; it must be onClick={() => setOpen(true)}.
• An effect that sets state it also depends on, with no guard:

useEffect(() => { setItems([...items, 1]); }, [items]); // loops forever

• A dependency that is a new object, array or function on every render (useEffect(fn, [{ a: 1 }])). The effect then re-runs each time and sets state.

Fix:

• Move calculations into render (derived state) instead of effect plus setState.
• Use functional updates (setItems(prev => ...)) so you do not need the value as a dependency.
• Memoise object dependencies with useMemo or depend on primitives.
• Check the call stack and use the lint rule react-hooks/exhaustive-deps. Add a console log to see which dependency changes.

What they are checking: Whether you can find the loop cause quickly

This is a stale closure (the callback holds an old value). The effect ran once with []. So the callback captured count from the first render and keeps using it.

Responses can arrive out of order, so an older request overwrites the newer one. Cancel or ignore old requests in the effect cleanup.

Split state by type and use the simplest tool for each.

Use a framework with server rendering, most pages as static or incrementally regenerated: Next.js (App Router) or similar.

Move the data logic into a custom hook that returns { data, error, loading }. Use an AbortController so a slow earlier request cannot overwrite a newer one.

Each keystroke updates state at the top, which re-renders everything beneath.

React preserves state only while the component keeps the same type at the same position (and key). Resets usually come from:

Treat every request as having four states: loading, error, empty and success, and design each one.