Common React Interview Questions

React interviews typically probe how well you understand the mental model behind the library, not just its API surface. Interviewers want to see that you can explain why the virtual DOM exists, how reconciliation and keys work together, why hooks have rules, and when to reach for memoization or Context instead of prop drilling. This topic collects the questions that come up most often across junior-to-mid React interviews, paired with answers that go a level deeper than a one-line definition so you can defend your reasoning in a follow-up discussion.

The virtual DOM is a lightweight in-memory representation of the real DOM, expressed as plain JavaScript objects. When state changes, React builds a new virtual DOM tree, diffs it against the previous tree (reconciliation), and computes the minimal set of real DOM mutations needed to bring the UI up to date. Direct DOM manipulation is expensive because layout, style recalculation, and repainting are costly browser operations. By batching and minimizing real DOM writes, React trades cheap JavaScript object comparisons for expensive DOM operations, which keeps UI updates fast even as an application grows in complexity.

Reconciliation compares the new element tree to the previous one using a heuristic O(n) diffing algorithm rather than the theoretically optimal O(n^3) tree-diff. It relies on two assumptions: elements of different types produce different trees (so React tears down and rebuilds rather than trying to match children), and elements of the same type are compared attribute-by-attribute while their children are diffed recursively. For lists, React uses the key prop to match children across renders instead of relying on index position, which lets it correctly reorder, insert, or remove items without unnecessarily destroying and recreating DOM nodes and component state.

Keys give React a stable identity for each item across renders so it can match old elements to new ones instead of guessing by position. A stable, unique key (like a database id) lets React correctly reuse DOM nodes and preserve component state when items are reordered, inserted, or removed. Using the array index as a key works fine for static lists that never reorder or change length, but it becomes a bug source once items can be added, removed, or reordered: React will match the wrong old element to the wrong new data, causing state to attach to the wrong row, stale form inputs, or incorrect animations.

The two rules are: only call hooks at the top level of a function component or custom hook (never inside loops, conditions, or nested functions), and only call hooks from React function components or other custom hooks (never from regular JavaScript functions). These rules exist because React tracks hook state by call order, not by name — internally each component has a linked list of hook calls indexed by position. If a hook is called conditionally, the order can shift between renders, causing React to associate the wrong state or effect with the wrong hook call, leading to subtle and hard-to-debug bugs.

A controlled component has its form value driven entirely by React state: the input's value prop is set from state and an onChange handler updates that state on every keystroke, making React the single source of truth. An uncontrolled component lets the DOM manage its own internal state, and React reads the current value on demand via a ref, typically using a defaultValue for the initial value instead of value. Controlled components give you validation, conditional disabling, and formatting on every keystroke at the cost of a re-render per input; uncontrolled components are simpler and more performant for cases like a plain file input or a form you only read on submit.

The dependency array tells React when to re-run the effect: after the initial render, React re-runs the effect only if any value in the array has changed (compared with Object.is) since the last render. Omitting the array entirely runs the effect after every render; passing an empty array [] runs it once after the initial mount only. A common mistake is omitting a dependency that the effect actually reads, which causes the effect to close over a stale value — the fix is to include every reactive value the effect uses, or to restructure the effect (for example moving logic into the event handler) so it does not need that dependency at all.

Both hooks memoize a value between renders based on a dependency array, but they memoize different things: useMemo caches the *result* of an expensive computation and returns that value, while useCallback caches a *function reference* itself, which is really just shorthand for useMemo(() => fn, deps). They're most useful for avoiding expensive recalculations on every render and for keeping stable references so that child components wrapped in React.memo don't re-render just because a new inline function or object was created on the parent. Overusing either adds memory and comparison overhead, so they should be applied where profiling shows a real cost, not by default on every value.

Prop drilling happens when data needs to pass through several intermediate components that don't use the data themselves, just to reach a deeply nested child — each layer has to accept and forward the prop, which adds boilerplate and coupling. The Context API solves this by letting a provider expose a value at the top of a subtree that any descendant can read directly via useContext, skipping the intermediate layers entirely. Context isn't a full replacement for state management libraries, though: every consumer re-renders when the context value changes, so it's best for relatively low-frequency, broadly-shared data like theme, locale, or authenticated user, rather than high-frequency state.

Props are read-only inputs passed down from a parent component to configure a child; a component must never mutate its own props. State is data owned and managed internally by a component (via useState or useReducer) that can change over time and triggers a re-render when updated. The distinction matters for data flow: props flow one way, top-down, while state changes are local and, if a descendant needs to affect an ancestor, are handled by passing a callback down as a prop ("lifting state up") rather than mutating a prop directly.

Error boundaries are class components that implement static getDerivedStateFromError and/or componentDidCatch to catch JavaScript errors thrown during rendering, in lifecycle methods, and in constructors of their child tree, displaying a fallback UI instead of crashing the whole app. They do not catch errors inside event handlers (those need a regular try/catch), errors in asynchronous code such as setTimeout or promise callbacks, errors during server-side rendering, or errors thrown in the error boundary itself. There is currently no hook-based equivalent, so error boundaries must still be written as class components, though libraries like react-error-boundary wrap this pattern for convenience.