100 Redux Interview Questions & Answers
Redux interviews test the mental model as much as the API — why state is immutable, why reducers must be pure, why middleware exists at all. This covers all 100 questions, organized by topic, with code (mostly modern Redux Toolkit, with the classic hand-written patterns explained alongside since interview banks and older codebases still ask about them directly), a diagram, and a mock test at the end.
Redux Fundamentals
Q1. What is Redux and how is it used in web development?
Redux is a predictable state container — a single, centralized store holding an application's entire state, updated only through dispatched actions handled by pure reducer functions. It's used (most commonly alongside React, though it's framework-agnostic) when an application's state is complex enough, or shared across enough distant components, that prop-drilling or scattered local state becomes genuinely hard to reason about.
Q2. Can you describe the three principles that Redux is based upon?
| Principle | Meaning |
|---|---|
| Single source of truth | The entire application state lives in one store |
| State is read-only | The only way to change state is to dispatch an action |
| Changes are made with pure functions | Reducers take the previous state + an action, return a new state, with no side effects |
Q3. What is an action in Redux?
{ type: "todos/add", payload: { text: "Buy milk" } }An action is a plain JavaScript object describing something that happened — a required type field (conventionally a string) identifying what kind of event it is, plus any additional data (usually under payload) the reducer needs to compute the new state.
Q4. How are actions used to change the state in a Redux application?
store.dispatch({ type: "todos/add", payload: { text: "Buy milk" } });
// The store runs the root reducer with (currentState, action), replacing state with whatever it returnsDispatching an action is the only entry point for changing state — the store passes the action (and the current state) to the reducer, and whatever the reducer returns becomes the new state, triggering a re-render of any subscribed UI.
Q5. What is a reducer in Redux and what role does it play?
function todosReducer(state = [], action) {
switch (action.type) {
case "todos/add":
return [...state, action.payload];
default:
return state; // unknown action — return state unchanged
}
}A reducer is a pure function — (previousState, action) => newState — with no side effects, no mutation of its arguments, and no randomness/dates/API calls inside it. Purity is what makes Redux state predictable and enables features like time-travel debugging, since replaying the same actions against the same starting state always produces the same result.
Q6. How does Redux differ from local component state in React?
| Local component state (useState) | Redux | |
|---|---|---|
| Scope | Confined to one component (and its children, if passed down) | Global — accessible from anywhere without prop drilling |
| Sharing across distant components | Requires lifting state up, or Context | Any connected component can read/dispatch directly |
| Overhead | None — built into React | Store setup, actions, reducers — real ceremony for simple cases |
Local state is the right default for anything genuinely local to one component/subtree; Redux earns its overhead when state is truly shared across many unrelated parts of the app, or when you want strict, centralized, inspectable state transitions.
Q7. Define 'store' in the context of Redux.
import { configureStore } from "@reduxjs/toolkit";
const store = configureStore({ reducer: rootReducer });
store.getState();
store.dispatch(someAction);
store.subscribe(() => console.log("state changed"));The store holds the application's entire state tree, and exposes getState() (read the current state), dispatch(action) (the only way to change it), and subscribe(listener) (react to changes) — it's a single object per application, not one per feature/component.
Q8. Can you describe the concept of 'single source of truth' in Redux?
Every piece of shared application state lives in exactly one place — the store — rather than duplicated or synchronized across multiple components' local state. This eliminates an entire category of bugs where two copies of "the same" data drift out of sync with each other.
Q9. How do you create a Redux store?
// Modern (Redux Toolkit) — the recommended approach today
import { configureStore } from "@reduxjs/toolkit";
const store = configureStore({ reducer: { todos: todosReducer } });
// Classic (plain Redux) — what older codebases and many interview banks still describe
import { createStore } from "redux";
const store = createStore(rootReducer);Q10. What is meant by 'immutable state,' and why is it important in Redux?
// Wrong — mutates the existing array
state.push(newTodo);
return state;
// Correct — returns a NEW array, leaving the original untouched
return [...state, newTodo];Immutability means a reducer never modifies the existing state object — it always returns a new one. This matters because React-Redux (and Redux DevTools' time-travel) detect changes via reference equality — if state were mutated in place, the reference wouldn't change, and connected components would never know to re-render.
Enjoyed this?
Let's talk about building something together.