System design interviews

Day 26: Beating the System Design Rubric Without Losing Your Judgement

You can give the right answer in a system design round and still fail it. For a lot of mid-level engineers, this round decides whether a senior offer happens, and it doesn't score quite the same thing the senior job needs. Once you know what the scorecard is listening for, you can pass without pretending to be a different engineer.

1. The scorecard moment

I was interviewing a candidate for a senior backend role. The prompt was a standard one: design a scheduled notification system for a B2B product. They spent the first ten minutes asking questions. Who sends notifications? How many tenants are there? What does 'late' mean to a customer: one second, or one minute? What happens if a notification goes out twice?

Then they committed to Postgres and cron. A notifications table with a status column. A cron job every minute that claims due rows with SELECT ... FOR UPDATE SKIP LOCKED. An idempotency key so retries don't double-send, and a dashboard query for stuck rows. They walked through how it fails, how you'd notice, and how you'd recover. Three boxes on the whiteboard.

Then I got to the scorecard. One line read 'Demonstrates ability to design for scale'. My pen hovered over it while two versions of me argued. The ex-CTO said this was exactly the design I'd have wanted in year one of a startup: cheap, debuggable, and one person can run it. The EM running a structured loop said the rubric exists to stop me hiring on gut feel, and this candidate never mentioned queues or partitioning, or any traffic number above a few thousand.

What I actually wrote: 'Excellent scoping. Clear failure-mode reasoning. Simplest viable design, well defended. Did not demonstrate scale.' In the margin: 'Would trust on call.' My overall call was Lean No Hire.

2. What happened next

In the debrief, the other interviewers had scored coding and behavioural positively. Mine was the split vote. Someone asked, 'Did they show they could operate at scale?' Honestly, no. Not in the vocabulary the rubric was listening for. My margin note didn't map to any rubric line, so it carried no weight. The rubric won. That's partly what rubrics are for.

The uncomfortable part came later. I pictured the notification backlog growing at 2am and asked myself who I'd want beside me. It was that candidate, the one who asked what 'late' means and wrote the stuck-row query before anyone asked for it. I'd failed the person I most wanted on my team, and I'd done it by following the process correctly.

The lesson isn't 'interviews are broken'. The rubric is a fixed constraint. The candidate didn't know which signals it was listening for, and that part can be learned.

3. What the interview is really grading

Most system design rubrics carry assumptions nobody says out loud. Here they are, next to what a founder or engineering leader actually pays a senior engineer for:

• ▹The rubric assumes more components means more expertise. The job rewards the fewest components that meet the requirement.
• ▹The rubric listens for scale vocabulary: sharding, consistent hashing, fan-out, CQRS. The job needs scoping vocabulary. Who are the users, how many are there, what does 'wrong' cost, what does 'late' mean?
• ▹The rubric assumes a hypothetical 100M users. On the job you have real numbers, usually much smaller, with growth you can see coming.
• ▹Breadth across lots of technologies scores well. The job rewards operability: can a small team debug this at 2am?
• ▹Cost of being wrong rarely appears on the rubric, yet it's most of the job. Make reversible decisions fast and irreversible ones slowly.

You don't have to pick a column. Your job is to tick the left one while keeping the right one in plain view.

4. Why this matters more in the agent era

Ask any capable coding agent to 'design Twitter' and within seconds you'll have a load balancer, a fan-out service, Kafka, Redis, a CDN and a sharded database. Boxes are cheap now, so a senior engineer has to earn their keep somewhere else: deciding which boxes to leave out, and spotting the ones the model added only because the prompt pattern-matched to 'big system'. When agents write much of a team's code, every unnecessary component means more surface for agents to generate, more drift to review, and more on-call burden for humans. I expect interview loops to catch up. One obvious next exercise: hand the candidate an AI-generated design and ask them to cut it down. Restraint is becoming the signal worth looking for.

5. The move: simple first, scale on a trigger

Here's the same candidate's answer, replayed so it passes. The design doesn't change at all. The difference is that every box they left out becomes an explicit, measurable decision.

