# The System Design Round Run, Six Timed Phases to Defended Trade-Offs

*Run a 45-minute design round in six timed phases, scope it to your target level, handle an LLM component, and score a recorded mock to pick your next drill.*

- Canonical URL: https://www.refolk.ai/candidates/guides/system-design-round-timed-phases
- Pillar: Interviewing
- Format: Playbook
- Published: 2026-11-09
- Last reviewed: 2026-11-09
- Reading time: 22 min
- Keywords: how to structure a system design interview, system design interview 45 minute time breakdown, system design interview senior vs staff expectations, how to practice system design interview mock, system design interview with LLM component, back of the envelope estimation system design interview

## Key takeaways

- Lock requirements by minute 8 and have an end-to-end request path for every core feature by minute 18, earlier than the minute 20 to 25 that public timelines allow.
- Third-party accounts of Meta's 45-minute design round put the real design time at about 35 minutes once introductions and closing Q&A are taken out, so a plan that budgets all 45 will run late.
- In Refolk's index there are 5.5 US Senior Software Engineers for every Staff Software Engineer, so a staff-level design answer has to show cost, abuse, operations, ownership, and adjacent systems, which most senior answers leave out.
- A full LLM response takes 2 to 10 seconds, while a same-datacenter round trip takes 0.5 ms, so any model call in a design needs an explicit timeout, a fallback, and a cost-per-query figure.
- The down-leveling tell reported most often is laying out three options and asking the interviewer to choose, so every trade-off should end in a commitment and a reason.
- Score each recorded mock phase by phase against a written rubric and drill the lowest-scoring phase next, breaking ties toward the earliest phase.

This is a run order for a 45 to 60 minute system design round, written for engineers targeting senior or staff who already have the interview scheduled. It splits the round into six phases with fixed minute marks and has you set the scope to your target level before minute 5. It also shows how to treat a model or LLM call as an ordinary component, and how to score a recorded mock so you know which phase to drill next.

## What does a system design round actually give you to work with?

You get a vague prompt, a 45 or 60 minute slot, and a drawing surface. In practice only about 35 minutes of a 45-minute slot is design time. No employer publishes a minute-by-minute split, so you have to bring your own clock and run it.

Third-party accounts of Meta's process say its design rounds are 45 minutes long, and that the effective design window is roughly 35 minutes once introductions and closing Q&A are taken out. Most public timelines budget the full 45 minutes, which is why candidates who follow them run late. Expect one to three design interviews in a loop. Meta E6 candidates usually face two. At Google, system design is reported to start at L5.

The System Design Primer lays out four ordered steps with no minute marks: outline use cases, constraints, and assumptions; draw a high-level design with all the important components; design the core components; then scale the design. The third-party timelines agree on that order but not on the timing:

| Source | Requirements end | Diagram done | Deep dive window |
|---|---|---|---|
| IGotAnOffer | 5 (diagram starts 8) | 20 | 20 to 45 |
| Design Gurus | 10 | 25 | 25 to 45 |
| Aced (Meta) | 5 | Core design runs 25 to 30 min | Inside core design |
| Matthew Wong | 5, plus 5 for estimates | 24 | 10 min |
| This guide | 8 | 18 | 18 to 32 |

The sources disagree on two things: whether estimation gets its own phase, and whether the diagram should be finished at minute 20 or 25. One practitioner says outright that there is no official split. This guide sets the diagram deadline earlier than any of them. A diagram finished at minute 25 leaves almost no room for the deep dives, and the deep dives are where your level gets decided.

### Medium and AI policy

The medium and the AI rules change from employer to employer and over time, so confirm both with your recruiter instead of assuming. Here is what the public record shows:

- Google's hiring page says AI tools "are not permitted to be used during your interviews."
- Meta's hiring page says candidates in select technical rounds are expected to use the AI assistant built into CoderPad, and that no outside AI tool is authorized.
- Amazon tells candidates not to use generative AI tools "unless explicitly permitted," or risk disqualification.
- Business Insider reported a pilot that lets some software engineering candidates use Gemini in one code comprehension round. That is not the design round.
- A survey of employer policies found that none allows AI in every round. No employer source permits AI in the design round.
- The drawing tool is known only from community reports. One poster on Blind said a Meta recruiter told them they *have* to use Google Drawing. Prepfully suggests Excalidraw for Meta prep. No employer has publicly stated which tool it uses.
- Google has reportedly brought back in-person interviews for some roles, so practice on a physical whiteboard as well as a canvas.

