system-design

Self-Grading Checklist

After a practice design, how do you know if it was good? This chapter is a concrete rubric you apply to your own attempts (or a partner’s) to score them like an interviewer would — turning vague “that felt ok” into specific, actionable feedback. Print it, use it after every mock.

Prerequisites: Rubrics, Common Mistakes Time to read: ~10 minutes; use as a reference after every practice

How to grade yourself

🚨 Grade against the process, not the “right answer” — because there isn’t one. Record your mock (audio is enough) or have a partner take notes, then score each dimension below 1–5. Be harsh: the interview is harsh. Your lowest-scoring dimensions are your study plan.

Scoring key per item: 1 = didn’t do it · 3 = did it adequately · 5 = did it fluently and drove it. Aim for all 4s before you interview.

The rubric

1. Requirements & scoping (before any design)

Asked clarifying questions before designing (didn’t jump to a solution).
Separated functional from non-functional requirements.
Interpreted the NFRs into design directions (“read-heavy → cache,” “money → strong consistency”).
Explicitly stated what’s out of scope.
Confirmed scope with the interviewer before proceeding.

🚨 The #1 place candidates lose points is skipping this. If you scored low here, fix it first — it’s the cheapest, highest-impact improvement.

2. Estimation

Did back-of-envelope math (QPS, storage, bandwidth) with stated assumptions.
Used the numbers to drive a decision (not math for its own sake).
Rounded sensibly and got the order of magnitude right.
Identified the dominant cost (read-heavy? storage-heavy? write-heavy?).

3. High-level design

Drew a clean architecture: client → LB → services → data stores.
Covered both the read path and the write path.
Chose appropriate components and could name why each.
Kept the right altitude (didn’t rabbit-hole into one box too early).
Had a coherent data model / API sketch.

4. Deep dives

Went deep on the component that actually matters for this problem.
Offered options with trade-offs, then chose one with justification.
Named the key hard problem of the design (hot key, oversell, fan-out, consistency).
Handled at least one edge case / failure mode unprompted.

5. Trade-offs & communication

Named trade-offs out loud in trade-off vocabulary for major decisions.
Justified choices (“X because Y, accepting Z”) rather than asserting them.
Drove the conversation — proposed next steps, didn’t wait to be interrogated.
Connected decisions back to the requirements (“aligns with availability, which we chose up front”).
Communicated clearly and structured — thinking out loud, organized.

6. Handling pressure & the unknown

When challenged, reasoned calmly instead of freezing or getting defensive.
When unsure, reasoned from principles instead of bluffing a confident falsehood.
Adapted the design when the interviewer added a requirement.
Managed time — reached a complete design + summary in ~45 minutes.

7. Closing

Summarized the design and its main trade-offs at the end.
Flagged what you’d do with more time / known limitations.

Scoring interpretation

Add up your section averages:

If your weakest sections are…	Your study focus
Requirements / scoping	Requirements Gathering; force clarification in every mock
Estimation	Estimation Drills; do 5/day for a week
High-level design	Building Blocks; Component Drills
Deep dives	Deep Dives; re-do case studies focusing on the hard part
Trade-offs / communication	Trade-off Drills; practice narrating aloud
Pressure / unknowns	Handling Uncertainty; more mocks with a tough partner
Closing	Practice a 60-second summary at the end of every mock

🚨 Don’t average away a 1. A single dimension you completely miss (e.g. never estimating, or never naming a trade-off) can sink an otherwise good interview. Bring every dimension to at least a 3 before polishing your 4s to 5s.

The one-line self-assessment

After each mock, answer honestly: “If I were the interviewer, would I hire based on that?” — and why or why not, in one sentence. That gut check, repeated, calibrates you faster than any rubric. Pair it with the specific dimension scores above so the gut feeling becomes actionable.

Grading a partner (or being graded)

When you grade someone else (do this — it sharpens your own eye):

Take notes on moves, not just the outcome — mark each 🟢 good move and 🔴 miss as they happen (see the annotated transcripts).
Give specific, kind feedback: “You designed well but never estimated, so the caching decision looked unmotivated — next time do the read/write ratio first.”
Focus on the highest-leverage fix, not a laundry list. One or two concrete changes per mock.

🛠️ Try it

1. Grade your last attempt now. Take a design you did recently, run it through all seven sections, score each 1–5. Your lowest two sections are this week’s focus.

2. Track scores over time. Keep a running table of your section scores across mocks. Watching a weak dimension climb from 2 → 4 is motivating and proves the practice works.

3. Swap grading with a partner. Grade each other’s mocks with this rubric. Seeing your blind spots through someone else’s scoring — and spotting theirs — accelerates both of you.