Answer like an architect.
Estimated time: about 6 minutes
Your goal is not to name the most libraries. Your goal is to show a reliable reasoning process that survives changing requirements.
The six-part answer structure
- Classify: local, shared client, server, URL, form, or workflow state.
- Assign ownership: identify the authoritative source of truth.
- Choose scope: keep state as close as practical to its consumers.
- Choose transitions: setters, reducer, mutation, or state machine.
- Choose synchronization: cache, invalidation, persistence, URL, or none.
- Discuss failure and performance: stale data, conflicts, rollback, subscriptions, and measurement.
Drill 1: collaborative document editor
Prompt: “Design state management for a collaborative editor with autosave, presence, offline edits, and a shareable document URL.”
Pause and answer aloud before revealing the outline.
Document content is server/domain state with synchronization concerns. The current edit buffer is client draft state. The document ID belongs in the URL. Presence is remote live state. Offline edits need a queue/conflict strategy, not just a global store. Model autosave and sync lifecycle explicitly.
Drill 2: checkout
Prompt: “How would you manage a checkout with address validation, payment authorization, retries, and back navigation?”
Use explicit workflow states, keep form drafts separate from saved order data, use server mutations for payment and validation, preserve or reset step state intentionally, and avoid optimistic UI for irreversible payment actions unless the semantics are extremely clear.
Drill 3: performance complaint
Prompt: “A dashboard becomes slow after adding a global Context. What do you do?”
Reproduce and profile first. Identify provider value identity and consumer scope. Split unrelated contexts, localize state, stabilize values where useful, and consider selector-based subscriptions only if measured work remains. Do not replace Context blindly.
Final self-check
Can you complete this sentence without naming a library first?
“The source of truth is ___; this value is ___ state; it should live ___; updates happen through ___; synchronization requires ___; the main trade-off is ___.”
If yes, you have the core interview framework.
Compact final answer
“I classify state before choosing a tool. Local UI state stays local; shared client state is lifted or placed in a store when coordination justifies it; server data belongs in a cache and synchronization layer; navigable state belongs in the URL; and complex workflows deserve explicit transitions. I define the source of truth, failure behavior, persistence, and subscription scope, then measure performance rather than optimizing from assumptions.”
Continue practicing
Use the previous lessons as reference material, then ask for a mock interview. I can play interviewer, interrupt weak assumptions, and score your answer on classification, ownership, trade-offs, and clarity.
Course core complete. Optional future lessons: SSR and hydration, offline-first state, concurrent React, and a real project case study.