The System Design Interview: What the Interviewer Writes Down, Minute by Minute

Meta’s own candidate page says the design interview is 45 minutes long, and that the interviewer usually keeps the last five minutes for your questions. The page is dated October 6, 2022, and still said so when we read it on October 24, 2026. Google’s design rounds were also 45 minutes in the candidate and coaching accounts we read that day. Amazon’s SDE II page describes a loop of four 55-minute interviews with at least one question on systems design (read October 24, 2026).

The time you can use is shorter than the booking. In a recorded Meta-style practice round on interviewing.io, the interviewer tells the candidate that about 35 of the 45 minutes are for the problem. Plan for 35 to 40 minutes of design.

The opening is short. The interviewer gives you one line, such as "Design Ticketmaster", and then goes quiet. When you ask a question, they answer with real numbers. They do not hand you requirements you did not ask for. No company publishes a time split, but coaching guides and interviewers who write about the round agree on its shape:

1. 0 to 2 min · Hello and the promptHow the round runs, then one line: "Design Ticketmaster."
2. 2 to 8 min · RequirementsWhat it must do, how well, and what you leave out.
3. 8 to 11 min · NumbersUsers, requests a second and storage, and the decision they force.
4. 11 to 23 min · High-level designThe core entities, the API and a path for every requirement.
5. 23 to 39 min · Deep divesOne or two places at real depth, often with a new constraint.
6. 39 to 45 min · WrapWhat breaks first, what you would change, and your questions.

Each company bends this shape. Our guides to the Meta design round and the Amazon design round cover the differences, and our list of 62 system design interview questions lists what gets asked.

The failure interviewers name first is designing before understanding. Fahim ul Haq, who has interviewed hundreds of engineers at Microsoft and Meta, describes candidates who reach for databases, load balancers and microservices within minutes of the prompt. On the sheet that reads as "started drawing at minute two".

A strong opening is small. Three functional requirements: what the system must do. Three to five non-functional ones, each with a number: how fast, how available, how consistent, at what scale. One thing out of scope, with a reason. For Ticketmaster that is: view an event, search events, book seats. No seat is ever sold twice, browsing stays up, 10 million users can arrive for one popular event, and search answers in under 500 ms. Past bookings and dynamic pricing are out.

Then say what makes this system hard. For Ticketmaster it is two people pressing Buy on the same seat in the same second. Saying it early tells the interviewer where you will spend your depth.

Two habits cost you here. A long list of requirements spreads your time thin. And asking the interviewer "what should I build?" over and over hands the problem back to them. Ask about users, scale and constraints, then decide.

The second failure on the lists is numbers that go nowhere. A candidate works out daily users, requests a second and storage, and never mentions them again. The interviewer writes down that the numbers were recited, not used.

Coaches disagree on how much to estimate. Hello Interview tells candidates to skip estimation up front unless it changes the design, while its own Meta guide reports Meta interviewers pressing for throughput maths (both read October 24, 2026). One rule fits both: give a number when it will pick a component, and say which component. "About 5,800 reads a second on average and up to 600,000 at the peak, so reads go through a cache and the database only takes writes" is a number with a job. Write it on the board, and point back to it when you size the cache.

Interviewers read the board for whether you agreed the requirements before you designed, and whether they can follow you. A few conventions make that easy. Keep the requirements as a short list in one corner, and leave them up. Write your numbers and leave them up too. Put three to five API endpoints beside the diagram. Draw databases as cylinders, label every box, and label every arrow that carries data. When you skip something, write that you skipped it.

Talk while you draw. Coaching guides treat a silent drawing session as a failed signal, however good the diagram is. The board is a shared reference for the conversation, not the answer.

The tool depends on the company, and it changes. On October 24, 2026, Meta’s hiring process page said design interviews run in CoderPad with Mermaid Markdown and a built-in AI assistant, while coaching guides for Meta still described Excalidraw. Google candidates in 2026 describe a plain Google Doc or a basic whiteboard. Amazon’s virtual interview page suggests your own diagram tool shared on screen, a free web whiteboard such as Miro, or paper held up to the camera (read October 24, 2026). Netflix rounds often have no diagram at all. Ask your recruiter which tool you will use, and practise in it.

