What they're testing
Whether you separate server state from client state — conflating them is where most convoluted state code comes from.
The short answer~30 seconds
I classify state into four kinds before choosing a tool. Server state (data from an API) belongs to a caching library like TanStack Query — it brings cache keys, deduplication and background refresh, and you stop hand-writing loading/error. URL state (filters, pagination, tabs) belongs in the address bar, because it must be shareable and survive back/forward. Local state is useState in the component. Only what remains — usually very little — needs a global store.
The long answer
The biggest structural mistake I see is putting API data in Redux. You write actions, reducers, selectors and middleware for something that is fundamentally a CACHE of data living elsewhere — and then you have to solve revalidation, expiry, request deduplication and staleness yourself. That's hundreds of lines for an already-solved problem, and it's the main reason older React codebases have enormous store directories.
URL state is the most overlooked, though it gives the most benefit per line. If filters live in useState, users can't send a colleague a link, back loses everything, and a reload resets to defaults. Moving it to the query string solves all three with no library — and on a statically prerendered site you read the parameters client-side so you don't break the prerender.
When you genuinely need a global store — theme, session, cart — the selection criterion isn't features but re-render cost. React Context re-renders EVERY consumer when the value changes, so one context holding a whole config object re-renders half the tree over an unrelated field. Zustand or Jotai let you subscribe to slices, and that's usually the actual technical reason to pick them.
What they'll ask next
?Does Redux still have a place?
Yes, in applications with genuinely complex client logic that benefit from time-travel debugging or action replay — editors, trading consoles. Redux Toolkit is also far less ceremonial than old Redux. The problem was never Redux; it was using it for API data.
These lose points
- Picking the library first and finding the problem later. The first question is "who owns this state".
- Putting everything in one context. It works until the app is large enough for typing to feel laggy.