Prompt and scope
Design an offline-first product for people who regularly lose connectivity or pay a high cost for data. The answer should cover the target segment, critical jobs, offline behavior, sync expectations, conflict handling, MVP, and metrics.
Treat offline-first as a product promise, not a cache checkbox. Android guidance defines it as keeping all or a critical subset of core functionality usable without the internet; web.dev also stresses that users need clear status when a request cannot be completed.
What the interviewer is testing
They are testing segmentation, prioritization under constraints, trust in data state, and the ability to connect experience choices to outcomes. A strong answer separates “works offline” from “syncs later,” and makes the limits visible instead of promising the whole product without a network.
Questions to clarify before answering
- Which users, locations, devices, and connectivity patterns are in scope?
- What is the single job that must work offline: read, create, edit, capture, or share?
- Is data private, collaborative, regulated, or safety-critical?
- How stale can content be, and what happens when two devices edit the same item?
- Are storage, battery, data cost, and support capacity hard constraints?
A 30-second answer framework
“I would start with field workers who capture records in dead zones and sync when they return to coverage. The MVP lets them view assigned work, create drafts, attach small evidence, and see a clear sync state; it does not promise real-time collaboration offline. A local store is the immediate source of truth, with an outbox for idempotent uploads and explicit conflict review. I would measure task completion in disconnected sessions, successful sync rate, conflict resolution time, data usage, and support contacts before expanding the surface.”
Step-by-step deep dive
Step 1: Segment by connectivity and job
Do not target “everyone with bad internet.” Segment by the job, outage frequency, device capability, and cost of failure. A courier capturing proof, a clinician recording notes, and a traveler reading tickets need different offline guarantees.
Step 2: Rank jobs by offline value
Map each job by urgency, frequency, data size, and reversibility. Start with a narrow critical path: view a prepared work list, capture an input, save a draft, or retrieve a previously downloaded artifact. Defer collaborative editing and heavy media until the core loop is reliable.
Step 3: Make product states explicit
Use labels users can act on: saved on this device, waiting to sync, synced, conflict needs review, or upload failed. web.dev warns that a gray or ambiguous offline state can confuse users; show what is available now and what still requires a connection.
Step 4: Define the source of truth
For offline-first, keep a local data source as the immediate source of truth, then reconcile with the server. Explain which fields are authoritative, how versions are compared, and whether a user can undo a local change before sync.
Step 5: Design the sync contract
Queue mutations in an outbox with an idempotency key, retry only safe operations, and expose progress. Decide whether sync is automatic, user-triggered, or both. Preserve the user’s draft when the network fails; never make a successful local save look like a server-confirmed publish.
Step 6: Choose a conflict policy
For independent fields, merge field-by-field. For a shared status or quantity, prefer version checks and a review screen over silent last-write-wins. Ask whether conflicts are rare enough for manual resolution and whether the product can show the two versions without exposing sensitive data.
Step 7: Define the MVP and rollout
Limit the first release to one segment, one critical job, and a bounded amount of local data. Pilot behind a feature flag, test airplane mode and flaky latency, and add a recovery path before increasing retention or attachment size.
Step 8: Set outcome and guardrail metrics
Primary metrics can include successful completion of the target job while disconnected and time to a confirmed sync. Guardrails should include data-loss reports, unresolved conflicts, storage pressure, battery cost, data usage, and support contacts. Compare against an online baseline and segment by connectivity quality.
Trade-offs and boundaries
Trade-off 1: Freshness or availability
Showing a slightly stale work list may be better than showing nothing, but the timestamp and freshness promise must be visible. Safety-critical or financial data may require an online check instead of optimistic availability.
Trade-off 2: Local storage or privacy
More local data improves usefulness but increases exposure if a device is lost. Minimize fields, encrypt sensitive content, expire downloads, and give users a clear delete or sign-out behavior.
Trade-off 3: Automatic sync or user control
Automatic sync reduces effort; manual controls help users on metered data or shared devices. Offer defaults plus a visible pause or Wi-Fi-only option when the segment needs it.
Failure drills and evolution plan
Drill 1: The device stays offline for a week
Define what expires, what remains editable, and how much outbox data is retained. The user should know whether a local record is still valid or needs re-verification.
Drill 2: Two devices edit the same record
Show the conflict policy with a concrete example. Preserve both values when automatic merging would hide a material change, and measure how long resolution takes.
Drill 3: Sync succeeds but the server rejects the mutation
Show a failed state with the reason and next action. Keep the local draft, prevent infinite retries, and provide a safe correction path.
Common mistakes and follow-ups
Mistake 1: Treating offline as a technical feature list
Start with a user job and a failure cost. A service worker or local database is an implementation choice after the product promise is defined.
Mistake 2: Promising full parity
Name the critical subset and the deliberate exclusions. Unlimited offline scope creates storage, privacy, and support problems.
Mistake 3: Hiding sync status
Users cannot trust a save they cannot distinguish from a publish. Use action-based status, timestamps, and an inspectable retry path.
Mistake 4: Silent last-write-wins everywhere
It is simple but can erase meaningful work. Use it only where the business impact is low and the user can recover.
Mistake 5: Measuring only online retention
An offline feature can increase successful field work without changing daily opens. Instrument disconnected sessions, sync completion, and data-loss complaints.
Mistake 6: Launching without recovery drills
Test airplane mode, slow networks, full storage, clock changes, expired credentials, and interrupted uploads before broad rollout.