Mobile System Design, A 5 Step Interview Framework
Five ordered steps turn an open-ended prompt into a controlled, 45-minute conversation, so neither you nor the interviewer gets lost.
Five ordered steps turn an open-ended prompt into a controlled, 45-minute conversation, so neither you nor the interviewer gets lost.
Structure is what keeps the interview from drifting#
Coding interviews have a single correct answer to converge on. System design does not, it invites many valid solutions, so the risk is a rambling conversation with no clear through-line. A fixed framework removes that risk: it gives you a default order to work in and a shared map the interviewer can follow.
The payoff is signal. When you move through predictable phases, the interviewer can tell where you are and judge how you think, instead of spending energy figuring out what you're even doing. The five steps below are the high-level shape; later chapters apply them to concrete apps.
The five steps, and the one loop that matters#
The flow is sequential with a single deliberate exception: architecture and deep dive form a loop. You draw the high-level design, dive into a component, learn something, and come back to revise the diagram. That back-and-forth is the point, not a detour.
Step 1 · Turn a vague prompt into a defined problem#
Prompts arrive broad on purpose, "Design a news feed app," "Design a pagination library." Your first job is to draw the boundary: what's in scope, what's out, and what you're free to assume. The interviewer's answers steer every technology choice and trade-off that follows, which is why no two interviews from the same prompt look alike.
Ask targeted questions across three angles. You're not trying to ask everything, you're picking the few clarifications that most change the design.
What are we building?
Surfaces functional vs. non-functional requirements and what's explicitly out of scope.
- Which features, screens, or critical user journeys are in scope?
- Are we pre-fetching data? Is authentication part of the design?
Who are we building for?
Pins down scale, usage patterns, and how performant the solution must be.
- How many daily active users, and what's the expected growth?
- MVP or final product?
- One region or worldwide? Used at home, or on a moving train?
What are the constraints?
Fixes the system boundary and narrows technology choices.
- Which platforms, iOS, Android, or both?
- Any existing systems or APIs the app must integrate with?
Step 2 · Nail the contract before the internals#
The API is the contract between your client and everything it talks to. Settling it early aligns your mental model with the interviewer's and gives the rest of the design something solid to build on.
| If you're designing… | Define |
|---|---|
| An app + backend | The communication protocols suited to each use case, plus the concrete endpoints involved. |
| A mobile library | The public API surface, how host apps initialize, configure, and call into your library. |
Alongside the endpoints or public API, sketch the data models that flow through them, JSON payloads, Swift structs, Kotlin data classes, or protocol buffers where efficiency matters. The models should make the data's structure and relationships obvious.
Step 3 · Prove the end-to-end flow with a diagram#
With the contract set, draw a high-level client architecture showing how the pieces fit. The diagram does two jobs: it confirms you have a complete path from user action to result, and it exposes the interesting spots worth examining more closely.
As you draw, flag components you expect to unpack in the deep dive. Those flags become your agenda for step 4.
The source describes this step conceptually without a fixed reference architecture; Figure 2 is an illustrative layering to make the step concrete.
Step 4 · Go deep where it counts#
This is where you earn the strongest signal. Work with the interviewer to spot bottlenecks and pull apart two to three components in real detail. Two to three is a target, not a rule, adjust to the problem.
- Pick the right components. Follow the flags you raised in step 3 and the interviewer's cues about what interests them.
- Keep refining the architecture. As decisions emerge, update the diagram so it always reflects the current design, this is the loop from Figure 1 in action.
- Manage the clock across topics. If the interviewer is curious about several things, split your time so each gets real attention rather than one swallowing the rest.
Step 5 · Close with judgment, not defensiveness#
Optional, and only if time allows, but a strong wrap-up shows you think about a design's limits, not just its happy path. Four moves:
| Move | What it signals |
|---|---|
| Summarize decisions | Recap the key trade-offs after a dense discussion so the interviewer leaves clear on your reasoning. |
| Show critical thinking | When asked about improvements, don't defend the design as perfect, name where it could evolve. Self-awareness reads as maturity. |
| Address edge cases | Raise failure points and error paths you hadn't covered, proof you think about reliability, not just the happy path. |
| Consider future scale | Discuss growth in users and in team size. It shows you weigh technical and organizational scaling together. |
Where the 45 minutes actually go#
You have 45 to 60 minutes and a lot of ground. A rough budget keeps you from spending the whole session scoping or running out of time before the deep dive. The deep dive gets the biggest slice by design, it's where the strongest signal lives.
| Step | Budget | Focus |
|---|---|---|
| 1 · Scope | 5–10 min | Fully understand the problem and set its boundary. |
| 2 · API | 5–10 min | How the app talks to the backend; core data models. |
| 3 · Architecture | 10–15 min | Main components and how they connect. |
| 4 · Deep dive | 15–20 min | The hardest technical challenges and implementation detail. |
| 5 · Wrap-up | 0–5 min | Recap decisions; discuss improvements and trade-offs. |