Course Content
Mobile System Design Interview
11 sections · 23 lessons
The mobile round: how it differs and what is scored
Same 45 minutes, same whiteboard, same open-ended prompt — and a completely different centre of gravity. In a backend system design round you design the servers. In a mobile system design round the servers are assumed to exist and work, and what you design is the application running on the phone.
This lesson sets out what that shift means in practice: where the time goes, who is interviewing you, and the rubric they are filling in while you talk. Knowing the rubric changes how you spend the 45 minutes, because you can deliberately produce evidence for each axis rather than hoping it comes up.
The same prompt, two different answers
"Design a news feed" is a standard prompt in both rounds. Here is roughly where the 45 minutes go in each.
| Backend round | Mobile round | |
|---|---|---|
| Scale estimation | 5 min — users, requests per second, storage | ~0 min — not your problem |
| Data storage | 10 min — sharding, replication, indexes | 8 min — the device database schema |
| Fan-out and ranking | 10 min — push vs pull, ranking service | 1 min — "server concern, noted, moving on" |
| Caching | 5 min — cache tier, eviction, hot keys | 8 min — memory and disk cache on device |
| The API | 3 min — mentioned | 6 min — designed, in detail, from the client's side |
| Client architecture | 0 min | 10 min — layers, data flow, source of truth |
| Offline and sync | 0 min | 8 min — the part that decides the outcome |
The rows that are near zero in one column are the load-bearing rows in the other. A candidate who prepares only from backend material walks in ready for the left-hand column and gets asked about the right.
The three things that move to the centre
Client architecture. Which layers exist, what each owns, and where state lives. This is the equivalent of "what services do we need" in the backend round, and it carries similar weight.
Offline behaviour. A server is either up or down. A phone is on a train, in a lift, on a metered roaming connection, and in aeroplane mode, all within one journey. What the app does during each of those is a design decision you will be asked to state.
The API contract, from the consumer's side. Not "how would you build this endpoint" but "what should this endpoint return so the app can render without a second call, without layout jumping, and without downloading three megabytes on a cellular connection".
Who is on the other side of the table
Usually a mobile engineer from the team hiring you, occasionally with a backend engineer in the room. That matters, because it tells you what will impress them. They have shipped an app that broke in a tunnel. They have been paged because a caching bug shipped and could not be hotfixed. Concrete, device-level judgement lands here in a way that a well-drawn sharding diagram does not.
What is being scored
That interviewer is usually filling in a rubric with four axes. The three topics above map onto them directly, and a fourth — platform judgement — is the one only experience supplies.
Axis 1: client architecture and separation of concerns
Can you divide an app into layers with clear responsibilities, and say what each layer is not allowed to do? The specific thing being checked is whether your screens talk to the network directly. If they do, the app cannot work offline and cannot be tested, and both follow from one architectural mistake.
Axis 2: handling the mobile constraints
Network variability, battery, memory, storage, background execution limits, and process death. Six items. The score is not whether you have heard of them but whether your design changes because of them, and whether you attach numbers.
Axis 3: API and data-flow design
Can you specify what the client asks for and what it gets back, and defend the shape? Can you trace one piece of data from a network response to a pixel on screen, naming every place it is stored on the way?
Axis 4: platform judgement
Do you know what the operating system will and will not let you do? This is where mobile experience becomes visible, and it is the axis that cannot be faked from a book.
Mid-level and senior on the same axis
| Axis | A mid-level answer | A senior answer |
|---|---|---|
| Architecture | Names three layers correctly | Names the single source of truth and defends why the screen never calls the network |
| Constraints | Mentions battery and offline | "A 30-second heartbeat wakes the radio 120 times an hour, so we switch to push when backgrounded" |
| API | Designs reasonable endpoints | Asks for image dimensions in the payload so layout does not jump, and explains the defect that prevents |
| Platform | Knows background work is restricted | States the limit unprompted, then designs so a six-hour suspension is normal |
The pattern across the right-hand column: the senior answer names the failure the decision prevents. That is the single most reliable way to move an answer up a level.