How would you design resumable multi-step onboarding state management?

WHAT THIS TESTS: This question evaluates your ability to design durable state management for a growth-critical user flow. Interviewers want to see that you understand the difference between ephemeral client state and durable server state, can reason about offline behavior, and consider product metrics like abandonment and cross-device conversion. It also surfaces whether you think about compliance, since onboarding data often contains PII.

A GOOD ANSWER COVERS: First, propose a hybrid persistence layer. Use debounced server-side storage for cross-device resume and analytics, backed by localStorage or IndexedDB as an offline fallback. Second, define the schema granularity. Store step completion booleans, partially validated field values, and timestamps rather than a single progress integer. Third, address identity. Issue a temporary anonymous ID stored in a cookie or localStorage so unauthenticated users can resume after closing a tab, merging data after login. Fourth, explain trade-offs. Client-only storage is fast and reduces server load but is device-bound and vulnerable to cache clears. Server-only storage enables cross-device recovery and abandoned-session re-engagement but adds latency, requires infrastructure, and increases compliance scope. Fifth, mention conflict resolution. A last-write-wins strategy is usually sufficient for onboarding, but you should timestamp every save and optionally surface a UI prompt if divergent states are detected.

COMMON WRONG ANSWERS: Storing everything in sessionStorage is a red flag because it dies with the tab and ignores the device-switch requirement. Storing everything on the server without a client cache ignores the immediate tab-close scenario before a network request completes. Another anti-pattern is saving raw passwords or sensitive PII to localStorage. Failing to mention how anonymous users resume flow shows a lack of product thinking.

LIKELY FOLLOW-UPS: How would you handle two tabs open with different states? What is your GDPR strategy for partial submissions stored on the server? How do you re-engage users who abandon step three? At what granularity do you validate: per field, per step, or on final submit?

ONE CONCRETE EXAMPLE: Imagine a five-step onboarding checklist. A user completes steps one and two on mobile during a commute, then opens a laptop later. The server has persisted their state against an anonymous token. On the laptop, the app fetches progress and drops them on step three with pre-filled fields. Meanwhile, localStorage on the phone holds the same state as a fallback. If the user closes the laptop tab before the latest debounced save fires, the phone localStorage is irrelevant, but the server already holds the last explicit step transition. Auto-save triggers every three seconds or on blur, and a progress bar shows two of five steps complete to maintain motivation.

Source: reform.app