##### Question Compare Redux with more modern front-end state and data management approaches, and propose an end-to-end strategy. Concretely: for a React single-page app that consumes multiple APIs and must support **offline viewing, pagination, optimistic updates, and error retries**, design how you would manage local UI state and the server cache. Address the following: 1. **Modern data-management principles.** Lay out the principles you'd follow: separating state by source and lifecycle, co-locating state with its consumers, minimizing global state, embracing caching semantics (fresh vs. stale), optimistic UI with safe rollback, thoughtful normalization, the URL as a state store, and real-time/offline readiness. 2. **Client state vs. server state.** Define the distinction and give examples of each (e.g. modal open/close and form inputs vs. restaurants, menus, orders, and delivery status). Explain where each should live and the heuristics for deciding. 3. **Tooling comparison and trade-offs.** Compare Redux / Redux Toolkit (and RTK Query), React Query (TanStack Query), SWR, Zustand, Recoil, MobX, and native Context across: boilerplate, learning curve, performance (render churn, selectors, memoization), caching and invalidation, normalization, optimistic updates, error handling and retries, testing, and type safety. 4. **Caching and invalidation patterns.** Discuss structured query keys, staleTime/cacheTime tuning by data volatility, and invalidation on writes and on real-time (WebSocket/SSE) updates. 5. **Pagination.** Handle both offset pagination (keepPreviousData to avoid flicker) and cursor/infinite lists (useInfiniteQuery with getNextPageParam). 6. **Offline support.** Persist the query cache (IndexedDB) plus a Service Worker for static assets; queue mutations in an outbox with idempotency keys and background sync; describe a conflict-resolution policy. 7. **Performance.** Reduce re-renders with selectors, shallow compare, select-derived slices, list virtualization, and memoization. 8. **Error handling and retries.** Define retry/backoff policy (retry network/5xx, not 4xx), optimistic-update rollback, error boundaries, and a centralized fetcher with 401 token refresh. 9. **Testing and type safety.** Outline unit/integration/E2E coverage with MSW, end-to-end TypeScript types (codegen for OpenAPI/GraphQL), and runtime validation (zod/io-ts) at API boundaries. 10. **Incremental migration plan from Redux.** Propose a feature-by-feature, strangler-fig migration from an existing Redux codebase, including interoperability during the transition, feature flags, and risk mitigation.

DoorDash software-engineer onsite front-end question: compare Redux with modern state and data management approaches (Redux Toolkit/RTK Query, React Query, SWR, Zustand, Recoil, MobX, Context) and design an end-to-end strategy for a React SPA that needs offline viewing, pagination, optimistic updates, and error retries. It tests separating client UI state from server cache, caching/invalidation, performance, type safety, testing, and an incremental migration plan off Redux.

How do I approach Other / Miscellaneous interview questions?

Other / Miscellaneous questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master other / miscellaneous interviews.

What difficulty level is this interview question?

This is a hard difficulty Other / Miscellaneous question, commonly asked during Onsite rounds at DoorDash.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at DoorDash during technical interviews.

Compare front-end state management approaches

Question

Compare Redux with more modern front-end state and data management approaches, and propose an end-to-end strategy.

Concretely: for a React single-page app that consumes multiple APIs and must support offline viewing, pagination, optimistic updates, and error retries, design how you would manage local UI state and the server cache. Address the following:

Modern data-management principles. Lay out the principles you'd follow: separating state by source and lifecycle, co-locating state with its consumers, minimizing global state, embracing caching semantics (fresh vs. stale), optimistic UI with safe rollback, thoughtful normalization, the URL as a state store, and real-time/offline readiness.
Client state vs. server state. Define the distinction and give examples of each (e.g. modal open/close and form inputs vs. restaurants, menus, orders, and delivery status). Explain where each should live and the heuristics for deciding.
Tooling comparison and trade-offs. Compare Redux / Redux Toolkit (and RTK Query), React Query (TanStack Query), SWR, Zustand, Recoil, MobX, and native Context across: boilerplate, learning curve, performance (render churn, selectors, memoization), caching and invalidation, normalization, optimistic updates, error handling and retries, testing, and type safety.
Caching and invalidation patterns. Discuss structured query keys, staleTime/cacheTime tuning by data volatility, and invalidation on writes and on real-time (WebSocket/SSE) updates.
Pagination. Handle both offset pagination (keepPreviousData to avoid flicker) and cursor/infinite lists (useInfiniteQuery with getNextPageParam).
Offline support. Persist the query cache (IndexedDB) plus a Service Worker for static assets; queue mutations in an outbox with idempotency keys and background sync; describe a conflict-resolution policy.
Performance. Reduce re-renders with selectors, shallow compare, select-derived slices, list virtualization, and memoization.
Error handling and retries. Define retry/backoff policy (retry network/5xx, not 4xx), optimistic-update rollback, error boundaries, and a centralized fetcher with 401 token refresh.
Testing and type safety. Outline unit/integration/E2E coverage with MSW, end-to-end TypeScript types (codegen for OpenAPI/GraphQL), and runtime validation (zod/io-ts) at API boundaries.
Incremental migration plan from Redux. Propose a feature-by-feature, strangler-fig migration from an existing Redux codebase, including interoperability during the transition, feature flags, and risk mitigation.

Question

Compare Redux with more modern front-end state and data management approaches, and propose an end-to-end strategy.

Modern data-management principles. Lay out the principles you'd follow: separating state by source and lifecycle, co-locating state with its consumers, minimizing global state, embracing caching semantics (fresh vs. stale), optimistic UI with safe rollback, thoughtful normalization, the URL as a state store, and real-time/offline readiness.
Client state vs. server state. Define the distinction and give examples of each (e.g. modal open/close and form inputs vs. restaurants, menus, orders, and delivery status). Explain where each should live and the heuristics for deciding.
Tooling comparison and trade-offs. Compare Redux / Redux Toolkit (and RTK Query), React Query (TanStack Query), SWR, Zustand, Recoil, MobX, and native Context across: boilerplate, learning curve, performance (render churn, selectors, memoization), caching and invalidation, normalization, optimistic updates, error handling and retries, testing, and type safety.
Caching and invalidation patterns. Discuss structured query keys, staleTime/cacheTime tuning by data volatility, and invalidation on writes and on real-time (WebSocket/SSE) updates.
Pagination. Handle both offset pagination (keepPreviousData to avoid flicker) and cursor/infinite lists (useInfiniteQuery with getNextPageParam).
Offline support. Persist the query cache (IndexedDB) plus a Service Worker for static assets; queue mutations in an outbox with idempotency keys and background sync; describe a conflict-resolution policy.
Performance. Reduce re-renders with selectors, shallow compare, select-derived slices, list virtualization, and memoization.
Error handling and retries. Define retry/backoff policy (retry network/5xx, not 4xx), optimistic-update rollback, error boundaries, and a centralized fetcher with 401 token refresh.
Testing and type safety. Outline unit/integration/E2E coverage with MSW, end-to-end TypeScript types (codegen for OpenAPI/GraphQL), and runtime validation (zod/io-ts) at API boundaries.
Incremental migration plan from Redux. Propose a feature-by-feature, strangler-fig migration from an existing Redux codebase, including interoperability during the transition, feature flags, and risk mitigation.

Compare front-end state management approaches

Quick Overview

Compare front-end state management approaches

Question

Write your answer

Compare front-end state management approaches

Quick Overview

Compare front-end state management approaches

Question

Write your answer