Run the clock like this: 0 to 6 requirements and scope cuts, 6 to 10 estimation, 10 to 18 API and data model, 18 to 30 the high-level diagram, 30 to 42 one deep dive on a bottleneck you name yourself, 42 to 45 trade-offs. The blocks matter less than the hand-offs. Say the budget out loud before each one, because a candidate who announces "I'm going to spend five minutes on requirements before I draw anything" gets corrected at minute two instead of failing quietly at minute thirty. Below: the whole script worked on a news feed, and what to cut when you are ten minutes behind.
The clock, and the sentence that opens each block
Almost every failed round is a timing failure rather than a knowledge failure: twenty-two minutes of requirements, a rushed diagram, no deep dive, no trade-offs. Each sentence below hands the interviewer a cheap two-second window to redirect you.
| Minutes | What you produce | Say this to open it |
|---|---|---|
| 0-6 | A functional list, an explicit out-of-scope list, one non-functional target with a number on it. | "I'm going to spend five minutes on requirements before I draw anything, because what we cut changes the diagram. Stop me if you want a different slice." |
| 6-10 | Two or three numbers, rounded hard, one of which visibly forces an architectural choice. | "Requirements are locked. Four minutes on numbers, and I'm really after one figure, because that is the one that decides the shape." |
| 10-18 | Two endpoints written out, three tables, a named shard key for each. | "Before the boxes, let me pin the contract. Two endpoints and three tables, about eight minutes, then I'll draw." |
| 18-30 | Write path, then read path, in that order. Six to eight boxes, no more. | "I'll draw the write path first, then the read path. I'm deliberately leaving one gap in it that I'll come back to." |
| 30-42 | One component taken apart: failure mode, mitigation, cost of that mitigation. | "This holds until a ten-million-follower account posts. That is the bottleneck, and I'd like twelve minutes on it. Does that work, or is there something you'd rather see?" |
| 42-45 | Three trade-offs where you name the side you gave up, plus one open question. | "Three minutes left. Let me name what I traded away and what I'd revisit first." |
Glance at the clock at 10, 18, 30 and 42 only. Checking more often reads as anxiety and costs you the thread.
Worked end to end: design a news feed
0-6: requirements, and the cuts said out loud
In scope: create a post with text and one optional image, follow and unfollow, load a home timeline of the people you follow. Out of scope, said explicitly because unstated scope gets assumed against you: ranking, ads, stories, direct messages, comment threads, notifications. Non-functional, with numbers on them: feed loads under 200ms at p99, the feed may be seconds stale, posts must never be lost. Say that last pair aloud. "I'll trade freshness for availability on the read path, but not durability on the write path" sets up every decision that follows.
6-10: estimation, one number that matters
300M daily users opening the feed 10 times a day is 3B reads a day, roughly 35k per second, call it 100k at peak. One user in ten posts twice: 60M posts a day, under 1k writes per second. That 50 to 1 ratio is a hint, not the answer. The figure that decides everything is fanout: 60M posts times an average 200 followers is 12 billion timeline writes a day, about 140k per second sustained. Say it slowly. It is why fanout has to be asynchronous, why timelines live in a cache rather than behind a join, and why the design collapses on celebrity accounts.
10-18: API and data model
Two endpoints. POST /v1/posts, text plus an optional media id, with an Idempotency-Key header so a client retry does not double-post, returning 201 and a Snowflake id. GET /v1/feed?limit=20&cursor= returning items plus an opaque cursor, never offset pagination, because posts landing mid-scroll shift the window and hand the user duplicates. Three tables: posts sharded by post id, follows stored in both directions so neither lookup is a scan, timeline as a per-user capped list of about 400 post ids in Redis, a sorted set keyed on the Snowflake id. Timelines hold ids only and hydrate from a post cache, so a deleted post is not 200,000 rewrites.
18-30: the high-level diagram
Write path first: client, edge, post service, post store plus object storage for images, an event onto a durable log, then fanout workers that read the author's follower list and push the post id into each follower's timeline cache. Read path second, and deliberately dull: 20 ids from the timeline cache, hydrate from the post cache, fall back to the post store on a miss. Six or seven boxes total. Say what happens when one dies: if fanout workers lag, feeds go stale and nothing is lost, because the log still holds the events. Skip the search service and the recommender nobody asked for. Every extra box is surface area for a question you cannot answer.
30-42: the deep dive you choose yourself
Name it before they do. One post from a 10 million follower account is 10 million cache writes, which at 140k per second of fanout throughput backs the queue up for over a minute, and a few such accounts starve everyone else's feed. The fix is hybrid fanout: above a threshold, say 100k followers, skip fanout and write nothing. At read time take 20 ids from the user's own timeline, then for each celebrity they follow read recent posts from a small per-author cache and merge. Snowflake ids sort by time, so it is a k-way merge over integers. Then price the fix. Read work is now bounded by celebrities followed, usually under 50, but the threshold has to be dynamic, accounts crossing it in either direction need handling, and someone following 500 celebrities is a slow read you would cap. Handle unfollow with a read-time filter rather than a scan across millions of timelines, and an evicted timeline by rebuilding from per-author caches.
42-45: trade-offs, with the losing side named
Three, one sentence each. Fanout on write buys a fast read and costs enormous write amplification plus a feed that is seconds stale. Storing ids rather than bodies makes edits and deletes trivial and adds a hydration hop to every read. The hybrid threshold removes the celebrity spike and adds an operational knob that will be tuned wrong at some point. Then one open question: "with more time I'd look at losing a timeline cache shard, because at 12 billion writes a day, rebuilding cold is not free."
When you are ten minutes behind
You are behind if you hit minute 25 with no diagram, or minute 35 with no deep dive. Cut in this order, and narrate the cut so it reads as a decision rather than a collapse: "I'll compress the data model to a sentence so we still get a proper deep dive."
| Behind by | Cut this | Protect this |
|---|---|---|
| About 5 minutes | Two of your three estimates. Keep the fanout figure, drop storage per year. | The full diagram and a shortened deep dive. |
| About 10 minutes | The written data model. Say it instead: "posts sharded by post id, follows stored both directions, timelines as capped id lists in Redis." Fifteen seconds, no typing. | The deep dive, at full length. |
| About 15 minutes | Diagram breadth. Draw the write path and the timeline cache only, narrate the read path over it, skip the API beyond naming two endpoints. | One bottleneck dismantled, and 90 seconds of trade-offs. |
The deep dive and the trade-offs never get cut. Three boxes with one bottleneck taken apart properly scores above nine boxes with no depth, because the rubric has a row for depth and it is usually the row that separates a hire from a no-hire. If time runs out mid-dive, finish the sentence you are on and spend the last 30 seconds listing trade-offs. Never let the interviewer be the one who says time is up.
Where a copilot is the wrong tool for this round
A design round is not a sequence of questions with answers, it is 45 minutes of you steering a conversation while drawing, and live assistance fits it badly. Interview Copilot transcribes the interviewer on-device and drafts a speakable answer in about a second, which suits behavioural rounds and rapid-fire technical questions. Here the interviewer might speak for four minutes out of forty-five, so there is little for it to work with, and pausing to read a screen while you are meant to be narrating a diagram is conspicuous in a way a two-second thinking pause is not. Other limits, stated plainly:
- Windows 10 and 11 only. No macOS, no Linux, no mobile, no browser extension.
- Capture exclusion covers screen sharing and screen recording, nothing else. The overlay is excluded from screen capture at the operating system level, so it is absent from Zoom, Teams, Meet, OBS and screenshots while staying visible on your own monitor. It does nothing about a webcam, a lockdown browser, eye tracking, a second-device camera, or someone in the room.
- Depth is graded on the follow-ups. A hybrid fanout answer you did not reason your way to falls apart at the second question, and here the second question always comes.
- The rules belong to the company. Some interviews permit documentation and AI assistance, some do not. Read the instructions and ask when they are ambiguous.
The honest use of a tool here is before the round, not during it: rehearse the six hand-off sentences until they are automatic, then run the news feed once against a stopwatch. Everyone overruns somewhere, and it is almost always requirements.
Practise the clock, not the answer
Take four prompts, a news feed, a URL shortener, a rate limiter and a notification service, and run each to the same six blocks with a timer in view. The same fifteen sentences carry all four, which is the point: the framework travels even when the content does not. The question banks give you prompts to run against the clock, and the company Q&A generator builds a bank for a specific company and role, which matters because a payments team and a social team run this round very differently. OfferPilot AI's free tier is 5 minutes a day with no card, and paid plans start at $39 a month, metered on listening time only.