How would you implement a robust offline-first repository?

WHAT THIS TESTS: The interviewer wants to see if you understand that in an offline-first architecture the local database is the single source of truth, not the network. They are looking for separation of concerns between data producers, the repository boundary, and observable data streams. Specifically they care about how you handle reads versus writes, how you propagate network updates without janking the UI, and how you recover from errors when connectivity returns.

A GOOD ANSWER COVERS: First, the repository should expose a Kotlin Flow or similar observable type that queries Room directly so the UI re-emits automatically on every local change. Second, network fetching should be triggered explicitly by a refresh mechanism or by a stale-cache check, not on every read, to avoid redundant API calls. Third, the network response should be written into Room within a transaction so that downstream observers receive a single coherent update rather than partial state. Fourth, you need a conflict resolution strategy such as server-wins, client-wins, or last-write-wins based on timestamps or version fields, especially if the user can mutate data offline. Fifth, enqueue retry logic with exponential backoff for failed syncs, and expose sync status or errors through a separate channel or state flow so the UI can show banners instead of silent failures.

COMMON WRONG ANSWERS: A major red flag is proposing that the ViewModel calls the API directly and then pushes the result into Room as an afterthought; this inverts the architecture and makes the UI depend on network timing. Another mistake is exposing suspend functions that return network payloads directly without a local persistence step, which breaks offline support entirely. Candidates also stumble by ignoring write conflicts, assuming the server state always overrides local changes without considering pending mutations queued while offline.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle pagination with the Paging library while keeping Room as the source of truth, or how to structure a sync queue for mutations made offline. They might also probe how you would test this repository, including faking the DAO and API service to verify emission ordering, or how to handle schema migrations when your conflict metadata changes.

ONE CONCRETE EXAMPLE: Imagine a task manager app. The repository exposes Flow of task list from a Room DAO. When the user opens the screen, the ViewModel collects this flow and shows cached tasks instantly. A refresh trigger launches a network request; on success the repository maps DTOs to entities and upserts them in a transaction. If the user edits a task while offline, the repository writes the change to Room with a pendingSync flag and schedules a WorkManager task to retry the upload with exponential backoff starting at ten seconds. When the sync succeeds the pending flag is cleared and the UI updates automatically via the same Flow.