• ▹Scope (about 10 minutes). Ask about users, tenants, volume today and in 12 to 18 months, latency tolerance, duplicate tolerance, and who's on call. Then read the numbers back out loud: 'So we're designing for roughly N sends per day, with about a minute of tolerance.'
• ▹Commit. 'I'll start with Postgres and a cron worker. It meets the latency requirement, it's transactional so idempotency is easy, and one engineer can run it.'
• ▹For each box you didn't add, name the trigger that would bring it in. For example: 'A queue when write spikes exceed X per second for more than a few minutes, because that's when the cron claim query starts competing with the app's writes.'
• ▹'Read replicas when p95 on the status dashboard crosses Y ms under normal load.'
• ▹'Shard or isolate by tenant once one tenant is Z% of load, because at that point one noisy customer can hurt everyone else.'

Pick X, Y and Z from the scoping numbers you just collected, not from a blog post. The exact values matter less than showing that a threshold exists and you know which metric to watch. Now 'demonstrated scale' is something the rubric can score. You've named every component the interviewer was waiting for, and you've explained why each one isn't there yet.

6. The 45-minute shape

Steal this timeline. The arrow under each step shows which rubric line it quietly ticks.

00-10  SCOPE
       users, volume now + 18mo, latency, duplicates, who's on call
       -> rubric: requirements gathering, communication

10-20  SIMPLEST VIABLE DESIGN
       commit to it, draw 3-4 boxes, walk one request end to end
       -> rubric: technical design, data modelling, API design

20-28  FAILURE + ON-CALL STORY
       what breaks first, how you'd detect it, how you'd recover
       -> rubric: reliability, trade-offs, operational maturity

28-38  SCALE TRIGGERS
       for each omitted component: metric, threshold, what you'd add
       -> rubric: designs for scale, depth of knowledge

38-45  WHAT I'D CUT WITH A TEAM OF THREE
       remove or defer one thing from your own design, and say why
       -> rubric: prioritisation, seniority signal, judgement

Where people trip up: they spend 20 minutes scoping and run out of time for triggers. They name triggers with no metric ('when it gets big'). Or they drop the simple design the moment the interviewer says '100M users'. If you get pushed, don't redesign from scratch. Walk your triggers in order: 'At that volume, triggers one and two have fired, so the design now looks like this.'

7. Phrases that keep your judgement visible and tick the scale box

• ▹"I'm deliberately not adding Kafka yet. Here's the number that would change my mind."
• ▹"Before I draw anything, can I check what 'late' costs the customer? That decides most of this design."
• ▹"This is what I'd ship this quarter. If you want to jump to 100x, I'll walk through which triggers fire, in order."
• ▹"The first thing to break is the claim query under write contention. I'd alert on the age of the oldest unsent due notification before users feel it."
• ▹"With only three engineers, I'd hold off on the read replica even after its trigger fires and accept a slower dashboard. On-call load matters more than that latency."

8. Side note for seniors and EMs who interview

Add one line to your rubric: 'Scoping and restraint: sized the problem before designing, and justified each component with a requirement or a named trigger.' I argued for this in our calibration session. I put two anonymised designs side by side: a three-box answer with triggers, and a ten-box answer with no numbers. Then I asked one question: 'Which one would you want to be on call for?' The room agreed fast. With the rubric line in place, that kind of agreement counts in the debrief instead of sitting in a margin note.

9. Closing the arc

Day 26 is about showing judgement in a format that doesn't measure it directly. The next few days apply the same skill in two other places. In negotiation, you present your value in someone else's frame. In your first 90 days, you earn the right to make the simple-first calls you described in the interview.

If I could rewrite that scorecard, I'd keep every word and add one line for the candidate: 'You did the hard part. You scoped it, you committed, and you knew how it breaks. You stopped one step short: say out loud what you left out and the number that would bring it back. The judgement was already there. The rubric just needed to hear it.'

Extend your knowledge

• ▹Read Dan McKinley's 'Choose Boring Technology' (talk and essay). It's the clearest case for spending your limited innovation budget carefully, and it hands you language you can use in interviews.
• ▹Read the 'Monitoring Distributed Systems' and 'Handling Overload' chapters of Google's free Site Reliability Engineering book. They'll help you pick realistic metrics for your triggers.
• ▹Try this: ask a coding agent to 'design a URL shortener at Google scale', cut its diagram down to the minimum, and write a trigger for every box you removed.
• ▹Run a timed mock with a peer using the 45-minute shape. Have them score you on the standard rubric plus 'scoping and restraint'.