If you are preparing for a mobile system-design interview, good material is scarce. Search "system design interview" and the first page is backend material: sharding, CAP, leader election. Search "mobile system design interview" and you get scattered Medium posts, a handful of YouTube videos (some are good), and a few courses. None of that is a full prep loop.

returnzero is that loop for Android-focused mobile system design. Core Concept primers build the platform vocabulary. App and SDK system-design articles walk through the interview shapes panels use, against real device constraints. Together the primers, walkthroughs, and graded practice read like an android system design course: the platform vocabulary, the interview designs you will be asked to produce, and a coach that grades you on them. Each article has a Guided Practice button: structured guidance through the interview (requirements → APIs → high level design → deep dives) with an AI coach that grades each step and debriefs you against the article. The practices are tuned to teach the approach (what to decide in which order, how to talk trade-offs), so you learn and practice, not just recall from articles.

What is a mobile system-design interview?

A 45-60 minute conversation where the interviewer drops an ambiguous prompt ("design a photo gallery app", "design an image loading library", "design the offline mode for a messenger") and you lead the design. The panel does not expect one correct architecture. It expects a defensible answer, anchored in real platform constraints (memory budget, battery, lifecycle, OS-imposed limits) and laid out as a sequence of decisions you can justify when pushed. The interview designs you produce are architecture responses to an open-ended prompt - not a single diagram, but a defended chain of trade-offs. The format is standard at senior+ for mobile-platform roles. This catalog is Android-focused; the rubric and framework generalize to iOS and cross-platform loops.

A passing answer is graded on how you reason under those constraints. Two candidates can defend opposite choices ("cache decoded bitmaps" vs "cache encoded bytes") and both pass; one candidate who hand-waves the same choice fails.

What the panel grades

Four rubric axes. Every panel rolls their own scorecard; the axes below are the consolidated shape across Google, Meta, Amazon, and Microsoft mobile loops as of 2026.

Problem navigation. Turns an ambiguous prompt into a list of testable requirements and calls out what is in scope, what is deferred, and which assumptions are explicit. Treats the prompt as a starting point until you and the interviewer lock requirements. Diving into a diagram before clarifying, or treating interviewer hints as interruptions, undermines this.
Solution design. Reaches for the right platform primitive without being told and names the trade-off when there is one. Avoid hand-waving "we'd cache it on disk" without naming Room vs DataStore vs an HTTP/image disk cache and what is stored, and avoid conflating generic concepts with platform-specific ones.
Mobile-platform excellence. Knows the platform's sharp edges and calibrates answers to the SDK level the company ships against. "Just add a CDN" on a device-side problem, or not knowing where a platform behavior changed, is the usual miss. For the backstory on how the Android stack got from Activities to Compose, see The Great Android Stack Reset.
Communication. Thinks out loud, narrates trade-offs, accepts interviewer redirects gracefully, and asks "do you want me to go deeper here or move on?" at natural breakpoints. Silence for two minutes mid-decision, arguing when redirected, or refusing to pivot when the interviewer says "let's assume X is given" are the usual tells.

Mobile system design shares two skills with backend system design: problem navigation (structuring an ambiguous prompt and designing around specific constraints and requirements) and API design (finding an efficient way for client and server to communicate).

It diverges on focus: application architecture that stays responsive and within budget on a constrained device. That means knowing the platform's sharp edges by API level, and reasoning under real device limits: lifecycle, memory, battery, offline behaviour, and network efficiency.

Types of mobile system-design interviews

Every problem on this site follows the same four-phase shape (requirements, surfaces, architecture, deep dives), with the phase times in each problem's badge summing to the interview total. Guided Practice on that problem uses the same shape as graded canvas steps. There are two types of system design questions.

Application system design

End-user apps. "Design a photo gallery app", "design a messenger", "design a music player." You own the full device-side stack from the screen down to the wire contract.

We focus on data model and API: the domain entities the app works with and the REST / WS / RPC surfaces it speaks to. Architecture follows a fixed six-lane structure (UI, Domain, Data, Local Storage, Network / Push / Sensors, Backend) so every App design in the catalog renders against the same frame and is comparable problem to problem. The Backend lane shows only the wire surfaces (REST API, WSS stream, FCM Push); the dispatcher, the geo-index, and the internal databases behind those surfaces are out of scope. The mobile candidate's job ends at the wire contract. Backend internals belong to the distributed-systems loop, not this one. Interview-winning depth usually sits in offline sync, optimistic UI, push handling, background work, and state-driven rendering.

Exemplars (article + Guided Practice on each): Photo Gallery App (practice), Messenger App (practice), Music Player App (practice).

SDK / library system design

Code that runs inside a host app. "Design an image loading library", "design a crash reporter SDK", "design a feature flag SDK." The host app calls your public API; you have no screen of your own.

We focus on API design: software other developers call. The SDK has to be self-contained. It must not crash the host app, must not overload it, has to load fast, and has to integrate in a few lines. Architecture depends on a single test: does the SDK have a genuine execution-context partition (code in context X cannot do Y because of when or where it runs)? If yes (crash reporter: the crash-time lane cannot allocate or run JVM code), the diagram lanes by execution context, left to right as the contexts fire. If no (an HTTP client: one call stack runs end to end), the diagram is a single pipeline with each stage annotated by its concern. Interview-winning depth usually sits in async-signal-safety, never-throw contracts at the SDK boundary, binary size discipline, init-time setup, and thread-safety across caller contexts.

The durability artifact that bridges two lifetimes (the .crash file, the analytics WAL, the last-known-good cache) goes on the boundary between the lanes it connects, not inside one lane. Putting it inside a single lane hides the handoff the design has to show.

Exemplars (article + Guided Practice on each): Crash Reporter SDK (practice), Image Loading Library (practice), Feature Flag SDK (practice).

How to start

New to the platform vocabulary: Mobile Core Concepts, then one App or SDK article above. Already fluent: hit Guided Practice on that article, then follow the debrief back into weak primers.

For the full curriculum - all 29 core concepts and 15 system design breakdowns on one page - see the Android system design prep guide.

Introduction