Learn one answer skeleton, then run it on a different problem every day for seven days. The skeleton has seven parts: requirements, one scale estimate, the API, the data model, the high level diagram, one deep dive, one trade-off. On days 1 and 2 you are allowed exactly five components on the whiteboard and nothing else. Below are the seven problems, the verbatim opening 60 seconds, and the four follow-up questions interviewers use to test whether you understood your own diagram.
The skeleton, and what each part has to produce
Most people fail this round by running out of order, not out of knowledge. They draw before they scope, or they list technologies instead of choosing between two. The skeleton fixes the order, and every part has to produce something you could point at.
Requirements
Two or three core flows written on the board, plus one thing you explicitly cut. Cutting out loud is the point. "Search, analytics and moderation are out unless you want them in."
One scale estimate
One number that changes a decision, not a page of arithmetic. Usually writes per second or bytes per day. If the number would not move a single box on your diagram, do not compute it.
The API
Three endpoints, no more. Method, path, the parameters that matter, what comes back. This is where you find out whether you and the interviewer had the same product in mind.
The data model
Two or three tables, each with a primary key and one index. Say which access pattern the index exists for. Skipping this is why deep dives collapse twenty minutes later.
The high level diagram
Boxes and arrows for one request path, drawn in the direction the data flows. Narrate every box as you draw it, including why it is there at all.
One deep dive
Pick the component carrying the hard part and take it apart properly. One component understood beats eight boxes named.
One trade-off
Name the axis, pick a side, state the price you are paying, say what would make you switch. Four sentences, spoken before anyone asks you for them.
The exact opening 60 seconds
Say this, in these words, with the brackets filled in. It costs a minute and buys the interviewer a cheap chance to redirect you before you have drawn anything wrong.
Before I draw anything I want to pin down scope, size it, and agree an API. That is about five minutes. My reading is that the core flows are [flow A] and [flow B], and I am treating [feature X] as out of scope unless you want it in. I am going to assume [N] daily active users and check that against the write rate, because that number is what decides whether one database is enough here. On non functional requirements I care most about [latency, or durability, or consistency], and I am willing to trade [the other one] for it. Does that scope match what you had in mind, or would you rather I start somewhere else?
Filled in for day 3: the flows are post an update and load a home timeline, search and ads are out, 300 million daily actives at an average of 200 follows, and I care about timeline read latency more than about seeing a post the instant it is written. Four jobs done in one minute. You named a budget, made a cut, exposed an assumption, and handed control back.
Days 1 and 2: five components, nothing else
The rule is mechanical. For the first two days your whiteboard may contain a load balancer, a cache, a queue, a replicated database and an object store. Nothing else. No CDN, no sharding, no consistent hashing, no service mesh, no vendor product names, no reciting CAP.
- Load balancer. Spreads requests across identical app servers. Drawing it is how you commit to stateless servers, and that is a claim you may be asked to defend.
- Cache. Read relief. You must say what you cache, what the key is, and how an entry becomes wrong. A cache with no invalidation story is a bug you drew on purpose.
- Queue. Turns a slow or failure-prone step asynchronous and absorbs bursts. Whatever sits behind it is now eventually consistent, so say that out loud.
- Replicated database. Primary takes writes, replicas take reads. Replication lag is your entire consistency answer at this level, and it is enough.
- Object store. Large immutable blobs. The database keeps the key and the metadata, never the bytes.
The constraint is not humility, it is diagnostic. If you cannot get a URL shortener or an image host out of those five boxes, a sixth box will not save you, and an interviewer spots borrowed vocabulary in about ninety seconds. From day 3 you may add whatever the problem genuinely needs, and each addition has to be justified in one sentence as you draw it.
The seven days, one problem each
One problem per day, 60 minutes, in this order. Do not swap in something you have already solved, because the skeleton is what you are rehearsing, not the answer.
| Day | Problem | Allowed on the board | Deep dive | Trade-off drilled |
|---|---|---|---|---|
| 1 | URL shortener | Five primitives only | Key generation and collisions | Cache TTL against invalidation on write |
| 2 | Image and file host | Five primitives only | Upload path and the handoff to the object store | Synchronous upload against queue plus worker |
| 3 | Home timeline feed | Five plus fanout workers | Fanout on write, fanout on read, hybrid for large accounts | Read latency against write amplification |
| 4 | Group chat | Five plus a persistent connection layer | Message ordering and delivery receipts | At least once delivery against exactly once |
| 5 | Seat booking for events | Five plus a reservation store | Holding a seat for ten minutes without double selling it | Strong consistency against availability |
| 6 | Video upload and playback | Five plus CDN and transcoding workers | The transcode pipeline and what the player fetches first | Storage cost against startup latency |
| 7 | Redo day 3 or day 5 cold, no notes | Whatever it needs, each box justified | The one you fumbled the first time | All four questions, asked aloud and answered aloud |
Run every day on the same clock: five minutes requirements, five estimate, five API, five data model, ten on the diagram, fifteen on the deep dive, five speaking one trade-off. Spend the final ten minutes reading one written treatment of that same problem and writing down only what you missed. That last block is the one that compounds, and it is the one people skip.
The four trade-off questions, and the shape of an answer
Follow-ups in this round are nearly always one of four. Rehearse them against the day's own diagram, out loud, before you read anyone else's version.
- What falls over first at ten times the traffic? Name one component, not a list, and describe what the symptom looks like to a user.
- That box just died. What does the user see, and for how long? Answer it separately for the primary database, the cache and the queue. Losing a cache should be slow, not broken.
- A user writes, then reads one second later. Do they see their own write? The read-your-own-writes question, and it catches nearly everyone who drew replicas without thinking about them.
- Do you actually need that component? What breaks if I delete it? If you cannot answer, you copied it off a diagram instead of reasoning your way to it.
Every answer takes the same four sentences: name the axis, pick a side, state the price, name the trigger to revisit. Question 3 on day 3, worked: "Not from a replica, no. Someone who posts and immediately refreshes might hit a replica a couple of hundred milliseconds behind and see nothing. I would read an author's own recent posts from the primary, or merge the new post in on the client, and leave every other reader on the replicas. The price is extra load on the primary, and I would revisit it if author reads grew past a few percent of traffic."
Where a week is not enough, and where a copilot is the wrong tool
Seven days buys structure and vocabulary. It does not buy judgment, and interviewers grade those separately. At mid level the structure carries most of the score, so this plan is worth real points. At senior and staff level the round is mostly about which failure you chose to accept and why, and a week cannot manufacture experience you have not had. If you have never operated a service in production, expect the deep dive to be where you thin out, and plan to say so plainly rather than bluffing a number you cannot defend.
Live tooling is a poor fit for this specific round, and it is worth being blunt about that. System design is a conversation about marks you made on a shared board, where the interviewer points at your own arrow and asks what happens when it breaks. OfferPilot AI drafts a speakable answer from the interviewer's audio in roughly a second, which helps with a definition you have blanked on, and it cannot defend a diagram you never reasoned through. It is Windows 10 and 11 only, with no macOS, Linux, mobile or browser build. Its overlay is excluded from screen capture at the operating system level, so it stays out of Zoom, Teams, Meet and recordings, but that hides nothing from a webcam, a lockdown browser, a proctor sitting in the room, or a phone pointed at your desk. Where a round's rules forbid assistance, treat this as preparation only.
Two things to do tonight, before day 1
Write the seven parts on an index card and keep it in view for all seven sessions. Then open the drawing tool you will actually use in the interview, usually Excalidraw or the platform's own whiteboard, and draw six boxes in it once, so you are not learning a canvas at minute four. If the loop also has a behavioural round, build that question list with the company Q&A generator and skim the company question banks on a rest evening, never during a design hour.
Start day 1 tonight, keep the five component rule honest for 48 hours, and say the opening 60 seconds out loud every single day. If you want a companion for the read-back block, the free tier gives 5 minutes a day with no card, and the paid tiers sit on the pricing page.