Templates

System design interview rubric and scoring template

For the people running the interview, not taking it: six dimensions to score, what good looks like at each level, and how to turn scores into a decision.

By the Ryz Labs team · Updated October 2026

A system design interview rubric scores a candidate on a fixed set of dimensions, usually requirements, high-level design, data modeling, trade-offs, reliability and communication, against written expectations for the level you are hiring. The key is level calibration: a mid-level engineer who designs a working system with sensible components meets the bar, while a staff engineer must also drive the conversation, quantify load and explain what they would measure in production. This template gives you the dimensions, the anchors per level and the decision rule.

System design interview rubric

1. Dimensions and what to look for

Dimension	Weight	What a strong answer shows	Red flags
Requirements and scope	15%	Asks about users, scale, latency and consistency needs before drawing; states assumptions out loud	Starts drawing boxes immediately; never asks about scale
High-level design	20%	Clear components and data flow that satisfy the stated requirements	Lists technologies without explaining how data moves
Data model and storage	15%	Chooses storage by access pattern; defines keys, indexes and partitioning	Picks a database by brand; no schema
Trade-offs and judgment	20%	Names at least two options for key decisions and explains why one wins here	Only one option considered; buzzwords instead of reasons
Reliability and operations	15%	Failure modes, retries, idempotency, monitoring, what gets paged	Assumes nothing fails; no metrics
Communication and collaboration	15%	Structures the session, checks in, takes hints and builds on them	Monologue; ignores interviewer input

2. Level expectations (what "meets the bar" means)

Dimension	Mid-level	Senior	Staff or principal
Requirements and scope	Clarifies main requirements when prompted	Drives requirements; estimates load roughly	Quantifies load and cost; spots the requirement that changes the design
High-level design	Working design for the core use case	Complete design including async work and caching	Design that evolves: v1 now, what changes at 10x
Data model and storage	Reasonable schema for the main entities	Partitioning and indexing tied to queries	Consistency model choices and their user-visible effects
Trade-offs and judgment	Explains choices when asked	Compares options unprompted	Makes the call under ambiguity and says what would change it
Reliability and operations	Mentions retries and monitoring	Designs for partial failure and backpressure	Defines SLOs, rollout strategy and on-call impact
Communication and collaboration	Clear when guided	Leads the session	Teaches; makes the interviewer's job easy

3. Scoring sheet

Dimension	Weight	Score (1-4)	Weighted	Evidence
Requirements and scope	0.15	[1-4]	[=weight x score]	[Notes]
High-level design	0.20	[1-4]	[ ]	[Notes]
Data model and storage	0.15	[1-4]	[ ]	[Notes]
Trade-offs and judgment	0.20	[1-4]	[ ]	[Notes]
Reliability and operations	0.15	[1-4]	[ ]	[Notes]
Communication and collaboration	0.15	[1-4]	[ ]	[Notes]
Total	1.00		[Sum]	Decision rule: hire at 3.0+ with no 1s; discuss 2.6-2.9

Use this template

How to use this system design rubric

Pick one prompt per level and reuse it across candidates so scores are comparable. Prompts close to your real systems give better signal than famous puzzles.
Adjust the weights for the role. A platform role may weight reliability at 25%; a product engineering role may weight requirements and data model higher.
Read the level expectations row for your target level before the interview, and keep it open while you take notes.
Take notes on what the candidate asked, drew and decided, with timestamps if you can. Score each dimension from the notes after the session.
Multiply each score by its weight and sum. Apply the decision rule, and write one sentence on the level you observed.
Bring the scoring sheet to the debrief and compare evidence with the coding and domain interviews.

Example: one scored dimension

Dimension	Score	Evidence
Trade-offs and judgment (senior target)	3	For the notification service, compared a queue per channel with a single queue plus routing, and chose per-channel queues to isolate a slow SMS provider. Did not discuss cost of the extra infrastructure until asked.

Common mistakes when scoring system design

Rewarding vocabulary. Naming Kafka, Redis and Kubernetes is not design. Score how data moves and why.
Scoring every level the same. A mid-level candidate who needs prompts on load estimation can still meet the bar. A staff candidate cannot.
Letting the interviewer drive. If you led the whole session, you scored yourself. Note how much prompting was needed.
A famous prompt with memorized answers. "Design Twitter" rewards preparation. A prompt from your own domain rewards judgment.
Ignoring operations. Many production problems are about failure, rollout and monitoring. If the rubric skips them, you will hire people who skip them.

Want senior engineers who already pass this bar?

Ryz screens engineers through structured technical interviews before you ever see a profile, and only the top 1% of the tens of thousands we interview make it. Senior engineers and tech leads join your team, reporting to your leads, on US business hours including New York hours. Typical cost is $7,000 to $15,000 per engineer per month. Talk to us to scope your team, or browse tech leads and solutions architects.

FAQ

What do interviewers look for in a system design interview?

They look for whether the candidate clarifies requirements, produces a design that meets them, models data for the real access patterns, compares options and explains trade-offs, plans for failure and monitoring, and communicates clearly throughout. The bar for each rises with the level being hired.

How do you score a system design interview?

Score each dimension from 1 to 4 against written expectations for the target level, multiply by the dimension weight and sum. Require written evidence for every score, and apply a decision rule such as hire at 3.0 or above with no dimension scored 1.

Should junior engineers get a system design interview?

Usually not a full one. For junior roles, a short design discussion about a feature they built, or an object and API design exercise, gives better signal than a distributed systems prompt.

How long should a system design interview be?

Most teams use 45 to 60 minutes: about 5 minutes on requirements, 25 to 35 on the design, 10 on deep dives into one or two components and 5 for the candidate's questions. Shorter sessions rarely reach reliability and trade-offs, which carry the most signal.

How is a system design rubric different for AI systems?

Add dimensions for retrieval and data access, evaluation and model failure handling. A strong candidate explains how they would know the system gives correct answers, how they would catch quality regressions after a model update and how they would control cost per request.

Questions we didn't answer? Email info@ryzlabs.com.