React state management in 2026 is more fragmented than at any point in the framework’s history. The built-in primitives (useState, useReducer, Context) cover most use cases but have well-known limits. The third-party landscape includes Redux (declining but still common in legacy), Zustand (rapidly dominant for client state), Jotai (atom-based), Recoil (Meta-built but slowing), MobX (specialized), and several smaller players. Server state libraries (TanStack Query / React Query, SWR, Apollo) are essentially mandatory for serious applications.
Senior frontend interviews probe whether candidates can navigate this landscape — knowing what to pick when, articulating tradeoffs, and avoiding the common over-engineering pitfalls. This piece is the map.
The categories of state
The first thing senior interviewers test is whether the candidate decomposes “state management” correctly. Not all state is the same; different categories want different solutions.
- UI state: form inputs, hover states, expanded/collapsed accordions. Local to a component.
- Application state: selected tab, current user, theme. Often shared across many components.
- Server state: data fetched from APIs. Async, cached, occasionally stale.
- URL state: route, query params, anchor. Owned by the URL, not by JavaScript.
- Form state: field values, validation, dirty tracking. A specialized intersection of UI and application state.
The 2026 best practice: pick the right tool per category, not one tool for everything.
Built-in primitives
useState
The default for component-local state. Strong for: form inputs, toggles, simple values. Weak for: shared state across components, complex state with multiple actions.
useReducer
Strong for: state with multiple discrete actions (open / close / submit / cancel), state that changes in response to events. Weak for: trivial state where useState is simpler.
Context
Strong for: theme, user, locale — values that don’t change frequently and are needed widely. Weak for: state that changes frequently (every consumer re-renders), state where some consumers care about a subset of fields.
Senior interviewers probe the Context performance issue. The candidate should know that Context updates re-render every consumer, even if the consumer only uses one field of a larger context value. The solutions: split contexts by concern, use selector libraries, or pick a state-management library that subscribes more finely.
Redux: legacy but still common
Redux dominated state management from 2015-2020. By 2026 it is in clear decline for new applications but remains common in:
- Existing codebases that haven’t migrated.
- Large enterprise applications with established Redux patterns.
- Teams with strong Redux conventions and tooling.
Modern Redux uses Redux Toolkit (RTK), which is much more ergonomic than vanilla Redux. Interviews still test Redux concepts (actions, reducers, selectors, middleware) but the bar has moved toward RTK and away from boilerplate-heavy patterns.
What still scores well: knowing why Redux exists (predictable state container, time-travel debugging, middleware ecosystem), when it’s appropriate (very large applications with established conventions), and when it’s overkill (most modern applications).
Zustand: the 2026 default for new projects
Zustand has emerged as the most-recommended client-state library for new React projects in 2026. Strengths:
- Tiny API — a single hook, no providers needed.
- Selector subscriptions — components only re-render when the selected slice changes.
- TypeScript-friendly.
- Works with both client-side and server-side rendering.
Senior interviews increasingly assume Zustand familiarity, especially at modern startups. The interview questions are usually about API design and tradeoffs vs other libraries.
Jotai: atom-based state
Jotai uses a Recoil-inspired atom model — small pieces of state that can be composed. Strengths:
- Fine-grained re-renders.
- Compositional state derivation.
- TypeScript-friendly.
Trade-off: requires more upfront thinking about atom design than Zustand’s flat-store approach. Less common in interviews than Zustand but well-respected.
Server state: React Query / TanStack Query (the must-know)
Server state is the category most candidates under-prepare for. By 2026, almost any non-trivial React application uses TanStack Query (formerly React Query), SWR, Apollo (for GraphQL), or a similar library. The patterns:
- Stale-while-revalidate: show cached data immediately, fetch fresh data in the background.
- Cache key: the unique identifier for a cached query (typically the API endpoint + params).
- Cache invalidation: mark cached data as stale and refetch.
- Optimistic updates: update the UI immediately, roll back if the mutation fails.
- Mutation handling: POST/PUT/DELETE operations and their cache effects.
Senior interviewers test these patterns directly. A candidate who designs an entire frontend without considering server state caching does not understand modern frontend architecture.
URL state: the underrated category
URL state — route, query params, hash — is owned by the URL itself, not by JavaScript. The temptation to duplicate URL state in component state leads to bugs (state out of sync with URL on navigation, broken back-button behavior).
The 2026 patterns:
- React Router or Next.js routing as the source of truth.
- Library helpers (useSearchParams, useRouter) to read and update URL state.
- For complex query-state, libraries like nuqs that bridge URL and component state cleanly.
Senior interviews test whether candidates know not to duplicate URL state in JavaScript.
Form state: specialized libraries
Form state is a specialized intersection. Common 2026 libraries:
- React Hook Form: dominant for performant, uncontrolled-by-default forms.
- Formik: declining but still common in legacy.
- TanStack Form: newer, integrates with the rest of the TanStack ecosystem.
Plus validation libraries: Zod (dominant), Yup (declining), Valibot (newer, smaller).
The decision framework senior interviews test
Given a state-management problem, senior candidates apply a decision tree:
- Is it server state? Use TanStack Query / SWR / Apollo.
- Is it URL state? Use the router.
- Is it form state? Use React Hook Form or similar.
- Is it component-local state? Use useState / useReducer.
- Is it shared client state across many components? Pick Zustand or Jotai based on team preference.
- Is it Context for theme / user / locale? Use Context.
The decision tree is the answer most senior interviews want. Candidates who default to “Redux for everything” or “Context for everything” signal lack of taste in the modern landscape.
What to skip
- Memorizing every state library’s API. Two or three are enough — TanStack Query plus Zustand or Jotai plus React Hook Form.
- Over-emphasizing Redux unless the target company specifically uses it.
- MobX unless interviewing at a MobX-using company (rare in 2026).
Frequently Asked Questions
Should I learn Redux for new interviews?
For legacy / enterprise companies yes. For modern startups, conceptual understanding is enough. Most teams have moved past it for new projects.
Is Context bad?
No. Context is the right tool for low-frequency-changing values shared widely (theme, user). It’s the wrong tool for frequently-changing values where re-render performance matters.
How does the choice differ in Next.js vs Vite?
Next.js applications often use the URL more heavily (server-side routing) and benefit from server state libraries that integrate with React Server Components. Vite applications are more client-state-heavy in practice.
What about server-side state in 2026 with RSC?
React Server Components reduce some client-side state needs by fetching data on the server. The boundary between RSC data and client-side state is itself an interview topic — senior candidates should articulate when each makes sense.
Is one library always better than the others?
No, and senior interviews test the candidate’s ability to articulate tradeoffs. The right answer is “depends on the use case” with specifics, not “always Zustand” or “always Redux.”