Interview timing

TL;DR

• A 45-minute system design interview has about 40 usable minutes. Split them into six phases: Requirements (3 min), NFRs (2 min), API (3 min), Flow Design (5 min), Architecture (17 min), Deep Dives (15 min).
• Most candidates fail on timing, not on knowledge. They spend 15 minutes on requirements and never reach the interesting parts.
• Use the checkpoint technique at the 10, 20, and 30 minute marks to self-correct before you run out of time.
• Adapt your pacing to the interviewer's signals. If they lean forward, slow down. If they check their notes, speed up.
• The deep dive is where you score senior-level points. Everything before it is setup to get you there with enough time.

The Timing Disaster

You're 20 minutes into a "Design a notification system" interview. You've been discussing requirements for 12 minutes, carefully enumerating every possible notification channel (push, SMS, email, in-app, Slack integration, webhook). You've drawn a beautiful ER diagram of the notification preferences schema. The interviewer says: "Great, let's move on to the architecture."

You have 20 minutes left. You need to design the high-level system, discuss message queuing, handle delivery guarantees, walk through failure modes, and demonstrate depth on at least two hard problems. There is no way to do all of that well in 20 minutes.

I've sat on both sides of this table. When I interview candidates, the single most reliable predictor of a bad outcome is poor time management. Not missing a concept, not drawing the wrong diagram. Just running out of time before they could show what they know.

The fix is a structured time allocation that you practice until it becomes muscle memory. Not a rigid script, but a framework with built-in checkpoints that keep you on track.

The 6-Phase Framework

Here is how I recommend splitting a standard 45-minute system design interview. The times are targets, not rigid boundaries. You will flex them depending on the interviewer, but this is your baseline.

Phase 1: Requirements (3 minutes)

This is scoping, not specification writing. You need to establish three things:

• Who uses the system (consumers, enterprises, internal services)
• What the 3-4 core features are (not 8-10)
• What you're NOT building (say it out loud)

The output is a short bullet list on the whiteboard. 3-4 functional requirements, explicitly stated. If you're past 3 minutes and still listing requirements, you're over-scoping. Pick the core use case and move on.

My recommendation: write your requirements list, read it back to the interviewer, ask "Does this capture the scope you'd like to focus on?" and move forward. That takes 2-3 minutes, tops.

Phase 2: Non-Functional Requirements (2 minutes)

State your NFRs as concrete numbers, not adjectives. "Low latency" means nothing. "P99 read latency under 200ms" means everything.

Cover these four at minimum:

• Availability target (99.9% for most systems, 99.99% for payments)
• Latency (P50 and P99 for the hot path)
• Throughput (reads per second, writes per second, or both)
• Consistency model (strong for money, eventual for feeds)

Two minutes is enough to state these and do one quick back-of-envelope calculation (DAU to QPS, storage per item to total storage). Don't over-calculate. One number that changes your architecture is worth more than five numbers that don't.

Phase 3: API Sketch (3 minutes)

List 3-4 REST endpoints that map to your functional requirements. Request shape, response shape, one line each. This is not a detailed API design session.

POST /notifications       -> { userId, channel, message }
GET  /notifications/:userId -> { notifications[], cursor }
PUT  /notifications/:id/read -> { }

The API sketch forces you to think about data flow before drawing boxes. It surfaces hidden requirements (do you need pagination? real-time delivery? batch sends?) that will shape your architecture.

Phase 4: Flow Design (5 minutes)

Trace the critical path for one request through the system. Start at the client, end at the datastore. This gives you the spine of your architecture.

For a notification system: User action triggers notification, API receives it, validation, enqueue to message broker, worker picks up, resolve delivery channel, dispatch to push/email/SMS provider, mark as delivered.

Draw this as a simple left-to-right flow. No databases yet, no caches, no replicas. Just the happy path. This becomes the skeleton you'll flesh out in the architecture phase.

Phase 5: Architecture (17 minutes)

This is the core of your interview. You're converting that flow into a real system with:

• Service boundaries and responsibilities
• Data stores (and why you chose each one)
• Caching layers (and what they cache)
• Message queues (and what guarantees they provide)
• Read and write paths traced end-to-end

I typically spend the first 7 minutes adding the major components (services, databases, queues), then 5 minutes explaining data models and access patterns, then 5 minutes addressing the obvious scaling concerns proactively.

The key discipline is narrating as you draw. Every box gets a one-sentence explanation. Every arrow gets a label. Silent drawing is the enemy of a good score.