> **Note:** Re-check the rules for your loop
>
> Policies here are set per employer and per round, and they change. Before the round, ask your recruiter in writing two questions: which drawing tool will be used, and whether any AI assistance is permitted in the design round.

## How is the design round graded, and why does it set your level?

Interviewers grade the design round on scoping, how deep you go on the hard parts, how you justify trade-offs, how you handle failure, and how you communicate. In third-party accounts, the hiring committee decides your level after the loop, and the design round is the main input to that decision.

According to accounts of Atlassian's process, "did I pass" and "at what level" get settled together, after the loop. For Google, third-party sources say a weak design round is the most common reason an L5 candidate receives an L4 offer. None of this is published by the employers, and no survey of engineering leaders on the question exists. The pattern is consistent across sources, though, and it has one practical consequence: the committee reads written notes. You are effectively being scored on what your interviewer can write down, so a trade-off you say out loud counts for more than one the interviewer has to infer.

Prepfully reports eight official areas for Meta: testability, usability, extensibility, security, portability, availability, scalability, and operational characteristics. That is secondary reporting, so treat it as a checklist of topics, not as the actual scoresheet. The dimensions that show up in every source are:

- **Scoping.** Shows you can turn "design X" into a buildable problem. It lies when the scope is so narrow that the design becomes trivial.
- **Deep-dive depth.** Shows you know where the design is hard. It lies when the depth goes into a component that never constrained anything.
- **Trade-off justification.** Shows judgement. It lies when you list the options but never choose one.
- **Failure handling.** Shows operational maturity. It lies when it amounts to "add a replica" with no detection or degradation plan.
- **Communication.** Shows the interviewer can follow and record your reasoning. It lies when you are fluent but the reasoning is missing.

AlgoMaster's level ladder makes those dimensions concrete. Use it to decide what your answer has to contain before you start drawing:

| Level | The answer must show | What a false version looks like |
|---|---|---|
| Junior | A simple, correct design | Correct only because the scope ducked the hard part |
| Mid-level | A sized design with justified choices | Numbers that never change a choice |
| Senior | Deep dives into risks, scale, and failures | Depth the interviewer had to prompt for |
| Staff+ | Cost, abuse, operations, ownership, adjacent systems | Org concerns named, never designed |

**5.5 - US Senior Software Engineers for every Staff Software Engineer**

In Refolk's index of professional profiles there are 182,927 Senior Software Engineers and 33,163 Staff Software Engineers in the US, so Staff is 15.3% of the combined pool.

Level works as a scarcity filter. A staff answer has to carry signals that most senior candidates never bring up, and AlgoMaster's ladder says what they are: cost, abuse, operations, ownership, and adjacent systems.

