DEVPREP CODEX · #22

Redux Interview Questions

60 curated questions graded from Foundations (Easy) to Practical Patterns (Medium) and Internals & Architecture (Hard).

TOTAL QUESTIONS

THEORY QUESTIONS

IMPLEMENTATION FOLIOS

FREE QUESTIONS

5 / Level

Easy Level·20 Questions Total

Foundations & Core Concepts

Open Full Easy List

Q1What is Redux and what problem does it solve?

Definition: A predictable state container for JavaScript apps. State lives in one store; the only way to change it is dispatching actions into pure reducers.
Problems solved:
- Prop drilling — any component can subscribe to exactly the slices it needs.
- Unpredictable mutations — immutability makes every change traceable.
- Scattered state logic — transitions are centralized and testable.
Best suited to complex, shared client state; overkill for purely local UI state.

Q2Explain the three core principles of Redux.

Single source of truth — the entire app state is one object tree stored in one store.
State is read-only — components never mutate; they dispatch plain action objects describing what happened.
Changes via pure functions — reducers take (previousState, action) and return the next state, with no side effects. These three rules give you time-travel debugging, deterministic tests and trivial undo/redo foundations.

Q3What are the core building blocks of Redux?

Store — holds state, exposes getState(), dispatch(), subscribe().
Action — a plain object { type, payload? } describing an event.
Action creator — a function returning an action (keeps dispatch sites clean and typed).
Reducer — pure function producing next state per action.
Dispatch — the only mutation entry point.
Selector — function reading derived data from state (state => state.cart.items).

Q4What is the difference between an action and an action creator?

An action is the payload object itself: { type: 'cart/add', payload: { id } }.
An action creator is the function that builds it: const addToCart = id => ({ type: 'cart/add', payload: { id } }).
Why bother with creators: centralizes action shapes, gives TypeScript a single typed factory, keeps components free of string literals, and (with thunks/sagas) becomes the place where async logic starts.
With Redux Toolkit you rarely hand-write them — createSlice generates creators automatically from reducer names.

Q5What does a reducer look like and what rules must it follow?

function cartReducer(state = initialState, action) {
  switch (action.type) {
    case 'cart/add':
      return { ...state, items: [...state.items, action.payload] };
    default:
      return state;
  }
}

Rules:

Pure — same inputs ⇒ same output; no API calls, no Date.now/Math.random.
No mutation — spread/copy every touched level.
Default case returns state unchanged (enables cheap bailouts).
Never return undefined — React state reads will explode.

15 More Easy Questions Locked

Unlock the complete Redux Easy question bank

Get instant access to all 20 questions, in-depth model answers, code sandboxes, and all 27+ technologies for a single one-time payment.

Unlock All — One-time payment · Lifetime access

Medium Level·20 Questions Total

Mechanisms & Practical Patterns

Open Full Medium List

Q1What is a middleware in Redux and how does the chain work?

Middleware sits between dispatch and the reducer — it can log, transform, delay, or swallow actions.
Signature: store => next => action => result. Calling next(action) forwards to the next middleware; calling dispatch(...) instead restarts from the chain's head.
Composition order matters: middleware applied earlier sees actions first on the way IN and last on the way OUT.
Classic uses: thunks (async), logging/crash reporting, routing sync, analytics. RTK pre-installs thunk + devtools; add custom ones via configureStore({ middleware: g => g().concat(logger) }).

Q2Explain Redux Thunk — what problem does it solve and its limits?

const fetchUser = id => async (dispatch, getState) => {
  dispatch(loadingStarted());
  try { dispatch(loadSucceeded(await api.getUser(id))); }
  catch (e) { dispatch(loadFailed(e.message)); }
};

A thunk is any function dispatched instead of a plain object; the middleware invokes it lazily with (dispatch, getState) — enabling side effects and multi-step dispatches.
Limits: no cancellation built-in, race conditions need manual guards, complex flows become nested callback soup, hard to test interleavings.
For heavy async choreography teams graduate to RTK Query (data) or sagas/orchestration libs (flows).

Q3What is createAsyncThunk and what lifecycle does it generate?

const fetchUser = createAsyncThunk('user/fetch', async (id, { signal }) =>
  api.getUser(id, { signal }));

Emits three actions automatically: pending, fulfilled (payload = return value), rejected (payload = serialized error unless rejectWithValue).

Handle them via extraReducers builders — keeps slice reducers declarative.
Built-ins you get for free: AbortSignal (thunk.dispatch(fetchUser.abort()) or condition option), single-flight dedupe per arg (condition callback), and typed payload preparation via payloadCreator's second arg { dispatch, getState, rejectWithValue }.

Q4How do you handle race conditions in async Redux code?

