React Redux Interview Questions and Answers

What Redux interviews actually ask now

Two things have changed and both show up in interviews. Redux Toolkit is no longer optional, it is the official way to write Redux, and describing hand-written action-type constants and switch statements as your default marks you as out of date rather than experienced. And a large share of what teams used Redux for, caching server responses, has moved to React Query or RTK Query, so the interesting question is no longer how Redux works but what is left for it to do.

That is why the strongest answers here are scoped rather than enthusiastic. An interviewer who asks "do you know Redux?" is often really asking "will you reach for Redux on day one of a project that does not need it?" Knowing the internals and knowing when to leave them alone are both being assessed, and the second is what separates the candidates.

What are the core Redux concepts?

One store holds all the state as a single object tree. An action is a plain object describing what happened, with a `type` and usually a `payload`. A reducer is a pure function taking the current state and an action and returning the next state. Components dispatch actions and read state through selectors. Data flows one way - dispatch, reducer, new state, re-render, and nothing writes to the store directly.

Being able to name what this replaces is worth doing unprompted, because it shows the boilerplate reduction is something you have felt rather than read about. `createSlice` generates the action creators and the type strings, removes the constants file and the switch statement, and `configureStore` sets up the DevTools extension, the thunk middleware and development-only checks for accidental mutation and non-serialisable values, all of which used to be manual wiring.

Why must reducers be pure and immutable?

Because change detection is a reference comparison. React-Redux decides whether a component needs to re-render by comparing the previous selected value with the next one using strict equality, so mutating an object in place leaves the reference identical and the update is invisible. Purity also buys predictability - the same state and action always produce the same result, which is what makes time-travel debugging and replaying actions possible at all.

The follow-up is where side effects belong, and the answer is middleware, a thunk, a listener, or RTK Query. A reducer that fetches, logs, reads `Date.now()` or generates a random id is not replayable, which defeats the entire reason for the pattern. Generating the id in the action creator, or in `createSlice`'s `prepare` callback, is the idiomatic fix.

How does Immer let you write mutating code?

Redux Toolkit passes your reducer a draft, a Proxy that records every write you make instead of applying it. When the reducer returns, Immer replays those recorded changes to produce a new state object, structurally sharing every branch you did not touch. So the syntax is mutable and the result is immutable, and the parts of the tree you left alone keep their references, which is exactly what memoised selectors and `React.memo` need.

Both mistakes in that snippet come up in real review. Mutating the draft and also returning a value throws, because Immer cannot tell which one you meant. Reassigning `draft` itself does nothing, for the same pass-by-value reason that reassigning a function parameter does nothing, you have to write `state.items = []` rather than `state = { items: [] }`. And Immer's mutable syntax only applies inside a Toolkit reducer or a `produce` call; a plain reducer still needs spreads.

What is middleware, and how does a thunk work?

Middleware sits between `dispatch` and the reducer, forming a chain that each dispatched action passes through. Every middleware can inspect the action, transform it, delay it, log it, or stop it from continuing. It is the extension point where everything that is not a pure state transition lives, logging, analytics, and above all asynchronous work.

The curried triple-arrow signature is a standard whiteboard question and worth being able to write from memory. The insight to state alongside it is that thunk does not extend Redux so much as bypass it briefly: the store still only ever receives plain, serialisable actions, and the async work happens outside the reducer where it belongs. `createAsyncThunk` wraps this pattern and generates the pending, fulfilled and rejected actions for you.

What are selectors, and why memoise them?

A selector is a function from the store state to the piece a component needs. Keeping them in one place means components do not depend on the shape of the state tree, so reshaping the store does not touch every component. Memoisation matters because `useSelector` re-runs after every dispatch and compares the result by reference, a selector that builds a new array or object every time returns a new reference every time, so the component re-renders on every action in the application.

The cache-size-of-one detail is the advanced follow-up. A selector shared by a list of components each passing a different id will thrash, because every call evicts the previous result, the fix is a selector factory created per component instance, or `createSelector` with a larger cache. Being able to describe that failure is a genuinely senior answer and very few candidates reach it.

How should state be shaped, and what is normalisation?

Store collections as a lookup object keyed by id plus an array of ids, rather than as a nested array of objects. Updating one item then means writing to one key instead of mapping the whole array, lookups are constant time instead of linear, and the same entity is not duplicated in three places waiting to go out of sync.

`createEntityAdapter` in Redux Toolkit generates this shape along with the add, update, remove and upsert reducers and a set of selectors, which is the answer to give if asked how you would implement it. The `allIds` array is worth explaining too, an object's key order is not something to rely on for display order, so the array is what preserves it.

What is RTK Query, and when does it replace thunks?

RTK Query is a data-fetching and caching layer built into Redux Toolkit. You declare endpoints and it generates hooks that handle the request, caching, deduplication of identical in-flight requests, loading and error state, cache invalidation by tag, and refetching. It replaces the entire hand-written thunk-plus-slice pattern for server data, which in most applications was the bulk of the Redux code.

The framing that lands in an interview is that server data was never really client state. It is a cache of something owned elsewhere, with its own concerns, staleness, revalidation, retries, that a reducer was never designed to express. Once RTK Query or React Query owns that, the Redux store is left with genuine client state: the open modal, the multi-step form draft, the selected rows, the theme. Some teams find that remainder small enough that they drop Redux entirely, and saying so is not disloyal, it is the current consensus.

When do you actually need Redux?

When several distant parts of the application read and write the same frequently-changing client state, and you need the tooling, a serialisable action log, time-travel debugging, middleware, and predictable updates that a team can reason about. Large applications with complex cross-cutting interactions genuinely benefit. A dashboard with a handful of screens does not.

Split the decision by the kind of state rather than by its scope. Server data goes to a query cache. URL state - filters, pagination, the selected tab, belongs in the URL, where it survives a refresh and can be shared as a link. Form state belongs in the form library. What is left is the candidate for a store, and for that remainder Context is fine when it changes rarely, Zustand is fine when it changes often and you want minimal ceremony, and Redux earns its place when the tooling and the discipline are worth the boilerplate. The two comparison pages linked below go deeper on each.

What loses marks in a Redux round

The failure modes here are unusually consistent, and most are about being a version behind.

• →Describing hand-written constants and switch statements as your normal approach.
• →Not knowing that Toolkit reducers only look mutable because of Immer.
• →Saying reducers must be pure without connecting it to reference-based change detection.
• →Putting fetches, Date.now() or random ids inside a reducer.
• →Never having memoised a selector, or not knowing why an inline filter re-renders.
• →Storing a list as a nested array and then mapping it on every update.
• →Answering "when would you use Redux?" with "for global state" and stopping there.