How a Scored System-Design Interview Works, and How to Prepare
What the interviewer scores in a system-design round, the trap that catches well-prepared people, and how to prepare in order.
Most system-design advice tells you what to draw. This guide covers how the interview gets scored: what the interviewer writes down while you talk, and what it costs you when you skip it. The examples come from the rubrics behind Hyrr's practice system-design interviews. The same habits score well with human interviewers too.
The shape of the 45 minutes
A typical scored design round has four phases. You won't hear them announced, but the rubric is built around them:
- Requirements and scope (about 5 minutes). The prompt is deliberately vague. "Design a photo-sharing service" leaves out who uses it, how many people, what has to be fast and what can wait.
- High-level architecture and APIs (about 15 minutes). Components, data flow, and the actual API calls.
- Bottlenecks and the data layer (about 15 minutes). Which database and why, what gets cached, where it breaks first.
- Resilience and scaling at the edges (about 10 minutes). Failures, hot spots, and what happens when traffic multiplies.
Run out of time in phase 2 and you never reach the material that separates the levels. Pacing is part of the test.
What the interviewer is actually scoring
Hyrr's System Design Fundamentals practice interview scores five things, each on a four-level scale: Novice, Competent, Proficient, Expert.
| Scored area | What earns it | What loses it |
|---|---|---|
| Requirement scoping | You ask who the users are, what scale you're at, and which features matter, then write the answers down before you design. | Drawing boxes in the first minute. |
| Architecture coherence | Components that fit together, clear data flow, and APIs you could actually call. | A diagram of popular technology names with no arrows that mean anything. |
| Data-layer reasoning | A database choice you justify against the access pattern and the consistency it needs. | "We'll use NoSQL because it scales." |
| Capacity estimation | Rough numbers you calculate yourself: requests per second, storage per year, bandwidth. | No numbers at all, or numbers you never use. |
| Resilience thinking | You find your own single points of failure and say what degrades when a part goes down. | A final design with one database and no plan for when it dies. |
The company-style system-design templates add operational thinking (monitoring, deployment, graceful degradation, and in the cloud-focused one, cost). They also look explicitly for two things:
- Did you drive the design, or wait to be led? Waiting for the interviewer to tell you what to do next is named as a failure mode.
- Did you back every technology with how it works? Naming Kafka, Redis and Cassandra in one breath, without explaining what each one does for this design, is called out in the rubric as a failure mode ("buzzword bingo").
The trap that catches well-prepared people
The fundamentals rubric names this failure mode outright: reciting a memorized diagram without adapting it when the requirements change.
Good interviewers don't re-ask you about the design you've already drawn. They change the problem: the budget is halved, a new region is added, writes now have to be strongly consistent. Then they watch what you do. If your answer is the same diagram you memorized from a prep site, it shows.
That's why "prep that sticks" means practising reasoning out loud under a changing problem. Reading more architectures doesn't train that.
How to prepare, in order
- Write a 2-minute opening script. Functional requirements, non-functional requirements, scale, and the one thing that must never fail. Say it at the start of every practice round until it's automatic.
- Do the math out loud. Keep a few reference numbers in your head (seconds in a day, the rough size of an image or a row) and get comfortable doing quick multiplication on the whiteboard. The rubric looks for proactive, back-of-the-envelope estimates, so the habit matters more than being exact.
- For every component, prepare a "why" and a "what breaks first". If you can't say what breaks first, you don't understand that component yet.
- Practise against a moving target. Get a friend, or a practice interviewer, to change a constraint halfway through. Your goal is to update the design calmly and say what you're trading away.
- Narrate while you draw. A silent minute at the whiteboard is a minute the interviewer can't score. "I'm putting a queue here because the upload path shouldn't wait on thumbnail generation" is the kind of sentence that earns credit.
- Leave 10 minutes for failure. Plan your time so you reach resilience. It's a scored area, and you can't earn it from a phase you never got to.
What a Hyrr practice system-design interview is like
If you want reps against a scored rubric before the real thing:
- A live AI interviewer and a shared whiteboard. You talk through the design and draw it. The interviewer sees your whiteboard as it changes and asks about what you actually drew. It will not draw the design for you; in an assessment, the drawing is your work.
- A quiet stretch at the board is fine. Working on the board counts as working, so the interviewer won't jump in the moment you stop talking. A long silence still gets a check-in, and you score on what you explain, so talk it through once the sketch is down.
- The interviewer pushes back. Expect follow-ups on your choices and constraints that change mid-design. That's exactly the trap above, and you can practise it safely here.
- You're scored on what you say and draw, not on how you sound. Accent and speech rhythm are excluded from scoring.
- You get a question-by-question report afterwards, with feedback and a replay of your whiteboard. From there you can retake the same interview to see whether you improved, drill the questions you scored lowest on (including whiteboard answers), or turn the report into a study plan with a live voice trainer.
Practice interviews use credits from your Hyrr balance. There are general System Design Fundamentals interviews and company-style ones, from 30 to 60 minutes depending on the template.