Scenario: search input fires request per keystroke; slow stale response overwrites fresh results.
Guards ladder:
1. AbortController passed into fetch via thunkAPI.signal; abort prior request before starting new one.
2. Request-id check: capture id before await; ignore fulfillment if getState() shows newer id.
3. RTK Query / TanStack Query: subscription-based caches handle this natively (last-arg wins). Interview gold: describe both the symptom (flicker of wrong data) and two independent defenses (cancel + discard).

Q5What is Reselect and why do memoized selectors matter?

const selectVisible = createSelector(
  [selectTodos, selectFilter],
  (todos, filter) => todos.filter(t => matches(t, filter)) // reruns only on input change
);

useSelector runs after EVERY action; unmemoized derived selectors recompute (and produce new array references → re-renders) even when inputs didn't change.
Reselect caches the last computation keyed by reference equality of inputs: cheap skip when unrelated slices changed.
Pitfalls: default cache size 1 — alternating inputs thrash it (create per-component factories); input selectors returning new objects defeat memoization entirely.

15 More Medium Questions Locked

Unlock the complete Redux Medium question bank

Get instant access to all 20 questions, in-depth model answers, code sandboxes, and all 27+ technologies for a single one-time payment.

Unlock All — One-time payment · Lifetime access

Hard Level·20 Questions Total

Internals & System Architecture

Open Full Hard List

Q1How does the Redux store dispatch pipeline actually execute internally?

configureStore composes middleware via compose(...middlewares)(store.dispatch) producing an enhanced dispatcher; each layer wraps the next, so calling enhanced dispatch enters middleware[0] first.
The store keeps currentReducer, currentState; a boolean isDispatching guards re-entrancy — dispatching DURING a reducer throws ("Reducers may not dispatch actions"), preventing cascading corruption.
After reducer returns, listeners array is snapshotted and iterated — subscribers added/removed during notification are handled safely for the current pass but affect future ones.
State reference changes even when reducers return identical slices? No — combineReducers preserves identical slice references; root ref changes only if any slice changed (cheap bailout preserved).

Q2What guarantees does react-redux's useSyncExternalStore-based subscription provide, and what tearing means here?

Modern react-redux subscribes via useSyncExternalStore with a memoized selector wrapper (useSelectorWithStore pattern): getSnapshot = latest selector result cached per subscription.
Tearing: in concurrent rendering two components could read different store snapshots within one committed tree. useSyncExternalStore's consistency check forces re-render when snapshot mutates mid-render, closing the tear — provided your selector is pure & stable.
Store authors must notify AFTER commit-friendly timing? Not required — notifications during render trigger the check path. But mutating state objects in place breaks snapshot identity assumptions entirely (never mutate).
Interview depth: contrast with pre-18 store.subscribe + setState approach which could tear under transitions.

Q3Explain Immer proxy mechanics and where they break down.

Produce walks your draft mutations through ES2015 Proxy traps (set/get/deleteProperty), recording a patch list; finalize copies ONLY touched paths (copy-on-write at object granularity).
Breakage cases interviewers probe:
- Reading then relying on prototype methods of class instances stored in state (draft loses constructor unless tagged).
- Async gaps: keeping a draft beyond the producer scope → revoked proxy errors.
- Map/Set require plugins; Symbol-keyed fields ignored; extremely large arrays pay trap overhead.
- Structural sharing guarantee holds only if you never escape-references drafts into results. Patches emitted alongside enable inverse-patch undo systems.

Q4Design an undo/redo system on top of Redux — what do you track?

Two viable architectures:

Snapshot stack: wrap reducer to push {past:[...], present, future:[]} per tracked action whitelist; memory heavy but simple; partialize via key filtering to bound size.
Patch-based: capture Immer forward+inverse patches per action; apply inverses for undo, forwards for redo — orders of magnitude smaller for big normalized graphs. Hard parts to articulate: grouping rapid actions into logical steps (debounce windows / transaction markers), cross-slice atomicity (single history entry spanning slices via root wrapper), excluding volatile keys, and coalescing server reconciliations so network truth doesn't create undo steps.

Q5How would you implement a distributed-safe optimistic mutation engine in Redux?

Components:

pendingMutations: { [entityId]: Queue<Op> } persisted slice; ops carry clientToken, baseRev.
Reducer applies op optimistically AND bumps local rev; selector layer merges server cache beneath pending overlays.
On fulfillment: replace overlay with canonical entity (rev from server); conflicts (server rev > baseRev) route to rebase strategy: field-level merge where user-touched fields win, else surface resolution UI.
Refetch reconciliation must reapply pending overlays post-merge — implement as a single reconcileEntity helper ALL cache writes funnel through. Failure edges: abandoned tokens GC'd by TTL sweeper; double-submit prevented by token uniqueness per logical intent.

15 More Hard Questions Locked