Interview timing

Purpose

Use this article to allocate attention under a system-design time limit. The 45-minute schedule is one worked baseline; the reusable skill is preserving breadth, reaching a meaningful deep dive, and adjusting the proportions to the time actually available.

TL;DR

• Start with the time actually available for design. For a nominal 45-minute block, one baseline is Requirements (3 min), NFRs (2 min), API (3 min), Flow Design (5 min), Architecture (17 min), and Deep Dives (15 min); compress the same order when the round is shorter.
• Poor pacing can hide otherwise strong system-design knowledge. A common failure is spending too long on requirements and leaving no room for architecture or depth.
• 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. Follow-up questions usually justify slowing down; quick agreement or a redirect is a cue to move on.
• Deep dives are where you can demonstrate depth. Everything before them is setup that should earn its space.

Mental Model

Time management in a design interview is an attention-allocation problem:

• Protect the spine: scope the problem, state the important NFRs, trace one critical flow, and draw the major components.
• Go deep selectively: spend time where a decision has real uncertainty, a failure mode, or a meaningful trade-off.
• Use breadth before depth: get a complete medium-level architecture on the board before explaining one component in detail.
• Make transitions explicit: announce when you are moving on, what you are deferring, and which deep dive you will prioritize.
• Scale by proportion: a 30-minute round is a narrower answer, not a 45-minute answer delivered at double speed.

Treat phase times as targets. The interviewer’s format, the design scope, and the amount of setup or wrap-up time can all change the usable window.

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 semantics, walk through failure modes, and demonstrate depth on at least two hard problems. It is difficult to do all of that well in 20 minutes.

Poor time management can obscure good system-design knowledge. A candidate may know the concepts and still run out of time before showing how the design handles scale, failure, or trade-offs.

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

For a nominal 45-minute design block, use this baseline. It groups six activities into four phases; the times are elapsed minutes and targets, not rigid boundaries, so flex them with the format and the interviewer.

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.

A practical move: 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. Aim to do that in about 2-3 minutes.

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 (for example, 99.9% or 99.99%; validate the business need)
• 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

One workable split is 7 minutes for the major components (services, databases, queues), 5 minutes for data models and access patterns, and 5 minutes for the obvious scaling concerns.

The key discipline is narrating as you draw. Give every box a one-sentence explanation and every arrow a label. Silent drawing makes the reasoning harder to follow.

Phase 6: Deep Dives (15 minutes)

This is where candidates can make their depth visible. The interviewer may 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. Use three mental checkpoints during the interview. At each one, 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 add it back during deep dives if time permits.

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. Focused depth on one topic can communicate more than shallow breadth across every component.

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 can give you useful signals about pacing. They are easy to miss when you're focused on your 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 may be trying to accelerate past something you're spending too long on.
• They nod quickly and say "yep, that makes sense." They may have enough signal from 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. Treat it as a reason to stay clear, not as proof that the section is complete.

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: keep most of your focus on the design while reserving a small amount for the interviewer’s cues. This helps you adapt your pacing to what they are choosing to explore.

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 time went to architecture and depth, where the design’s trade-offs became visible.

Common Mistakes

Spending 10+ minutes on requirements

This is a common timing failure. Candidates treat requirements gathering as the main event instead of the warmup. Three to five minutes is a useful target. If you've been asking requirements questions for 8 minutes, revisit whether those questions change your architecture.

Never reaching deep dives

If you don't get to deep dives, you may not get room to demonstrate senior-level depth. An interview where you spend 40 minutes on architecture and 0 minutes on depth can undersell an otherwise good design.

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 may be routine while the other involves delivery semantics, retries, and deduplication. 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 often check whether you can get to a reasonable architecture within the time limit. Poor pacing can prevent that signal from appearing.

At the senior level, interviewers often expect you to self-manage your time and reach deep dives without repeated prompting. If the interviewer has to say "let's move on to the architecture" more than once, treat that as a pacing signal to adjust.

At the staff level, interviewers often look for strategic time use: more attention on hard problems and less on routine ones. A useful transition is "I'll sketch this part quickly since it's standard, and save time for the interesting consistency problem."

30-Second Explanation

“I treat interview time as a limited attention budget. I first secure the spine—scope, NFRs, one critical flow, and a complete medium-level architecture. Then I spend the remaining time on the hardest trade-offs and failure modes. I use checkpoints and explicit transitions, and I scale the proportions to the actual design time rather than assuming every round is 45 minutes.”

5-Minute Explanation

If you have only five minutes to explain your pacing method:

1. Confirm the usable design time and choose a narrow scope.
2. Reserve roughly one-quarter for scope, NFRs, API, and the critical flow.
3. Use the largest block for a breadth-first architecture pass.
4. Protect the final block for one or two deep dives and a short recap.
5. If behind, cut optional features and routine explanations before cutting the critical path or all depth.

For a five-minute answer itself, state the scope, one NFR, the core flow, the main bottleneck, and one trade-off. Do not attempt a full 45-minute design in miniature.

Quick Recap

1. Start with the usable design time. For a nominal 45-minute block, one baseline is Requirements (3), NFRs (2), API (3), Flow (5), Architecture (17), and Deep Dives (15). Adjust the targets while preserving the order and intent.
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 design depth becomes visible. A complete architecture with no depth can undersell seniority; an incomplete architecture with excellent depth on two topics can leave important gaps. Aim for a complete spine plus focused depth.
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 familiar. The goal is to spend less attention on the clock during the real interview because the transitions are practiced.
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.

Related Concepts

• Approach and structure — the overall sequence for a system-design answer.
• Scoping the problem — choose a tractable scope before time starts disappearing.
• Wrapping up the interview — close with trade-offs, gaps, and next steps.
• Capacity planning — choose the estimates and bottlenecks that deserve deep-dive time.