Phase 6: Deep Dives (15 minutes)

This is where senior and staff-level candidates separate from mid-level. The interviewer will typically steer you toward 2-3 areas. Common deep dive topics:

• How does X handle failure?
• What happens at 10x scale?
• Walk me through the consistency guarantees
• How would you implement feature Y specifically?

If the interviewer doesn't steer, pick the hardest problem in your design and go deep proactively. "The trickiest part of this system is delivery ordering guarantees. Let me walk through how I'd handle that."

The Checkpoint Technique

Even with a plan, it's easy to lose track of time. I use three mental checkpoints during the interview. At each one, I do a 5-second self-assessment: am I on track, ahead, or behind?

The 10-minute checkpoint

By minute 10, requirements, NFRs, and API should all be done. If you're still discussing requirements at minute 10, that is a red flag. Wrap up immediately. Say: "I have enough to start designing. I'll refine as I go."

The 20-minute checkpoint

By minute 20, you should be halfway through the architecture with the major components drawn. If you're still on flow design, simplify. Drop the component you're least sure about and move on. You can always add it back during deep dives.

The 30-minute checkpoint

By minute 30, the architecture should be substantively complete and you should be starting (or about to start) deep dives. If you haven't started deep dives by minute 30, stop architecting. Pick the single most interesting problem and go deep. A candidate who shows depth on one topic scores higher than a candidate who shows breadth on everything at a shallow level.

Adapting to Different Interview Lengths

Not every interview is 45 minutes. Here is how the framework scales.

For 30-minute interviews, you need to be aggressive about cutting scope. Fewer requirements, one data store choice (with a sentence on why), and one deep dive instead of two. The checkpoint technique still works; just shift the marks to 7, 15, and 22 minutes.

For 60-minute interviews, you have room to breathe. Use the extra time on requirements (explore edge cases the interviewer cares about) and deeper deep dives (propose two options, compare them, recommend one). Don't use the extra time to over-architect. More boxes on the whiteboard does not mean a better design.

Reading Interviewer Cues

Your interviewer is constantly giving you signals about pacing. Most candidates miss them because they're focused on their own train of thought.

Signals to speed up

• They're looking at their laptop or notes more than the whiteboard. You've lost their attention on this section.
• They say "Let's assume..." and fill in a detail for you. They're trying to accelerate past something you're spending too long on.
• They nod quickly and say "yep, that makes sense." They've evaluated this section. Move on.
• Short, closed responses to your questions ("Yes," "Sure," "That's fine"). They want you to progress.

Signals to slow down

• They lean forward or move closer to the whiteboard. You've hit a topic they want to explore.
• They ask a follow-up question about something you just said. Stay on this topic.
• "Can you go deeper on that?" or "What happens when..." is an explicit invitation to dive in.
• They're taking notes while you speak. What you're saying is being evaluated positively.

Signals they want to redirect

• "That's interesting, but what about..." means you're off-track. Pivot immediately.
• "Let's come back to that. What about the write path?" means they have a specific area they want to evaluate. Follow their lead.
• They re-ask a question you partially answered. Your answer wasn't sufficient. Give a more specific answer.

The meta-skill here is splitting your attention. About 80% of your focus is on the design problem. The other 20% is on the interviewer. If you can do this, you'll naturally adapt your pacing to what they care about, and that responsiveness itself is a positive signal.

When to Speed Up vs Slow Down

Beyond interviewer cues, there are structural moments where you should adjust your pace.

Speed up when:

• You're stating something standard. "I'll use a message queue for async processing" needs one sentence, not a five-minute justification of message queues vs direct calls.
• You're listing components that aren't differentiated. "Database, cache, CDN, load balancer" can be drawn in 30 seconds with one-line annotations each.
• You're on a topic that doesn't have trade-offs. If there's only one reasonable approach, state it and move on.

Slow down when:

• You're at a fork in the road. "Should we use push-based or pull-based fan-out?" is worth 3-4 minutes of analysis. This is where you demonstrate critical thinking.
• You're discussing failure modes. "What happens when the message broker goes down?" is an invitation to show production experience. Walk through it carefully.
• You're making a non-obvious trade-off. If you're choosing eventual consistency over strong consistency, explain why for this specific system.

The rule of thumb: spend time proportional to the difficulty of the decision, not the importance of the component. A load balancer is important but the decision is straightforward. A consistency model might seem like a small detail but the reasoning is complex and revealing.

Worked Example: Pacing "Design a Chat System"

