The framework: time budget, clarifying questions and the API contract

Forty-five minutes is not long, and the failure that wastes it is not ignorance — it is drift. A framework's real job is to stop you spending twenty minutes on the part you find interesting and two on the part you are scored on.

This lesson lays out the seven steps and their time budget, then works through the first two in detail: the clarifying questions that open every round, and the API contract that most candidates hurry past. Together they take ten minutes, and they set up everything you draw afterwards.

The seven steps

Steps 6 and 7 are often run together as a single five-minute close, which is why you will sometimes see this described as six steps. The reason they are separate here is that candidates who merge them tend to drop step 7 entirely and finish on a list of constraints rather than on a conclusion.

Where the time actually goes wrong

Overrunning step 1. Clarifying questions feel productive and are easy to keep asking. At minute twelve with nothing drawn, you are behind and it is hard to recover. Cap it at five minutes, say "I'll assume the rest and flag assumptions as I go", and start drawing.

Skipping step 2. The API contract is five minutes for a disproportionate return — it is a whole scoring axis and most candidates hurry it.

Letting step 5 eat step 6. The deep dive is the most enjoyable part and it will expand to fill everything left. Watch the clock at minute forty regardless of where you are.

Announce the plan

Say the structure out loud at the start:

"I'll spend about five minutes on requirements, five on the API, then twenty on the client architecture and data flow, leave ten for a deep dive on whatever you'd like, and finish on constraints and edge cases."

Twenty seconds, and it buys three things: the interviewer knows you will cover their rubric, they can redirect you early instead of at minute thirty-five, and you have given yourself permission to move on when a step is done.

Offline in the framework: it is not a step. It appears in step 1 as a requirement, step 3 as the reason the architecture has the shape it has, step 4 as the persistence design, and step 6 as a constraint. If offline appears only in step 6, the design was not offline-first.

Step 1: mobile-specific clarifying questions

Every design interview starts with questions. The mobile round has its own set, and asking them is a signal in itself, because nobody asks "does this work offline" by accident.

The five that matter most

"Which platforms, and what is the minimum OS version we support?" This is not trivia. The minimum version decides which capabilities you can assume, and supporting a wide range means designing to the oldest behaviour and progressively enhancing.

"Does this need to work offline, and which parts?" Ask it early, and press for specificity. "The app works offline" is not an answer. "Reading works offline, sending queues, search does not" is a specification.

"What network conditions are we designing for?" A commuter app used on underground trains is a different product from an office tool on Wi-Fi. If the answer is "emerging markets", every payload decision changes.

"What devices? Are low-end phones in scope?" A four-year-old device with 3 GB of memory and a slow processor will kill your app for allocations a flagship absorbs. This question changes the image strategy, the list strategy, and the memory budget.

"Is there an existing backend, or am I designing the API too?" This is the boundary question from How much backend to talk about. Ask it, and the rest of the round is unambiguous.

The rest of the bank

Keep these in reserve and pick the three or four the prompt actually needs:

How to ask them well

Ask in a batch, then answer your own questions if the interviewer is non-committal. Many interviewers deliberately give vague answers to see whether you can make a reasonable call.

"I'll assume iOS and Android, both current-generation with two OS versions back, feed reading works offline but posting queues, and there's an existing backend I can request changes from. Shout if any of those are wrong."

That takes fifteen seconds, converts ambiguity into a specification, and demonstrates the judgement the vagueness was testing for.

Step 2: designing the API contract from the client's side

Once the requirements are pinned down, the API contract comes next. Five minutes on it returns more marks per minute than any other part of this round, and most candidates hurry past it to get to the diagram.

Why it scores so well

Everyone in the interview knows that a mobile client is the hardest consumer an API has: high latency, expensive bytes, no ability to hotfix, and a version of the app from eight months ago still in the wild. A candidate who designs an API as its consumer is demonstrating the exact thing the job requires — and it is rare, because most practice material teaches API design from the producer's side.

What a mobile client wants, and why

Batched, not chatty. The naive contract fetches a feed page, then calls once per post for its author, then once per post for its reaction count. Twenty posts becomes forty-one requests. At 150 ms each, even with six in parallel, that is well over a second of latency and forty-one radio transactions. Ask for the author and counts inside the feed response.

Paginated with cursors. Offset pagination shows duplicates when the list changes under the user. The lesson on pagination has the failure in detail; in the room, say "cursor, not offset" and give the one-line reason.

Minimal payloads, with an explicit shape. Every field costs bytes on a metered connection. Where a response has a heavy and a light form, ask for a fields parameter or two distinct endpoints rather than one payload that serves both badly.

Stable identifiers. Every entity needs an identifier that does not change, so the client can store it, deduplicate against it, and reconcile a refreshed page against stored rows.

Everything the layout needs, before the bytes arrive. Image width and height, video duration, item counts. Without these the client cannot size a row until the media loads, and the list jumps.

Server time, not client time. Return an authoritative timestamp on responses. Device clocks are unreliable, and anything ordered by them will occasionally be ordered wrongly.

A worked contrast

Chatty:

GET /feed?page=2            → [ {id, authorId, imageId}, ... ]GET /users/{authorId}       → × 20GET /images/{imageId}       → × 20

Client-shaped:

GET /feed?limit=20&cursor=<opaque>→ { items: [ { id, created_at_server,               author: { id, name, avatar_url },               text,               image: { url, width, height, blur_placeholder },               reactions: { count, mine } } ],    next_cursor: <opaque|null> }

One request instead of forty-one, the row can be laid out before any image arrives, and the client can deduplicate on id.

Pushing back, politely

You will sometimes be given a chatty API and asked to work with it. The strong answer does both: design the client to cope — parallel requests with a concurrency cap, aggressive caching of author records — and state what you would ask the backend team for, with the cost of not having it. "This costs us about a second on a cold feed load; I'd ask for the author embedded."