The 45 minute round
The interviewer says "design a notification service" and starts a clock you cannot see. Most candidates who fail this round knew enough. They spent twelve minutes on requirements, drew boxes until minute 35, and were halfway through their first interesting idea when the interviewer said "we are almost out of time, any questions for me?"
A design round is a performance with a fixed running time. Knowing what belongs in each part of it is a skill on its own, and it is the cheapest one to fix.
You have 45 minutes and the prompt is 'Design Instagram'. Before reading on, write how you would split the time across the parts of the round, in minutes.
The clock#
Every design question page on this site follows the same four steps: understand the problem, propose a high level design, go deep, wrap up. Here they are against the clock, split a little finer, because the first step is really three jobs. Drag through the minutes.
- What you do
- Ask five or six questions. Write the answers in a corner of the board as requirements, and say out loud what you are cutting.
- What you might say
- “Before I draw anything: how many users, is it read heavy, and is a message allowed to arrive twice?”
- What they are checking
- Whether you scope before you build, and whether each question changes something.
- You are running late if
- You are still asking at minute 8, or you asked a question whose answer you never use.
Read the whole plan as text
- 0-5 Clarify. Ask five or six questions. Write the answers in a corner of the board as requirements, and say out loud what you are cutting. Say: “Before I draw anything: how many users, is it read heavy, and is a message allowed to arrive twice?” They are checking: Whether you scope before you build, and whether each question changes something. Late if: You are still asking at minute 8, or you asked a question whose answer you never use.
- 5-10 Numbers. Peak requests per second, storage over a few years, and the read to write ratio. Each number is followed by the decision it forces. Say: “About 2,000 writes a second at peak and a hundred reads per write, so this is a caching problem before it is a database problem.” They are checking: That a number drives the design. Nobody is grading your multiplication. Late if: You are working out CPU cores, or bandwidth for an API that returns a few kilobytes of text.
- 10-15 API and data. Three to five endpoints and the two or three tables or item shapes behind them, with one sentence on why each key is what it is. Say: “Messages are keyed by conversation and a time ordered id, because nearly every read is the latest 50 messages in one chat.” They are checking: That you design the storage from the reads backwards. Late if: You are writing out JSON bodies field by field.
- 15-25 Whole design. Draw 8 to 14 boxes. Walk one request through them out loud, start to finish, then the other main path. Say: “Let me follow one message from the sender to the receiver, and stop me wherever you want more detail.” They are checking: A design that works end to end before any part of it is clever. Late if: At minute 25 a request still cannot get from the client to storage and back.
- 25-38 Deep dives. Two deep dives on the hardest parts of this problem, which are not always the parts you know best. Each choice said with its cost. Say: “The hard part is fan out for accounts with ten million followers. I would push for most users and pull for the very large ones, and the price is a merge at read time.” They are checking: Depth in at least one area, and trade-offs stated with what they cost. Late if: You start the first deep dive after minute 30, or you picked it because it was comfortable.
- 38-43 Break it. Kill a node, triple the traffic, or cut a region off. Say what fails first, what the system does about it, and what you would see on a dashboard. Say: “If one connection server dies, fifty thousand clients reconnect at once. Jittered backoff on the client is what stops that turning into a storm.” They are checking: That you think about failure without being asked, and know what you would measure. Late if: The interviewer has to ask you what happens when this goes down.
- 43-45 Wrap up. Sixty seconds: the requirements, the shape, the two decisions that mattered, and what you would look at next with more time. Say: “So: writes go through a queue, reads come from a cache, and the two real decisions were the shard key and the hybrid fan out. With another hour I would look at running it in two regions.” They are checking: That you can say the whole design briefly, which is what a senior engineer does in a design review. Late if: The round ends mid-sentence inside a deep dive.
Two corrections to that plan for real rounds. A 45 minute slot often loses a few minutes to introductions and a few more to your questions at the end, so the design itself may get 35. When that happens, compress the deep dives, never the first three phases, because a design without scope or numbers has nothing for the deep dives to stand on. In a 60 minute round, the extra time goes to a third deep dive and a longer break it, not to more requirements.
By minute 25, one request should walk end to end through your boxes. If it cannot, stop adding detail anywhere else and finish the path. A complete simple design scores; a brilliant half design does not.
You drive#
The interviewer is not going to run the round for you. Reading the prompt and waiting for the next question is the most common way a strong engineer fails, because it looks exactly like someone who does not know what comes next.
Driving does not mean talking without pause. It means three habits:
Announce each change of phase. "I have enough requirements. Let me put two numbers on the board." One sentence, and the interviewer knows where you are on the clock without having to ask.
Offer the deep dive, then let them redirect. "I would like to go deep on retries and duplicate sends, unless there is an area you would rather see." Most of the time they say go ahead. When they redirect, that is the most useful thing they will say all round: it is the area they intend to score depth on.
Treat an interruption as a steer, not a challenge. If the interviewer cuts into your first deep dive with "what about quiet hours?", finish your sentence and follow them. You can come back later if there is time. Defending your plan against the person grading it costs more than any deep dive earns.
Where the time goes wrong#
Four patterns cover nearly every round that runs out of clock.
The requirements swamp. Fifteen questions, each reasonable, none of them used. Ask the five that change the design, then say "I will assume the rest, and you can correct me", and list the assumptions on the board.
Boxes with no depth. The whole design is drawn by minute 30 and nothing in it has been explained beyond its name. "Then a Kafka cluster" is a box, not a design. Every box you draw should be able to answer "what does it do when it is overloaded?", and in the deep dives at least one of them has to.
The rabbit hole. Twenty minutes on the virtual node count in a consistent hash ring, and the round ends before failure comes up. Put a mental timer on each deep dive. When it is up, say "I could go further on this, but let me make sure we cover failure", and move.
The freeze. The interviewer asks about something you have not used. Say so, then reason out loud: "I have not run that in production. Here is how I would expect it to behave and what I would check first." Interviewers write that down as a good signal. Bluffing gets written down too.
Interview replay#
The first and last few minutes of a notification service round, with the phase changes marked.
Score yourself#
Interviewers write notes against a short list of signals. The exact forms differ by company and are not public, but the things they write about are consistent: did you scope it, did numbers drive it, does it work, did you go deep, did you weigh choices, did you think about failure, and did you lead. After you run a design question, out loud and timed, score yourself here. The bands at the bottom are a rough self check, not anybody's hiring bar.
- Scoping
- Numbers
- API and data model
- Works end to end
- Depth
- Trade-offs
- Failure
- Driving
Run it out loud with a timer, even alone. Silent practice skips the part that fails in the room, which is talking and thinking at the same time.
Checkpoint#
1. In a 45 minute round, by roughly when should one request walk end to end through your design?
2. Ten minutes into your first deep dive, the interviewer asks about something else. What do you do?
3. It is minute 32 and failure has not come up. What is the best move?
- Five, five, five, ten. Clarify, numbers, API and data, whole design. Then deep dives until 38, break it until 43, two minutes to wrap up.
- End to end by minute 25. A complete simple design beats a brilliant half one.
- Every number is followed by the decision it forces. A number that decides nothing is wasted time.
- The interruption is the deep dive they want. Follow it.
I split a 45 minute round into seven parts. Five minutes of questions, where every answer has to change something and I say what I am cutting. Five minutes of numbers, each followed by the decision it forces. Five on the API and the keys. Ten on the whole design, walking one request end to end, which I want done by minute 25. Then two deep dives on the hard parts until about 38, five minutes breaking it, and a one minute summary. I announce each change of phase, offer the deep dive and let the interviewer redirect me, and if I am short of time I cut the deep dives, never the scope or the numbers.