Have you worked with state management libraries like Zustand, and how do they compare to Redux?
Yes — frame it around when and why: Zustand for lightweight global client state with selector-based subscriptions and minimal boilerplate; Redux Toolkit for large apps needing structure/middleware/devtools; Jotai for atomic state; and React Query for server state (a different problem).
This is a "show your judgment" question — the interviewer wants to know you can choose and reason, not just that you've imported a library.
Frame it: classify the problem first
Most state-management confusion is from conflating two problems:
- Server state (data from an API) → React Query / SWR / RTK Query. Caching, dedup, refetch — not what Zustand/Redux are for.
- Global client state (UI state shared across the tree) → Zustand / Redux Toolkit / Jotai.
Saying this up front signals seniority.
Zustand — what it's good at
- Minimal boilerplate — a store is a hook created with
create(); no providers, no actions/reducers ceremony. - Selector-based subscriptions —
useStore(s => s.cart)re-renders only when that slice changes. Good re-render performance by default. - Unopinionated — state and updater functions live together; works outside React too.
- Small bundle, easy to learn.
- Great for: cart, UI state (modals, sidebars), auth/user, app-wide settings — small-to-mid global state.
const useCart = create((set) => ({
items: [],
addItem: (item) => set((s) => ({ items: [...s.items, item] })),
}));
// component:
const items = useCart((s) => s.items);When I'd pick something else
- Redux Toolkit — large app, big team, need strict structure, time-travel devtools, rich middleware, or a well-known pattern everyone recognizes. RTK removed most of Redux's old boilerplate pain.
- Jotai / Recoil — atomic model fits when state is naturally fine-grained and derived; bottom-up composition.
- Context — low-frequency truly-global values (theme, locale); not for hot-updating state.
- Just useState/useReducer — most state is local; don't reach for a library reflexively.
How to answer in the interview
"Yes — I've used Zustand for [X: e.g. cart and UI state] because it's minimal and its selectors keep re-renders tight. I default to classifying state first: server state goes to React Query, local state stays local, and for global client state I pick Zustand for small-to-mid apps or Redux Toolkit when the app needs more structure and tooling. The library matters less than putting each kind of state in the right place." Then give a concrete example from your experience.
Follow-up questions
- •Zustand vs Redux Toolkit — when would you pick each?
- •Why is server state a different problem from client state?
- •How do Zustand's selectors help with re-render performance?
- •When would you not use any state library at all?
Common mistakes
- •Treating all state as the same problem (server vs client).
- •Reaching for a global store when local state would do.
- •Using Zustand/Redux to cache server data and hand-rolling refetch logic.
- •Naming a library without being able to justify the choice.
Performance considerations
- •Zustand's selector subscriptions mean components re-render only on the slice they read — good default. A naive Context holding everything re-renders all consumers. Server-cache libraries dedupe network calls entirely.
Edge cases
- •State that's both server-derived and locally editable.
- •SSR/hydration with a global store.
- •Migrating from Redux to Zustand incrementally.
Real-world examples
- •Zustand for cart + UI state, React Query for product data, Context for theme — in one app.
- •Redux Toolkit in a large multi-team app for structure and devtools.