Question presented to candidate: "We are starting a new Angular 22 app with about a dozen feature areas and three teams. Some people want NgRx, some want NGXS, and some say services with signals are enough. Compare the main state-management options in Angular and tell me how you would decide."
What a strong answer should cover:
- First split the problem: local UI state, shared client state, and server state (cached API data) need different tools.
- Services with signals (or a BehaviorSubject): no dependency, minimal ceremony; discipline (private writable state, read-only views, methods) is up to the team.
- NgRx Store + Effects: Redux pattern, actions, pure reducers, selectors, DevTools, the most structure and the most code; strong for large, event-driven, multi-team apps.
- NgRx SignalStore (
@ngrx/signals): signal-based, composable features (withState,withComputed,withMethods,rxMethod, entities, events plugin), protected state by default; a middle ground. - NGXS (class and decorator based Redux style) and Elf (the successor recommended by the Akita team); Akita itself is no longer recommended for new work.
- Server state tools: Angular
resource()/httpResource()(stable in v22) or TanStack Query (Angular adapter still experimental) for caching, loading and error status. - Decision criteria: team size, how much state is truly shared, debugging/audit needs, async complexity, learning curve, bundle size, and consistency across teams.
Clarifying questions expected:
- "How much state is genuinely shared across features, versus local to a screen or derived from the server?"
- "Do we need time-travel debugging, undo, or a strict audit of state changes?"
Code / implementation expected: Optional β the same small feature written as a signal service and as a SignalStore (or store) to compare the ceremony.