How would you structure Redux in a large application?
Assesses fundamental understanding of React conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
The recommended approach (and what Redux Toolkit is designed around) is a "feature folder" / "ducks" structure rather than splitting by technical type (actions/, reducers/, constants/):
src/
app/
store.js # configureStore() + root reducer wiring
features/
posts/
postsSlice.js # createSlice: reducer + actions + thunks
postsSelectors.js # createSelector-based selectors
PostList.jsx # components using useSelector/useDispatch
users/
usersSlice.js
usersSelectors.js
Guidelines:
- Colocate a feature's slice, selectors, thunks, and components in one folder instead of scattering related code across parallel
actions/reducers/constantsfolders. - One slice per domain concept (posts, users, cart), created with
createSlice, combined once instore.js. - Keep components decoupled from the store shape by reading data only through selectors, never
state.posts.entitiesdirectly in a component. - Normalize related/nested data (see Q336) so features can reference each other by ID instead of duplicating data.
- Use RTK Query (or a dedicated API slice) for server state, and keep hand-written slices for genuine client/app state.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.