The mobile round: the backend boundary, the failure modes and how to practise

How much backend to talk about is the judgement call candidates get wrong in both directions, and both directions cost real marks. It is also the first of the four failures that account for most of the low scores in this round. Each of those failures produces a specific conclusion in the interviewer's notes, and each is entirely avoidable.

This lesson starts at the server boundary, works through the failures, and ends with how to use the rest of the course so that you stop making them. The practice protocol at the end matters more than any single design in the course.

Direction one: designing a backend nobody asked for

The candidate hears "design a chat app", draws a load balancer, and spends the next fifteen minutes on message-store sharding and a fan-out service. At minute twenty they have a respectable distributed system and have not drawn a single thing that runs on a phone.

This is the more common error, because it is what candidates have practised. What the interviewer concludes is not "they know backend" — it is "they do not know what this role is".

Direction two: refusing to engage with the server at all

The opposite failure. Asked how messages reach the app, the candidate says "that is the backend team's problem". It reads as someone who cannot collaborate across the boundary, and it makes the API contract — an axis you are scored on — impossible to discuss.

The script

Say this at roughly minute eight, once requirements are agreed:

"I'm going to specify the API contract I'd want from the server — the endpoints, the payload shape, and where I'd push for a design change. I'll assume the server side is solved unless you'd like me to go into it. Does that split work for you?"

Four things happen. You have shown you know the boundary. You have signalled that you can specify what you need from another team. You have handed the interviewer an easy way to redirect you. And you have protected your remaining time.

Roughly one interviewer in four takes the offer and asks for ten minutes of server design. That is a good outcome — you invited it, and you now know it is wanted.

Where server detail is genuinely expected

Some server behaviour is part of the client design and should be discussed without hesitation:

• The pagination style, because cursor versus offset changes what the client can do.
• Idempotency support, because the client cannot retry a write safely without it.
• A change token or delta endpoint, because sync is impossible without one.
• Push delivery, because the client depends on the payload shape and on what a push means.
• Image dimensions and thumbnail URLs in payloads, because layout depends on them.

Each of those is a request from the client to the server. Framing them that way — "here is what I need from the API and why" — is exactly the collaboration the round is testing.

The four failure modes

Getting the backend boundary wrong is the first of four failures that dominate the low scores. Each one leads the interviewer to a conclusion about your experience rather than your knowledge.

Failure 1: designing a backend nobody asked for

What it looks like: twenty minutes of server architecture, five minutes of app. What the interviewer concludes: this person has prepared for a different interview. The fix: the script above, delivered by minute eight.

Failure 2: ignoring offline entirely

What it looks like: a complete design in which the network is never absent. No mention of what a user sees on a train, no queue for unsent actions, no cached content. What the interviewer concludes: this person has not shipped an app that real people used on a real network.

This is the most damaging failure of the four, because offline is the course's defining concern. An interviewer will usually prompt once — "what happens with no connection?" — and whether you needed the prompt is itself recorded.

The fix: raise offline yourself, in the requirements step, before anyone asks. Even a negative answer scores: "search will not work offline; the user sees their last results with a stale banner and a retry" is a design decision. Silence is not.

Failure 3: no persistence strategy

What it looks like: data arrives from the network, is held in memory, and is never written anywhere. The candidate has not said where anything lives between launches. What the interviewer concludes: every screen in this app is a spinner, and everything is lost the moment the operating system reclaims the process. The fix: name the store for each kind of data — database, files, key-value, secure store — as you go. Local persistence is the vocabulary.

Failure 4: treating the network as reliable

What it looks like: requests with no timeouts, retries with no backoff, writes retried blindly, and no distinction between "no connectivity" and "the server returned an error". What the interviewer concludes: this person will write the duplicate-charge bug.

The quieter fifth failure

No numbers. A design with no quantities in it — no page size, no cache ceiling, no timeout, no update frequency — reads as theoretical even when the structure is right. Attach a figure to every choice, and say where the figure came from.

How to use this course

Knowing the failures does not stop you making them under a timer. Practice does, and the way you practise matters more than how much you read. This course is eleven sections (23 lessons) and about nineteen hours of reading, and the order it is written in is not the order that produces the best results.

The sequence that works

Read Sections 1–3 straight through, in order. They are the shared vocabulary. Section 3 is long — 180 minutes — and it is the one that carries the course. Do not skim it to get to the case studies, because the case studies assume it in every paragraph.

Then, for each case study in Sections 4–10: attempt it first. Set a 45-minute timer, take a blank page, and design it before reading a word of the lesson. Then read, and mark the gap.

That gap is the actual product of this course. Reading a design you did not attempt produces recognition — "yes, that makes sense" — which feels like learning and is not. Attempting it first produces the specific, uncomfortable knowledge that you forgot to mention offline again, which is what changes your behaviour in the room.

The 45-minute practice protocol

1. Minutes 0–5: write down the clarifying questions you would ask. Answer them yourself, plausibly.
2. Minutes 5–10: the API contract. Actual endpoints, actual payload fields.
3. Minutes 10–20: the client architecture. Draw the layers.
4. Minutes 20–30: data flow and persistence. What is stored, where, for how long.
5. Minutes 30–40: pick a component and go deep.
6. Minutes 40–45: the six constraints — network, battery, memory, storage, background limits, process death.

Then read the lesson and mark every step where you were thinner than it is.

Reading the platform notes

The main text is platform-neutral, and code is pseudocode. iOS and Android specifics are in Platform specifics callouts, so if you work on one platform you can read your half and skim the other. Reading both is worth the small extra time — interviewers do ask "how would this differ on the other platform", and a one-sentence accurate answer is a strong signal.

The rest of the structure

Section 7 (Pagination Library) is deliberately unlike the others: it designs a library for other developers rather than an app, and the shape of the section is different because the shape of the problem is. Section 11 (Quick Reference Cheat Sheet) is a cheat sheet, kept at the end where a summary belongs — read it after the case studies, then again the day before an interview.