System design interview questions — what "design a URL shortener" is actually testing
The prompt is always vague on purpose. Here's what a system design round is really scoring, the questions that come up across every prompt, and why the diagram matters less than the trade-offs you say out loud.
"Design a URL shortener." "Design Twitter's timeline." "Design a rate limiter." The prompts vary, but system design rounds are graded on the same handful of things every time, and almost nobody explains that plainly before you walk in.
What's actually being scored
Not whether your final architecture is correct — there usually isn't one correct answer, and the interviewer has seen a hundred valid designs for the same prompt. What they're scoring is whether you can turn a vague requirement into specific numbers, and whether you can defend a trade-off out loud instead of just naming both sides of it.
A design that goes straight to "we'll use a load balancer, then microservices, then a cache" without ever asking how many requests per second this needs to handle is a worse answer than a simpler design that's grounded in real constraints — even if the simple one sounds less impressive.
The questions that show up regardless of the prompt
"What's your estimated scale?" Every design round starts here, and skipping it is the single most common reason a strong engineer gets a weak score. Requests per second, read/write ratio, data size after a year — rough numbers are fine, but you need numbers. A cache-everything design for 100 requests/day is over-engineering; the same design for 100,000 requests/second is correct. The interviewer can't tell which one you're building until you say a number.
"Why a database, not a cache — or why both?" This tests whether you understand consistency versus speed as a real trade-off, not a vocabulary word. The honest answer names what you're willing to lose: a cache can serve a stale value for a few seconds, and that's fine for a view counter and not fine for a bank balance.
"What happens when this component fails?" Not if — when. A design that only works when every service is healthy isn't a system design, it's a happy path. Naming the failure mode (this node dies, this queue backs up, this write fails halfway) and what happens next is worth more than another layer of the diagram.
"How would you shard this?" Comes up whenever the data is too big for one machine, which in a design round is usually assumed from the start. The follow-up that separates people: what happens when one shard gets way more traffic than the others (a celebrity's account, a viral post) — a plain hash-based shard doesn't fix that on its own, and saying so is the actual signal.
"What would you cut if you had one week instead of six months?" A trick question in the sense that there's no design-document answer to it. It's testing whether you can rank your own design by what matters most, which is what a senior engineer does on a real project when the deadline moves.
What trips people up
Going deep on one component nobody asked about. A candidate who spends fifteen minutes designing the perfect consistent-hashing scheme for a component that wasn't the bottleneck has demonstrated knowledge, not judgment — and judgment is the thing being graded.
The other common failure is silence during the estimation step. Rough napkin math said out loud — "let's say 10 million users, 10% active daily, each posting twice a day, so roughly 2 million writes a day, about 25 a second average" — is worth more than a precise number you worked out in your head and never explained.
Prepair asks system-design-style questions at the senior level — trade-offs, failure modes, scaling decisions — as part of the interview, spoken out loud and scored on substance. It's not a dedicated whiteboard round with a live diagram; it's practice for saying the reasoning above clearly under pressure, which is usually the part that actually breaks first. Try a free interview — 3 a month, no card required.