Common React Interview Questions and How to Answer Them

A strong answer explains that a state or prop change causes React to render the relevant component tree and compare the new output with the previous one. React then commits the necessary changes to the host environment, such as the browser DOM.

Clarify that rendering a component does not automatically mean every DOM node changes. Also mention that component identity, element type, and keys influence whether React preserves or resets state.

Keys help React identify items among siblings across renders. Stable keys allow React to preserve the correct component state when items are inserted, removed, or reordered.

Array indexes can be acceptable for a static list that never reorders, but they are risky for editable or changing lists. Prefer a stable identifier from the underlying data.

Use an effect to synchronize React with an external system: a network subscription, browser API, timer, or non-React widget. Many derived values and event-driven updates do not need an effect.

Be ready to explain cleanup and dependencies. Cleanup should undo the synchronization, while the dependency list should include reactive values used by the effect. Avoid describing an empty dependency array as a universal “run once” mechanism.

Place state in the closest common owner of the components that need it. Keep state local until sharing creates a real requirement. Distinguish local UI state, URL state, form state, and server data because each has different tools and persistence needs.

Interviewers often care more about the reasoning than a particular library. Explain why a solution is appropriate for the scale and behavior of the feature.

Start by measuring a real problem. Common improvements include reducing unnecessary work, keeping state close to where it is used, virtualizing large lists, splitting expensive components, and avoiding network waterfalls.

Memoization has a cost and should not be applied blindly. Explain when referential stability matters, such as a measured expensive render or a dependency that would otherwise trigger repeated work.

Practice reading unfamiliar components, finding stale state, correcting effect dependencies, and designing a small feature from requirements. Prepare two or three project stories that cover a difficult bug, a trade-off, collaboration, and an improvement you measured.

When you do not know an answer, state what you understand, identify the uncertainty, and describe how you would verify it. Clear reasoning is more credible than confident guessing.