When would you choose Redux or Zustand over React's built-in hooks?

WHAT THIS TESTS: This question tests whether you can articulate the boundary between component-level state and application-level state. Interviewers want to see that you understand the concrete failure modes of useState and useContext, specifically performance cliffs, deep prop drilling, and unpredictable update chains, rather than relying on vague rules like use Redux for big apps.

A GOOD ANSWER COVERS: A strong candidate names four specific signals from the Redux documentation. First, large amounts of application state are needed in many distant places in the component tree, which makes prop drilling or deeply nested Context providers unwieldy. Second, the state is updated frequently, because Context causes unnecessary re-renders of all consumers when any value changes, whereas a well-structured store can isolate updates to subscribers. Third, the logic to update that state is complex or involves multiple subsystems, so centralizing reducers or actions makes the flow easier to trace and test. Fourth, the team needs to see how state is being updated over time, leveraging time-travel debugging, action logging, or replayable state transitions. A senior answer also mentions tradeoffs, noting that global state adds indirection and boilerplate, and that lighter alternatives like Zustand or Jotai can solve the same problems with less ceremony.

COMMON WRONG ANSWERS: The biggest red flag is recommending Redux as a default for every project or every team larger than two people. Another mistake is claiming that Context does not scale without explaining the technical reason, which is that any change to a Context value re-renders every component that consumes it, even if only one slice of data changed. Some candidates also confuse server-state caching with client-state management, suggesting Redux for data fetching when tools like React Query or SWR are more appropriate.

LIKELY FOLLOW-UPS: An interviewer might ask how you would migrate an existing Context-based codebase to a store without a full rewrite. They may also ask you to compare Zustand to Redux Toolkit, or to explain how you would prevent a global store from becoming a dumping ground for all state. Another common follow-up is asking how you structure state to avoid excessive re-renders in a connected component tree.

ONE CONCRETE EXAMPLE: Imagine a real-time collaborative dashboard with a WebSocket feed updating stock prices, user presence, and alert banners across twenty distinct widget components. Using useState alone would force you to lift every feed to a common ancestor and pass it down through layers of components that do not need it. Using Context for the feed would cause every widget to re-render on every price tick. A global store lets each widget subscribe only to its relevant slice, keeps the update logic in predictable reducers, and lets developers replay the WebSocket message log to reproduce bugs.