This question checks you understand why global state libraries exist and the modern way to use them.

The Redux mental model

Three principles:

1. Single source of truth — one store object holds app state.
2. State is read-only — you never mutate it; you dispatch an action (a plain object describing what happened).
3. Changes via pure reducers — (state, action) => newState, pure functions, no side effects.

This makes state changes predictable, traceable, and time-travel debuggable — every change is a logged action.

Redux Toolkit (RTK) — the modern standard

Classic Redux was infamous for boilerplate (action types, action creators, switch reducers, manual immutability). RTK is the official, recommended way and should be your default if you reach for Redux:

• createSlice — generates actions + reducer together.
• Immer built in — you "mutate" state.value = x in reducers; Immer produces the immutable update.
• configureStore — store setup with good defaults (DevTools, thunk).
• createAsyncThunk / RTK Query — async logic and data fetching/caching built in.

const counterSlice = createSlice({
  name: "counter",
  initialState: { value: 0 },
  reducers: {
    increment: (state) => { state.value += 1; }, // Immer makes this safe
  },
});

When you actually need it (the senior part)

Don't reach for Redux reflexively:

• Local/UI state → useState/useReducer.
• Low-frequency global state (theme, auth user) → Context.
• Server data (caching, refetch, sync) → React Query / RTK Query / SWR — most "global state" is actually server state.
• Genuinely complex, high-frequency, cross-cutting client state → Redux Toolkit, or a lighter store like Zustand / Jotai (less ceremony, no provider boilerplate).

The honest take: Redux solved a real problem, but a lot of historical Redux usage was server state that's now better handled by query libraries.

The framing

"Redux is one store, read-only state, changes only through actions run by pure reducers — that's what makes it predictable and debuggable. Modern Redux means Redux Toolkit: slices, Immer, configureStore, RTK Query — far less boilerplate. But the senior answer is knowing when not to use it: local state stays local, server state belongs in React Query, theme/auth fit Context, and only truly complex shared client state justifies a store — and even then Zustand is often enough."