Courses › System Design › Getting Started

What Interviewers Look For

The grading rubric and how expectations change from mid-level to senior to staff.

A system design interview has no single correct answer, so it's graded on how you design rather than what you end up with. Knowing the rubric — and how it shifts between mid-level, senior and staff — tells you where to spend your 45 minutes. Every breakdown in this course ends with a "What's expected at each level" section; this page explains the overall picture behind those sections.

What's being assessed

Most companies score some version of these four areas:

[!TIP] Trade-offs are the currency Almost every strong signal comes from naming a choice and its cost: "Fan-out on write makes reads fast but celebrity posts expensive, so I'll use a hybrid." A design with no trade-offs mentioned looks memorized, even when it's correct.

How expectations change by level

Mid-level (L4 / E4)

  • Produce a working end-to-end design that satisfies the functional requirements.
  • Know the standard building blocks — databases, caches, queues, load balancers — and use them sensibly.
  • Go reasonably deep on one or two areas, often with interviewer guidance.
  • It's fine if the interviewer drives some of the deep dives. Breadth and correctness matter more than novel insight.

Senior (L5 / E5)

  • Drive the interview yourself: requirements, a clean high-level design, then proactively identify the two or three hardest problems and go deep on them.
  • Explain trade-offs between alternatives and justify choices with numbers ("50k reads per second is too many for one primary, so…").
  • Handle failure modes: what happens when this component dies, this request is retried, this queue backs up?
  • Show real depth in at least a couple of technologies — how they partition, replicate and fail.

Staff (L6 / E6) and above

  • Everything above, with speed: a solid design quickly, leaving most of the time for the genuinely hard problems.
  • Identify problems the interviewer didn't prompt: operational complexity, migration paths, multi-region, cost, org and team boundaries.
  • Make judgment calls under ambiguity and explain why the simpler option is often better.
  • Teach the interviewer something — depth from real experience usually shows here.

Signals that hurt

  • Jumping into boxes before agreeing on requirements
  • Naming technologies without saying why ("I'll use Kafka" with no reason)
  • Staying at the surface for the whole interview — never going deep on anything
  • Over-engineering a simple problem — sharding a system that fits on one machine
  • Ignoring the interviewer's hints or arguing with their constraints
  • Running out of time before the core flow works

See Common Mistakes for these in more detail.

Using this course to hit the bar

  • Follow the Delivery Framework so your time goes where it should.
  • Learn the Core Concepts and a handful of Key Technologies deeply rather than many shallowly.
  • For each breakdown, read the "What's expected at each level" section and check that you could reach the level you're interviewing for without the article.

[!INTERVIEW] Make your level visible Senior and staff signals often come from a single sentence at the right moment: "Before we go further, the riskiest part of this design is the hot-key problem on popular events — I'd like to spend most of our deep-dive time there." It shows you see the whole problem and are prioritizing.