React interview questions

What a strong answer covers

• Props are inputs passed down from a parent and are read-only within the receiving component; state is data a component owns and can update over time.
• Updating state (via the setter from useState) schedules a re-render; you never mutate props or state directly.
• Data flows one way: parent to child via props, and children communicate up by calling callback props the parent passed down.
• A strong answer notes that lifting state up to a common ancestor is how sibling components share data.

Where people lose the point

• ×Saying you can change props from inside the component, or mutating this.props / a prop object.
• ×Mutating state directly (e.g. state.push(x)) instead of producing a new value through the setter.
• ×Confusing which one triggers a re-render, or claiming props changes never cause re-renders.

What a strong answer covers

• useEffect is for synchronizing with systems outside React: subscriptions, timers, manual DOM work, or data fetching, and it runs after the render is committed.
• The dependency array controls when it re-runs; the returned cleanup function runs before the next effect and on unmount to prevent leaks.
• Much logic mistakenly put in effects should instead be computed during render (derived state) or handled in event handlers; you don't need an effect to transform props into displayable data.
• A strong answer mentions that effects run twice in development under StrictMode to surface missing cleanup, and that data fetching in raw effects has race-condition and waterfall pitfalls.

Where people lose the point

• ×Using an effect to sync one piece of state from another when it could just be derived during render.
• ×Omitting cleanup for subscriptions, intervals, or event listeners, causing leaks and duplicate handlers.
• ×Treating the StrictMode double-invoke as a bug rather than a signal that an effect isn't idempotent.

What a strong answer covers

• Keys give each element a stable identity so React's reconciler can match elements between renders and decide what to reuse, move, or unmount instead of diffing purely by position.
• With a correct stable key (like a database id), reordering or inserting items lets React move existing DOM and component state rather than recreating it.
• Using the array index means identity is tied to position, so inserting or reordering shifts every key and can attach the wrong state (like input values) to the wrong item.
• A strong answer notes index keys are acceptable only for static lists that never reorder, filter, or insert in the middle.

Where people lose the point

• ×Claiming keys are only there to silence the console warning.
• ×Using the index as a key on a list that reorders or has items added or removed.
• ×Generating a fresh random key (like Math.random) on every render, which forces full remounts and destroys state.

What a strong answer covers

• useMemo caches a computed value and useCallback caches a function identity across renders, both recomputing only when their dependency array changes.
• They matter when a referentially-stable value is needed downstream: passing a callback to a React.memo child, or avoiding an expensive recomputation on every render.
• Without them, a new function or object is created each render, which breaks memoized children or effect/dependency comparisons that rely on reference equality.
• A strong answer stresses they are not free: they add memory and comparison cost, so blanket-wrapping everything can be slower and just adds noise. The React Compiler now automates much of this.

Where people lose the point

• ×Wrapping every value and function reflexively without a measured reason.
• ×Giving useCallback the wrong or empty dependency array so it closes over stale props or state.
• ×Expecting useMemo to help when the child isn't memoized, so the referential stability buys nothing.

What a strong answer covers

• Calling the state setter schedules a re-render; React re-invokes the component function to produce a new element tree (the render phase), which is pure and has no side effects.
• React reconciles the new tree against the previous one, diffing by element type and key to compute the minimal set of changes.
• In the commit phase React applies those changes to the real DOM and then runs layout effects and effects; this phase is where mutations happen.
• A strong answer mentions batching of multiple state updates into one render, and that concurrent features let React interrupt or reprioritize the render phase before commit.

Where people lose the point

• ×Claiming setState updates the DOM synchronously and immediately.
• ×Saying React re-renders and repaints the entire DOM rather than diffing and applying minimal changes.
• ×Conflating the render phase (pure, interruptible) with the commit phase (side effects, DOM writes).

What a strong answer covers

• The effect captured the state variable in a closure from the render when it ran; with an empty dependency array the interval callback keeps referencing that first snapshot.
• One fix is the functional updater form, setCount(c => c + 1), which reads the latest value from React rather than the captured variable.
• Alternatively, include the state in the dependency array so the effect re-subscribes with a fresh closure, remembering to clear the old interval in cleanup.
• A strong answer notes useRef can hold a mutable latest-value that the callback reads, avoiding re-subscription while still seeing current data.

Where people lose the point

• ×Blaming React for being buggy instead of recognizing the stale closure over captured state.
• ×Removing the dependency array entirely, which re-creates the interval on every render.
• ×Adding the dependency but forgetting to clear the previous interval, stacking multiple timers.