Let me walk through what good pacing looks like in practice. The prompt is "Design a real-time chat application like WhatsApp."

Minutes 0-3 (Requirements): "I'll scope to 1-on-1 messaging and group chats up to 500 members. Core features: send message, receive message in real-time, message history. Below the line: read receipts, typing indicators, file attachments. Sound good?" Interviewer nods. Done.

Minutes 3-5 (NFRs): "100M DAU, each sending 40 messages/day gives 4B messages/day, roughly 46K writes/sec. P99 delivery latency under 500ms. Messages are durable once persisted. Eventual consistency on read status is acceptable."

Minutes 5-8 (API): Three endpoints: POST /messages, GET /messages?chatId=X&cursor=Y, WebSocket /ws/connect for real-time delivery. One line each.

Minutes 8-13 (Flow): Trace the send-message path. Client sends via WebSocket, gateway routes to chat service, chat service persists to database, publishes to message broker, broker fans out to connected recipients via their WebSocket connections.

Minutes 13-30 (Architecture): Draw the full system. WebSocket gateway cluster, chat service, Kafka for message fan-out, Cassandra for message storage (partition by chat_id), Redis for presence/session mapping, push notification service for offline users. Explain each choice in one sentence as you draw it.

Minutes 30-45 (Deep Dives): The interviewer asks about message ordering. You spend 8 minutes on partition-level ordering in Kafka, vector clocks for conflict detection, and how group messages maintain causal ordering. Then 7 minutes on scaling WebSocket connections (connection balancing, session migration during deploys, heartbeat and reconnection).

Notice the discipline: requirements and API took 8 minutes total. The remaining 37 minutes went to architecture and depth, which is where the evaluation happens.

Common Mistakes

Spending 10+ minutes on requirements

This is the number one timing failure I see. Candidates treat requirements gathering as the main event instead of the warmup. Three to five minutes max. If you've been asking requirements questions for 8 minutes, you've been asking questions that don't change your architecture.

Never reaching deep dives

If you don't get to deep dives, you physically cannot demonstrate senior-level thinking. An interview where you spend 40 minutes on architecture and 0 minutes on depth looks like a mid-level performance, regardless of how good the architecture was.

No time awareness at all

Some candidates genuinely have no idea how much time has passed. They don't look at the clock, they don't check in, and they're shocked when the interviewer says "we have 5 minutes left." Practice with a visible timer. Always.

Spending equal time on every component

Not every component deserves the same attention. A notifications service and a payments service both appear on your diagram, but one of them is routine and the other involves exactly-once delivery guarantees. Skim the routine parts and linger on the interesting parts.

Front-loading all depth in architecture

Some candidates try to deep-dive every component as they draw it. This means they deep-dive the first two components and never get to the rest. Draw the full architecture at medium depth first, then come back for targeted deep dives.

How This Shows Up in Interviews

At the junior/mid level, interviewers check whether you can get to a reasonable architecture at all within the time limit. Poor pacing is the most common reason candidates fail at this level.

At the senior level, interviewers expect you to self-manage your time and reach deep dives without being prompted. If the interviewer has to say "let's move on to the architecture" more than once, that is a pacing signal against you.

At the staff level, interviewers expect you to use time strategically. That means spending more time on the hard problems and less time on the easy ones, without being told which is which. Staff candidates often explicitly say things like "I'll sketch this part quickly since it's standard, and save time for the interesting consistency problem."

Quick Recap

1. A 45-minute interview gives you about 40 usable minutes. Split them: Requirements (3), NFRs (2), API (3), Flow (5), Architecture (17), Deep Dives (15). Adjust the targets, never the ratio.
2. The checkpoint technique at 10, 20, and 30 minutes catches pacing problems before they become fatal. If you haven't started deep dives by minute 30, stop architecting and go deep immediately.
3. Deep dives are where you earn your seniority rating. A complete architecture with no depth looks mid-level. An incomplete architecture with excellent depth on two topics looks senior.
4. Read the interviewer. Quick nods mean speed up. Follow-up questions mean slow down. "Let's assume X" means they're trying to skip past what you're discussing. Adapt.
5. Spend time proportional to decision difficulty, not component importance. A load balancer gets one sentence. A consistency model gets five minutes.
6. Practice with a visible timer until the pacing becomes automatic. The goal is to never think about time during the real interview because your internal clock just works.
7. For different interview lengths, scale every phase proportionally. A 30-minute interview is not a 45-minute interview done faster; it is a narrower scope designed to reach depth quickly.