Before any deep dive, the board needs a path for every functional requirement. Start with the simplest design that works: the client, a service or two, a database. Then walk one request end to end, naming each box it passes through. A senior interviewer wants that working design up by about minute 25, so two deep dives still fit.

Time is where good designs fail. The recorded interviewing.io round ended with one main note for the candidate: they ran four minutes over, and there was no time left for the API and the data model. On the sheet, "design still incomplete at minute 35" outweighs a clever cache.

Keep it plain. Kafka, Redis, Elasticsearch and Kubernetes for a problem one Postgres database would carry is over-engineering, and Hello Interview names it among the common reasons a senior candidate gets a mid-level offer. Every component should answer a requirement or a number you already wrote down.

A deep dive goes below the box. Not "a cache", but what the key is, what invalidates it and what happens when it is cold. Not "a lock", but how long it is held and what happens when the holder dies. This is where a senior performance pulls away from a mid-level one.

Name the limit before the fix. "One popular event puts every booking on the same few rows, so the database becomes the bottleneck when the sale opens" comes first. The queue or the virtual waiting room comes second. Adding the component first reads as reaching for a pattern you memorised.

Then state the trade-off in one sentence: X over Y, because Z, at the cost of W. "A seat hold that expires after 10 minutes, over a lock held through checkout, because a buyer who walks away must free the seat, at the cost of a second place to keep in step with the tickets table." One sentence like that is worth more than a list of options with no choice.

Expect the interviewer to change something partway through. In accounts we read on October 24, 2026, Google candidates report constraints added after the first design, and Meta candidates report being asked what happens at a hundred times the users. Take the new constraint, change the design, and say what changed. And give every technology you name its job here: "the queue holds the rush so the booking service sees 2,000 requests a second, not 200,000."

The design round often sets your level, not only whether you pass. The same Ticketmaster question is read differently for a mid-level, senior or staff candidate. Here is the short version of what coaches and interviewers described when we read them on October 24, 2026:

Two patterns move a performance down a level: over-engineering, and waiting to be led. At senior, every time the interviewer has to ask "what about scale?" or "what if this node dies?", it goes on the sheet.

This is how candidates, former interviewers and the companies described it on October 24, 2026. At Meta, each interviewer writes a summary of the round, the questions and your answers, with a recommendation and a read of your level. A hiring committee of people who did not interview you reads that packet. At Google, each interviewer writes feedback and gives one of six ratings, from Strong Hire to Strong No Hire, by candidate and former interviewer accounts, and a committee reads the packet. Google’s re:Work guide (updated March 2026) describes rubrics with outstanding, solid, borderline and poor answers. At Amazon, written feedback and an inclined or not inclined vote go to a debrief run with a Bar Raiser.

In every case, the person who decides never saw your board while you drew it. They read the notes. So the notes need something specific to say. For a strong Ticketmaster round, they look like this:

• Set three requirements and the 10 million-user peak before the first box.
• Used the peak to put a queue in front of booking.
• Seat hold explained down to its expiry. Search stayed at the box level.
• Chose a row lock over an optimistic write, and said what it cost.
• Needed one prompt on what breaks when the sale opens.

Each line is something you said or drew at a moment the interviewer could point to. That is the whole game: give them those moments on purpose.

Reading about a design round is not the same as drawing one while someone asks what breaks. The first time, the clock and the silence catch people out.

Star Interview runs a 45-minute practice system design interview on a shared whiteboard. Your AI interviewer reads what you draw, picks one of sixty-two questions real companies ask for your level and company, answers your questions with the numbers, and runs two deep dives. Your report is scored on eight things the big loops score, with the level your design read as, your board stage by stage, and a reference design next to yours. A 20-minute design sprint and a 5-minute numbers drill are there for shorter days.