What system design interviews are actually testing

System design interviews feel different from coding interviews because there's no single correct answer to converge on. That's disorienting the first few times, but it's also the entire point: the interviewer is evaluating your process, not grading you against a hidden reference architecture.

What's actually being scored

• Clarifying the problem first. Jumping straight to a design for an under-specified problem is a common early mistake — "design a URL shortener" has a very different shape at 100 users/day versus 100 million.
• Reasoning about tradeoffs out loud. Every real design decision trades something for something else (consistency for availability, cost for latency, simplicity for flexibility). Naming the tradeoff you're making, and why, is worth more than picking the "right" answer silently.
• Adjusting under new constraints. A good interviewer will add a requirement partway through ("now assume 10x the traffic") specifically to see whether your design bends or breaks.

What it's not testing

Memorized architecture diagrams, buzzword fluency ("we'll use microservices and Kafka"), or knowledge of one specific company's actual production stack. Naming a technology without being able to explain what problem it solves for this design reads as memorization, not understanding.

A practical starting habit

Before proposing anything, restate the problem in your own words and ask 2-3 clarifying questions (scale, read/write ratio, consistency requirements). This single habit fixes the most common failure mode: designing confidently for the wrong problem.