| Title | US count (Refolk's index) | Employers seen in a 25-profile sample |
|---|---|---|
| Senior Software Engineer | 182,927 | Meta, Google, Datadog |
| Staff Software Engineer | 33,163 | Databricks, GitHub, Vanta |
| Senior SWE listing LLM skill | 2,510 | Amazon, Meta, Google DeepMind, Microsoft |

The employer column comes from small samples, so read it as illustrative only. Decide your target level before the round, not during it. If the posting says staff but your history reads as senior, it is better to find that out at your desk than at minute 30. [Refolk](/candidates) scores how well your actual history fits a specific posting, and that is a quick way to see whether to scope your answer up or hold at the level your record supports.

#### Where your answer lands on the level ladder

Horizontal axis runs from Shallow on risky components to Deep on risky components. Vertical axis runs from One team's service to Org and adjacent systems.

| Quadrant | What it means |
| --- | --- |
| Architecture tour | Stop adding boxes; pick the riskiest component and go deep |
| Staff signal | Hold it; state cost, abuse, and ownership explicitly |
| Mid-level read | Size the design and justify each choice with a number |
| Senior read, staff miss | If targeting staff, design the adjacent systems, operations, and cost |

*Depth on the risky components earns senior, and only scope that reaches adjacent systems turns that depth into a staff signal.*

## The six-phase minute budget

Run the round in six phases. Requirements are locked by minute 8, the high-level diagram is done by minute 18, two deep dives run until minute 32, failure and cost are covered by minute 40, and the close ends by minute 45. Each phase has a "done" condition you can check from the recording.

| Phase | Ends at | Done looks like |
|---|---|---|
| 1. Level, requirements, estimates | 8 | 3 core features, written SLOs, out-of-scope list, 2 to 3 numbers |
| 2. API and data model | 12 | Endpoints plus core entities |
| 3. High-level diagram | 18 | Every core feature has an end-to-end request path |
| 4. Two deep dives | 32 | Two risky components, each ending in a decision |
| 5. Failure and cost | 40 | Failure modes, detection, degradation, cost driver |
| 6. Close | 45 | Recap against requirements, one open risk, trade-offs restated |

An SLO (service level objective) is a measurable target such as a latency or availability figure, for example "p99 read under 200 ms." Write the SLOs on the board, because they become the yardstick you use in every later phase.

#### The six phases of a design round

1. **Scope (0 to 8)** - State level, lock requirements, SLOs, exclusions, and rough numbers
2. **Interface (8 to 12)** - Endpoints and core entities
3. **Diagram (12 to 18)** - Components with a request path for every core feature
4. **Deep dives (18 to 32)** - Two risky components, each ending in a decision
5. **Failure and cost (32 to 40)** - What breaks, how you detect it, how it degrades, what it costs
6. **Close (40 to 45)** - Recap, one open risk, trade-offs restated

*Each phase ends at a fixed minute mark, and the deep dives absorb any slack in either direction.*

### Adjusting for a 35-minute window or a 60-minute slot

If introductions and Q&A come out of the same 45 minutes, you have about 35 minutes of design time. This is my compression of the plan, not a published schedule:

- Requirements and estimates by minute 6.
- API and data model by minute 9.
- Diagram by minute 15.
- One deep dive to minute 24, and a second only if you are ahead.
- Failure and cost by minute 31.
- Close by minute 35.

For a 60-minute round, one mock script says to give the extra time to the deep dive. I agree. Keep the first three phases on their 45-minute marks and spend the extra 15 minutes on deep dives, because that is where the level evidence comes from. If the prompt has a generative AI component, budget the full 8 minutes for requirements even in the compressed version. GenAI prompts are reported to need the longer scoping time.

## Step-by-step: running the round from prompt to close

Do these eight moves in order. The first seven happen inside the round and follow the six-phase budget, with phase one split into two moves. The eighth happens after a recorded mock.

> **Rule:** Say your level before minute 5
>
> State your target level and your plan out loud before minute 5. If you never say it, you will drift to mid-level breadth, and nothing in the interviewer's notes will show you were aiming higher.

#### The design round run

1. **State the target level and the plan** - In the first two minutes, say which level you are targeting and how you will spend the time, then invite the interviewer to redirect you.
2. **Lock requirements and estimates by minute 8** - Fix three core features, write the SLOs, list what is out of scope, and convert DAU to QPS and storage with two or three rounded numbers tied to design choices.
3. **Set the API and data model by minute 12** - Write the endpoints for each core feature and name the core entities and their keys.
4. **Draw the high-level diagram by minute 18** - Draw the components and trace one write and one read end to end for every core feature.
5. **Run two deep dives from minute 18 to 32** - Choose the riskiest components yourself and finish each deep dive with a chosen option, a reason, and what it cost you.
6. **Cover failure and cost by minute 40** - Say what breaks, how you detect it, how the system degrades, and what drives the cost. Cut deep-dive time before you cut this.
7. **Close by minute 45** - Recap the design against the locked requirements, name one open risk, and restate the trade-offs.
8. **Score the recording and pick the next drill** - Score each phase 0 to 2 against the rubric, note the real minute marks, and drill the lowest-scoring phase next.

The opening matters more than its two minutes suggest. Use this script and adapt the bracketed parts:

**Opening script, minutes 0 to 2**

```
Before I start, I'm targeting [senior / staff], so I'll aim to spend most of our time on the parts of this that are actually hard.
Here's how I plan to use the time:
- About 8 minutes on requirements, what's out of scope, and rough numbers.
- A quick API and data model, then a high-level diagram by around minute 18.
- Two deep dives. I'll pick them based on where the numbers make this hard.
- Failure modes and cost, then a short recap of the trade-offs.
[Staff only: I'll also cover how this touches adjacent systems and who owns what.]
If you'd rather I go deep somewhere specific, stop me at any point.
```

*Swap the level and the focus areas to match the posting; keep the time plan as-is.*

### Choosing the deep dives

Pick the riskiest component, meaning the part where the numbers or the requirements make the design hard. Choose it yourself. Senior candidates volunteer the deep-dive areas, and junior candidates wait to be prompted. If your estimates showed a write-heavy peak, the deep dive is the write path. If an SLO is tight, the deep dive is whatever sits on the critical path to that SLO.

### Stating a trade-off so it can be written down

Every trade-off should come out as one sentence an interviewer can copy into their notes:

- "I'm choosing X over Y because [requirement or number]."
- "The cost is [what you gave up]."
- "I'd revisit this if [condition changes]."

If you hear yourself listing options and then asking the interviewer which one they prefer, stop and choose one.

## Back-of-the-envelope estimation that earns its minutes

Back-of-the-envelope estimation means rough arithmetic that turns user counts into load, storage, and latency figures. It earns its time only when each number changes a design decision. Two or three rounded numbers, each tied to a choice, is enough.

The standard anchors:

- **Seconds per day:** 86,400.
- **Average QPS:** DAU × actions per user per day ÷ 86,400. DAU is daily active users. QPS is queries per second.
- **Sanity check:** 1 million requests a day is about 11.6 per second.
- **Peak load:** average QPS × a peak factor of 5 to 10.
- **Latency:** the Jeff Dean and Norvig latency table, learned as orders of magnitude.

Worked example: 10 million DAU × 10 actions is 100 million requests a day. Divided by 86,400, that is roughly 1,200 QPS on average, or about 6,000 to 12,000 at peak. Say the rounded figure, then the decision it drives: "That peak is beyond what I'd put on a single write node, so I'll partition writes." Here the number did its job. If it changed nothing, you can drop it.

Nobody has published how often each anchor comes up in reported prompts, so do not try to memorize a long table. The latency table you will see quoted is labelled "Latency Comparison Numbers (~2012)". Newer versions put SSD random reads near 16 µs. Quote orders of magnitude, such as "sub-millisecond inside the datacenter, around 150 ms across a continent", not exact values. Colin Scott's interactive latency numbers page shows how the figures shift over time if you want to re-check them.

Whether estimation is its own phase is disputed. Chirag Hasija puts it before the API, and other sources fold it into requirements. This guide folds it into phase one so the numbers are on the board before you draw anything.

## How to handle a prompt with an LLM or model component

Treat the model call as an ordinary component that has its own latency, cost, and failure modes. Because a full model response takes 2 to 10 seconds, it dominates the latency budget. That makes a timeout, streaming, a fallback, and a cost-per-query figure required parts of the design, not optional extras.

The share of general software engineering prompts that include an LLM component has not been published, so do not assume a number. The follow-up topics reported for these prompts are consistent: latency per stage, cost per query, and fallback to a smaller model or a cached response. The latency contrast explains why:

| Operation | Typical figure | Source |
|---|---|---|
| Same-datacenter round trip | 0.5 ms | Latency numbers table |
| Cross-continent packet | 150 ms | Latency numbers table |
| RAG retrieval | 30 to 80 ms | GenAI interview guide |
| Full LLM response | 2 to 10 s | GenAI interview guide |

RAG (retrieval-augmented generation) means fetching relevant documents and adding them to the prompt before the model generates its answer. Reported budgets give 30 to 80 ms for retrieval and 50 to 150 ms for reranking, followed by LLM generation. Every hop except the last is measured in milliseconds, and the last is measured in seconds. The model therefore sets your p95 latency, which is the response time that 95% of requests come in under.

#### Wrapping a model call in a design

1. **Client timeout and streaming** - User sees tokens or a fallback before the latency budget runs out
2. **Fallback path** - Smaller model, cached response, or a template answer
3. **Prompt cache** - Repeated prefixes cut input token cost by 50 to 90%
4. **Retrieval and rerank** - 30 to 80 ms retrieval, 50 to 150 ms rerank
5. **Model generation** - 2 to 10 seconds per full response, dominates p95

*Each layer keeps the model's multi-second latency and per-query cost from reaching the user unbounded.*

Fold the model into your six phases like this:

- **Requirements:** add a latency SLO for the model path and a cost ceiling per query.
- **Diagram:** draw the model as one box on the request path, with retrieval in front of it and the fallback branching off it.
- **Deep dive:** the model path is almost always one of your two deep dives, because it is where the numbers make the design hard.
- **Failure and cost:** state the timeout, what the fallback returns, and the cost per query, then show how prompt caching changes that cost.

**1.4% - Share of US Senior Software Engineers who list LLM as a skill**

In Refolk's index, 2,510 of 182,927 US Senior Software Engineers list it, so a candidate who designs the model call as a measured component still stands out.

## How the round goes wrong: failure modes and false positives

The round usually goes wrong in one of two ways. Either it feels productive but leaves nothing at your level in the interviewer's notes, or it shows strength at the level below the one you are targeting. Each failure below has a check you can run against a recording.

> **Watch out:** Hedging is the most common down-level tell
>
> The down-leveling tell reported most often is passivity about trade-offs: laying out three options and asking the interviewer to choose. Every option you raise has to end in a commitment and a reason, or the interviewer has nothing to write down.

- **Skipping the level statement.** If you never state your target level, you end up scoping to mid-level breadth. *Check:* did the deep-dive topics come from you or from the interviewer?
- **Hedged trade-offs.** Three options, no decision. *Check:* every option you raised ends in "I'm choosing X because Y."
- **A diagram without request paths.** The false positive here is a lot of boxes. The failing anchor in reported rubrics is "boxes with no request path." *Check:* trace one write and one read end to end. If either breaks, the diagram is not done, however full it looks.
- **Team-scoped design at a staff target.** One reported cause of an L6-to-L5 down-level was a design round that "showed strong technical depth but team-scoped execution." Strong depth is the false positive here, because it reads as a solid senior performance and still misses staff. *Check:* did you name adjacent systems, ownership, operations, and cost without being asked?
- **Memorized designs.** Candidates "try to bend the Twitter design to requirements it was not built for." *Check:* every component on the board traces back to a requirement you stated in phase one.
- **Treating the LLM like a database call.** This misses the multi-second latency. *Check:* the design has an explicit timeout, a fallback (smaller model, cache, or template), and a cost-per-query figure.
- **Precision theatre in estimates.** One course mocks answers like "meaning we need exactly 347.1 servers." *Check:* every number is rounded and changed a decision.
- **Over-trusting outdated latency numbers.** The common table dates from around 2012. *Check:* you quoted orders of magnitude, not exact nanoseconds.
- **Running out of clock.** Following a timeline that budgets the full 45 minutes when you really have about 35. *Check:* where did phase three actually end? If you run long, shorten the deep dive rather than skip failure modes.

> A full board is not a finished diagram. If one read cannot travel end to end, the diagram is not done.

## Scoring a recorded mock and choosing what to drill next

Record every mock and score each phase 0 to 2 against a written rubric. Note the real minute mark where each phase ended, and drill the lowest-scoring phase next. Starting a new prompt from scratch practices your strong phases as much as your weak ones, so it improves the weak phase slowly.

Practice inside the window you will actually get. Hello Interview's Live Practice, for example, runs a 35-minute design interview out loud on a shared whiteboard with an AI interviewer, which matches the effective window reported for 45-minute rounds. A human peer works too, as long as someone keeps the clock and you keep the recording.

**Design round mock rubric**

```
Prompt: ______   Target level: ______   Window: 35 / 45 / 60 min

Phase 1 Scope [ended at __ min, target 8]
 2 = level stated before min 5; 3 core features; written SLOs; out-of-scope list; 2-3 rounded numbers each tied to a decision
 1 = requirements present but no SLOs or exclusions, or numbers that changed nothing
 0 = started drawing before requirements were fixed

Phase 2 API and data model [ended at __ min, target 12]
 2 = endpoints for every core feature; core entities and keys named
 1 = partial endpoints or entities
 0 = skipped

Phase 3 Diagram [ended at __ min, target 18]
 2 = one write and one read trace end to end for every core feature
 1 = paths exist for some features only
 0 = boxes with no request path

Phase 4 Deep dives [ended at __ min, target 32]
 2 = two components chosen by me, each ending in a decision, reason, and cost
 1 = one deep dive, or topics the interviewer picked
 0 = no deep dive, or depth on a component that constrained nothing

Phase 5 Failure and cost [ended at __ min, target 40]
 2 = failure modes, detection, degradation, cost driver; LLM timeout, fallback, cost per query if present
 1 = failures named without detection or degradation; cost missing
 0 = skipped

Phase 6 Close [ended at __ min, target 45]
 2 = recap against requirements, one open risk, trade-offs restated
 1 = recap only
 0 = ran out of time

Level check (staff target only): adjacent systems / ownership / operations / abuse / cost named unprompted?  Y / N
Hedged trade-offs counted: __
Lowest phase: __   Drill next: __
```

*Fill one copy per recording; write the actual minute mark in brackets after each phase.*

The drill-next rule:

1. Drill the lowest-scoring phase.
2. If phases tie, drill the earlier one. A slow phase one starves every phase after it.
3. If every phase scores 2 but the minute marks slipped, drill the clock, not the content: rerun the same prompt in the 35-minute window.
4. If you are targeting staff and the level check is "N", the next mock is a staff drill no matter what the phase scores say.

#### Before you call the round ready

- [ ] I can say my target level and time plan in under two minutes without notes.
- [ ] In my last recorded mock, requirements were locked by minute 8 and the diagram was done by minute 18.
- [ ] Every trade-off in that recording ended in a commitment and a reason.
- [ ] I traced one write and one read end to end for every core feature.
- [ ] My failure and cost phase survived even when I ran long.
- [ ] For a prompt with a model call, I stated a timeout, a fallback, and a cost per query.
- [ ] My estimates were rounded, and each one changed a design decision.
- [ ] I have confirmed the drawing tool and the AI policy for this loop with the recruiter in writing.
- [ ] My lowest-scoring phase from the last mock has been drilled at least once since.

### Keeping this current

Two things in this guide can change without notice: employer AI policies and the medium for the design round. Before each loop, re-read the employer's own hiring page and ask the recruiter. The six-phase structure and the rubric do not depend on either.

The same phase-and-rubric approach carries across a full technical loop. Pair this guide with the Live Coding Round and Case Interview playbooks in the library so every round is prepared and scored the same way. The systems you list on your resume tend to come up when interviewers probe your experience, so make sure they are ones you can defend at your target level. Refolk tailors your resume to each posting from your own history, which keeps the projects on the page matched to the round you are preparing for.

## Frequently asked questions

### How should I split time in a 45-minute system design interview?

Lock requirements and estimates by minute 8, finish the API and data model by minute 12, have the high-level diagram done by minute 18, run two deep dives until minute 32, cover failure and cost until minute 40, and close by minute 45. No employer publishes an official split, and public timelines disagree. If introductions and Q&A come out of the same 45 minutes, compress the plan to roughly 35 minutes of design time by cutting deep-dive time, not failure modes.

### What is the difference between senior and staff expectations in system design?

Senior candidates are expected to go deep on risks, scale, and failures. Staff candidates are expected to add cost, abuse, operations, ownership, and adjacent systems on top of that. One reported cause of an L6 candidate being down-leveled to L5 was a design round that showed strong technical depth but stayed scoped to one team. If you are targeting staff, put the org-level concerns into your answer without waiting to be asked.

### Can I use AI tools during a system design interview?

Assume no. Google's hiring page says AI tools are not permitted in interviews. Meta authorizes only the AI assistant built into CoderPad, in select technical rounds. Amazon prohibits generative AI tools unless they are explicitly permitted. A survey of employer policies found that none allows AI in every round, and no employer source permits it in the design round. Ask your recruiter in writing to confirm the policy for your specific loop.

### What numbers do I need for back-of-the-envelope estimation in a system design interview?

Know that a day has 86,400 seconds, that DAU times actions divided by 86,400 gives average QPS, and that 1 million requests a day works out to about 11.6 per second. Multiply by a peak factor of 5 to 10 to get peak load. Learn the latency table at the level of orders of magnitude, because it dates from around 2012. Round every number and tie each one to a design decision.

### How do I handle an LLM component in a system design interview?

Treat the model call as an ordinary component that has its own latency, cost, and failure modes. A full response takes 2 to 10 seconds, so the model dominates p95 latency. Give it an explicit timeout, stream the output, add a fallback to a smaller model, a cached response, or a template, and state a cost per query. Mention that prompt caching can cut input token cost by 50 to 90% on repeated prefixes.

### How should I practice system design with mock interviews?

Record every mock, then score it phase by phase against a written rubric and note the real minute mark where each phase ended. Drill the lowest-scoring phase next instead of starting a new prompt from scratch. Practice inside a 35-minute window, which matches the effective design time reported for 45-minute rounds. Hello Interview's Live Practice, for example, runs a 35-minute session out loud on a shared whiteboard.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/candidates/guides/system-design-round-timed-phases*