React Easy technical 0 views 1 min read

How would you structure Redux in a large application?

Peer-reviewed by HireXTech Technical Panel Updated for 2025/2026 hiring Editorial standards
Practise this track
Interviewer Expectations for this Question
01
Core Competency

Assesses fundamental understanding of React conventions, runtime behavior, and memory/performance considerations.

02
Evaluation Criteria

Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.

Comprehensive Model Answer Verified Solution

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:

  1. Colocate a feature's slice, selectors, thunks, and components in one folder instead of scattering related code across parallel actions/reducers/constants folders.
  2. One slice per domain concept (posts, users, cart), created with createSlice, combined once in store.js.
  3. Keep components decoupled from the store shape by reading data only through selectors, never state.posts.entities directly in a component.
  4. Normalize related/nested data (see Q336) so features can reference each other by ID instead of duplicating data.
  5. 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

  1. Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
  2. Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
  3. Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
  4. Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.
Related Topics & Skills
Spotted an error or have an alternative solution?