Android System Design Interviews: What to Expect and How to Prepare

Android system design interviews test something generic "design a scalable backend" prep completely misses: can you architect a client that stays fast, correct, and battery-friendly on a real device with a flaky network — and survives the Android process lifecycle? If you walk in ready to talk about database sharding, you're prepared for the wrong round. Here's what Android interviewers actually probe and how to get ready.

Backend vs. mobile system design

A backend round is about a service at scale — throughput, partitioning, replication. A mobile round is about a client on one device: smooth UI, offline behavior, memory, battery, and surviving the OS killing your app. The server is usually assumed ("there's a REST API"); your job is everything from the network boundary to the screen. If you drift into QPS and sharding, a good interviewer will pull you back to the app.

What Android interviewers actually probe

• Offline and unreliable networks. Flaky and offline are the normal case. Does the app show a last-known-good state? Do writes queue and retry when connectivity returns?
• Memory and smooth scrolling. 60/90/120fps under a fast-scrolling list of images is a hard constraint. How do you load, downsample, cache, and evict Bitmaps? What's your working set?
• Battery and background work. Polling and radio use drain battery, and Android's Doze mode and App Standby restrict background execution. When and how do you sync?
• Process death and lifecycle. The OS can kill your process any time, and configuration changes (rotation) recreate UI. Does your state survive both? (This is the single most Android-specific theme.)
• The on-device vs. server boundary, made explicit.
• Privacy — runtime permissions, scoped storage, and what leaves the device.

The topics to be fluent in

Reason about these with specifics, not just names:

• Architecture — MVVM or MVI with unidirectional data flow; a repository layer as the single source of truth. Know why one pattern over another for the given scope (over-engineering is a ding).
• State holding — ViewModel + StateFlow/LiveData, and crucially SavedStateHandle to survive process death, not just config changes.
• Persistence — Room (or SQLite) as the local source of truth, DataStore for key-values, EncryptedSharedPreferences/Keystore for secrets.
• Concurrency — Kotlin coroutines + Flow, dispatchers, and main-safety.
• Networking — Retrofit/OkHttp; background transfers.
• Background work — WorkManager for deferrable, guaranteed work (respects Doze/constraints); foreground services for user-visible ongoing work. Knowing when to use which matters.
• Image loading — Coil/Glide-style: in-memory LruCache + disk cache, Bitmap memory management and downsampling, cancellation on view recycling, prefetching.
• Pagination — the Paging 3 library with a RemoteMediator bridging network + Room.
• Offline sync — an outbox/operation-log, idempotency keys with client-generated IDs, and conflict resolution.
• Media playback — ExoPlayer/Media3, player pooling and buffer management for video feeds.

A structure for the round

The same phased approach works — fill it with client concerns:

1. Clarify and scope — client-only or full-stack? Min SDK / device range? Offline required? Real-time? On-device data volume?
2. Requirements — a few prioritized features plus the mobile non-functional ones that matter here (offline, memory, battery, accessibility).
3. High-level architecture — the major blocks and an explicit on-device/server boundary.
4. Deep-dive — pick one: the feed pipeline, the image cache, the offline sync engine, the real-time channel. Go deep, including failure modes and process death.
5. Wrap up — trade-offs and what you'd revisit.

Common problems you'll see

Usually framed as "design the Android client for X":

• An image loading & caching library (Coil/Glide-style) — caching, Bitmap memory, cancellation.
• A Twitter-style feed — Paging 3, Room as source of truth, smooth scrolling, offline.
• A 1:1 chat client — real-time (WebSocket/FCM), offline send queue, media upload, receipts.
• An offline-first notes app — local source of truth, sync, merge conflicts.
• A short-video feed (TikTok-style) — ExoPlayer pooling, prefetch, memory under fast scroll.
• A client-side analytics SDK — batching, a crash-durable on-disk queue, privacy controls.

Mistakes that cost Android candidates

• Designing the backend instead of the client — the most common failure.
• Ignoring offline — if the design assumes a perfect network, you missed the defining constraint.
• Forgetting process death — "it's in memory" isn't an answer when the OS kills you; use SavedStateHandle + a persistent store.
• Hand-waving memory — "I'll cache images" without eviction, downsampling, or a budget won't survive a 10,000-item-list follow-up.
• Misusing background APIs — a raw thread or naive polling instead of WorkManager, ignoring Doze.
• Not practicing out loud — the round is a spoken back-and-forth, not an essay.

How to prepare

Study the client topics above, then practice full problems out loud under questioning — because that's the actual test, and generic backend mocks won't push you on the Android-specific themes. If you're also interviewing on iOS, note that the concerns are identical (offline, memory, lifecycle) even though the APIs differ — see our companion iOS system design guide.

Whitepad has a dedicated Android track (and iOS): a senior mobile interviewer that runs the phased round by voice, watches your whiteboard, and probes exactly the offline/memory/process-death themes above — with Android-idiomatic follow-ups (Room, WorkManager, Coil, ExoPlayer) — then scores you against a mobile rubric. Practice the round you're actually going to sit.