Two candidates get the same prompt: design a service that lets users share short video clips. The first draws a clean diagram in ten minutes, names every popular component and speaks with total confidence. The second starts slower, asks who the users are, says which part she is unsure about and makes a different choice for storage, giving a clear reason. Interviewer A rates the first candidate "strong". Interviewer B, who sat in on the same session, rates the second "strong". Their notes barely overlap.
This is an illustrative scenario, not a documented hiring incident. It is common enough that most engineering teams will recognise it. Both designs were defensible. What differed was what each interviewer was scoring: fluency, speed, familiarity with their own preferred architecture, or the quality of the reasoning. This guide is for engineering managers and engineering enablement leads who need a system design interview rubric that scores senior candidates on the same evidence, so two interviewers can reach the same conclusion for the same reasons. Every criterion below should be validated by a senior engineer and reviewed for fairness before you use it in a real hiring decision.
What is a system design interview rubric?
A system design interview rubric is a scoring guide that lists what you are looking for, what each score looks like in observable behaviour, and which mistakes cannot be offset by strengths elsewhere. It sits next to the question, so each interviewer collects evidence against the same criteria. Google's guide to structured interviewing calls these scoring tools "rubrics" and notes that researchers call them "behaviorally-anchored rating scales". It reports that structured interviews give higher predictive validity and smaller differences between demographic groups, and that pre-made questions, guides and rubrics save an average of 40 minutes per interview. You can read the full guidance in Google re:Work: A guide to structured interviewing.
Public examples are easy to find, and most are written for candidates. This guide is for the other side of the table.
עובדות מהירות
| שאלה | תשובה קצרה |
|---|---|
| What are you assessing? | How a candidate reasons about an open-ended architecture problem, not how many components they can name. |
| What goes in a rubric? | Criteria, anchored scores, and a list of critical errors. |
| כמה קריטריונים? | Three to five. Fewer criteria are easier to score and calibrate; keep only those you can anchor with observable evidence. |
| Who validates it? | A senior engineer who does the work, plus your people team for fairness. |
| How do you keep it consistent? | Score independently first, then compare evidence in a calibration session. |
| What can a rubric not do? | Fix an unclear role, an unrepresentative task or interviewers who are not trained to use it. |
| איך אתה יודע שזה עובד? | Interviewers' scores agree more on the same recording or write-up, and the scores line up with later performance. |
1. Define the performance you are assessing
Start with the work, not the topic. For a senior engineer, the relevant task is usually: given an ambiguous problem, make and defend architectural decisions, and say what would change them. Write that as one sentence, and specify the role, level and the context the person would work in. A senior backend role at a payments company has a different bar from a senior platform role at a media company.
Also write what you are not assessing. Typing speed, familiarity with a particular cloud vendor and the ability to draw neatly on a shared whiteboard are common accidental criteria. If they are not part of the job, they should not move the score.
2. Choose a representative, unfamiliar task
Pick a problem that samples the real work and that candidates cannot have memorised. A widely known prompt ("design a URL shortener") rewards rehearsal. Use a problem from your own domain with the sensitive detail removed, and ask a senior engineer to solve it independently so you know what a reasonable range of answers looks like.
Accept that a single 45-minute problem samples only part of what a senior engineer does. It can show how someone handles ambiguity, constraints and trade-offs. It cannot show how they mentor, run a migration over months or handle a long incident. Say that in your hiring documentation so no one over-reads the score.
3. כתבו קריטריונים ועוגנים נצפים
Build criteria around evidence you can write down. A short, workable set for a senior system design round:
| קריטריון | ראיות נצפות |
|---|---|
| מסגור הבעיה | Asks clarifying questions, states assumptions and agrees the scope before drawing. |
| Trade-off reasoning | Names at least two options for a key decision, says what each costs and chooses with a reason. |
| עומק | Goes deep on one or two components when asked, without losing the whole design. |
| טיפול בשינוי | Adjusts the design when a constraint is added and explains what is now weaker. |
| תקשורת | Makes the design understandable to a colleague who was not in the room. |
Score each criterion from 0 to 2: 0 is absent or unsupported, 1 is partial with relevant omissions, and 2 is complete and justified against the agreed criteria. The anchors matter more than the scale. For trade-off reasoning, for example, a 0 is "names a technology without saying why", a 1 is "gives a reason but not the cost of the alternative", and a 2 is "compares options against the stated constraints and says what they would give up".
Define critical errors separately, such as ignoring a data-protection requirement the interviewer stated or proposing a design that cannot meet a stated hard constraint. An average score must never hide a critical error. Avoid scoring on confidence or speed; a quiet candidate who reasons carefully should not be penalised for style. Our guide to assessing judgment and problem solving covers how to write criteria for reasoning tasks.
4. כיול מעריכים והפעלת פיילוט
A rubric that two people read differently is not yet a rubric. Before you use it live:
- Choose an example. Use a written design from a colleague who is not in the hiring process, or a mock interview recording with the person's consent.
- ציון באופן עצמאי. Each assessor writes the evidence for each criterion before seeing anyone else's scores.
- Compare evidence. Where scores differ by more than a point, find out whether the anchor was ambiguous or the assessors noticed different things. Rewrite the anchor.
- Repeat on a second example. Stop when disagreements are about judgement, not wording.
Google's guide pairs interviewer training with calibration so that interviewers are consistent and confident in their assessments, which is the same idea. Ask a specialist, such as an engineering manager from a neighbouring team, to review the case and the anchors, and ask your people team to review the process for fairness and legal requirements in your hiring regions.
5. עבדו על דוגמה מציאותית
לדוגמה. מהנדס בכיר צריך לאמת את המקרה ולענות על קריטריונים לפני השימוש.
המקרה. Candidates design a notification service for a delivery app: customers get updates when an order changes status. Scale is described only as "a few million orders a day, mostly at meal times".
ניסיון ראשון. "I would put a message queue between the order service and a notification worker, store every event in a database and send push notifications." The structure is reasonable, but the candidate did not ask what channels are needed, what happens if a notification is late or sent twice, or what the peak load means for the queue.
Interviewer feedback and retry. The interviewer asks, "What is worse here: a late notification or a duplicate one?" Interviewers should have a standard follow-up for each criterion, so every candidate gets the same chance to show the skill.
ניסיון חזק יותר. "A duplicate is worse for push, because people would stop trusting the app, so I would make sending idempotent with an order and status key. For SMS I would accept occasional duplicates because cost matters more. Peak load at meal times means the queue should absorb bursts and workers should scale on queue depth. I am unsure how strict the delivery-time promise is, so I would ask the product owner before choosing between a simple retry policy and a priority lane for time-critical updates."
מְנִיָה. Against the rubric, this answer scores 2 on trade-off reasoning (two options, costs, a reason), 2 on problem framing (states assumptions, asks a question), and 1 on handling change until the interviewer adds a constraint. Notice that the interviewer is scoring evidence, not matching the candidate's design to their own preferred one.
היכן שהעברת מידע אינטראקטיבית עוזרת
The skill you are building here is for interviewers, and interactive practice suits it. In a live calibration session, show the example design, ask every assessor to score each criterion privately, and reveal the spread before discussion. People commit to a score before they hear the loudest voice in the room, and the disagreements point to the anchors that need rewriting. The same example and rubric can run self-paced for new interviewers who join later, with a live session to discuss the ambiguous cases. AhaSlides supports interactive learning and moving between live and self-paced delivery. It is a presentation and learning tool, not an interview platform or an applicant tracking system, so keep real candidate data in your hiring tools. Check any specific authoring, feedback or reporting function you plan to rely on against your own workflow. For help choosing formats, see our guide to מתי להשתמש בלמידה אדפטיבית, אינטראקטיבית וחיה, and for feedback design see עיצוב תרגול אינטראקטיבי עם משוב שימושי.
מדוד מה השתנה
Decide in advance what would show the rubric is working. Two measures are practical. First, agreement: on the same recorded or written design, do independent interviewers land closer together after calibration than before? Define who is included, the denominator and the timing. Second, relevance: after a few months, do the scores relate to how new hires perform in design reviews? With a small number of hires this will be a rough signal only, so treat it as a prompt to review the rubric, not as proof. If results improve, check what else changed at the same time, such as a new role definition or a different sourcing channel, before crediting the rubric.
אילוצים שעשויים להישאר
- Representativeness. One problem samples part of the job. Pair it with other evidence such as a work sample or a structured conversation about past decisions.
- הֲגִינוּת. A rubric reduces variation, but it does not remove bias on its own. Review the case and anchors for assumptions about background, and check outcomes across groups with your people team.
- Interviewer time. Calibration takes hours. Without it, the rubric is just a longer form.
- Role clarity. If the team does not agree what "senior" means, no rubric will settle it.
- Legal context. Hiring assessment is regulated differently in different places. Check local requirements before you change a process.
שאלות נפוצות
What should a system design interview rubric include?
Three to five criteria such as problem framing, trade-off reasoning, depth, handling change and communication, a 0 to 2 anchored score for each, and a separate list of critical errors.
How do you stop interviewers scoring on confidence?
Make them write the observable evidence for each criterion before giving a score, and anchor each score to behaviour, such as "compares two options and states the cost of the one not chosen".
How long should a system design interview be?
Interviews are often scheduled for around an hour, but the right length is whatever lets a candidate show every criterion in your rubric. Test it with a pilot.
Can a rubric make hiring objective?
It makes it more consistent and easier to audit, but judgement remains. The aim is for interviewers to agree for the same reasons, not to remove people from the decision.
איפה להתחיל
Pick one open role and write the one-sentence performance statement. Draft three criteria with anchors and a short critical-error list, then have a senior engineer solve your case independently. Run one calibration session with the people who will interview, rewrite the anchors that caused disagreement, and pilot the rubric on a small number of real interviews before you use it widely.
To see how a calibration session could run live with your own interviewers, and be reused self-paced afterwards, explore AhaSlides.
