Android System Design Interview Questions & Answers

Android System Design Interview: Questions & Answers

Android system design interviews reward structured thinking more than a "correct" answer. The questions below are the ones that come up most often for senior/lead roles, each with a model answer showing the shape of a strong response — not a script to memorize.

1. Design the client architecture for a photo-sharing feed (Instagram-style)

Strong answer: Start with the data model (post, author, media URLs, engagement counts), then the source of truth (local DB, populated by network, observed by UI via Flow). Cover pagination (Paging 3 + RemoteMediator), image loading with sized requests and disk caching, and optimistic updates for likes/comments with rollback on failure. Close with background refresh via WorkManager under network/battery constraints.

2. How would you design an offline-first note-taking app?

Strong answer: Local database is the only thing the UI ever reads or writes to — every user action is a local write first. A sync engine (WorkManager-driven) pushes local changes and pulls remote ones on a schedule and on connectivity change. Each record needs a version or timestamp for conflict detection; last-write-wins is the simplest resolution strategy, though field-level merging is worth mentioning for more collaborative use cases.

3. How do you design efficient image loading at scale?

Strong answer: Three layers of caching — in-memory (LRU, fastest, lost on process death), disk (survives restarts, bounded by size not count), and network (HTTP cache headers respected). Always request an image sized for its target view, not the original resolution. Use a request-deduplication mechanism so ten simultaneous requests for the same URL become one network call. Libraries like Coil handle most of this, but knowing what they're doing under the hood is the actual signal an interviewer is looking for.

4. Design the local data layer for a chat application

Strong answer: Messages are append-mostly, so a local DB table indexed by conversation ID and timestamp works well, with pagination loading older messages on scroll. Sending needs an optimistic local insert with a "sending/sent/failed" status field, updated once the server acknowledges. Real-time updates arrive over a WebSocket or long-lived connection and get written straight into the same local table the UI observes — so live messages and paginated history render through one consistent path, not two.

5. How would you structure a multi-module Android app for a large team?

Strong answer: Split by feature, not by layer — a :feature:profile module containing its own UI, ViewModel, and domain logic scales better for parallel team work than a horizontal split into :ui/:domain/:data modules shared by everyone. Shared code (design system, networking, common models) lives in :core modules that feature modules depend on, never the reverse. This is also where you'd mention build time trade-offs — more modules means more Gradle configuration overhead, so it's worth justifying against actual team size, not applying by default.

6. Design a rate-limited API client with retry and backoff

Strong answer: An OkHttp interceptor is the natural place for this — it can inspect a 429 response, read a Retry-After header if present, and delay/retry using exponential backoff with jitter (to avoid every client retrying in lockstep after an outage). Cap total retries, and distinguish retryable errors (timeouts, 5xx) from ones that shouldn't be retried (4xx client errors, except 429).

7. What's your approach to background sync design?

Strong answer: WorkManager for anything deferrable and constraint-based (periodic sync, "retry when back online"). A foreground service only when the user needs to see ongoing progress in real time (an active upload, a call). Push notifications (FCM) to wake the app for time-sensitive server-initiated events, which then typically trigger a WorkManager job to actually fetch and persist the data, rather than doing the work directly in the FCM callback.

8. How do you design for testability in your architecture?

Strong answer: Depend on interfaces, not concrete implementations, at every layer boundary — repositories are interfaces in the domain layer, implemented in the data layer, so tests can substitute fakes. Keep the domain layer free of Android framework imports so use cases run as fast, JVM-only unit tests. Push side effects (network, DB, dispatchers) to the edges and inject them, rather than letting a ViewModel construct its own dependencies.

9. How do you handle pagination for a large dataset?

Strong answer: Cursor-based pagination over offset-based — offsets shift when items are inserted/deleted concurrently, causing skipped or duplicated items; a cursor (e.g. "give me items after this ID/timestamp") doesn't have that problem. On Android, Paging 3 handles the UI-side mechanics (prefetch distance, loading state, error retry) so you're not hand-rolling scroll listeners.

10. "Design Uber's driver location tracking" — a broader systems question

Strong answer: This tests whether you can reason beyond a single app. Key pieces: the client samples GPS location on an interval balancing accuracy against battery drain, batches updates rather than sending on every reading, and uses a low-latency channel (WebSocket, not repeated REST polling) to push location upstream. On the receiving end, this becomes a backend/systems question — but showing you understand the client's role (sampling strategy, battery constraints, offline buffering when connectivity drops) is exactly what an Android-focused interviewer wants to hear, even without a backend-deep answer.

How to actually use this list

Don't memorize the answers — memorized answers fall apart under a single good follow-up question. Instead, practice the shape: define the data model, name the source of truth, address consistency and offline behavior, then name the trade-offs you didn't choose. That structure transfers to almost any system design question you'll actually get asked.