System design interview questions: what is actually being scored

Almost nobody fails a system design round for choosing the wrong database. They fail for designing in silence, assuming requirements, or presenting one architecture as though alternatives did not exist.

The interviewer is watching how you think when the problem is deliberately underspecified — because that is what the job is.

Start by narrowing the problem

“Design Twitter” is not a question, it is an invitation to ask questions. How many users, read-heavy or write-heavy, what latency matters, what can be eventually consistent.

Five minutes of clarifying is not lost time — it is the first thing being scored. A candidate who starts drawing boxes immediately has told the interviewer they would do the same thing on a real project.

Write the constraints down where both of you can see them, then design against those numbers rather than against a general idea of scale.

Trade-offs are the answer

Every meaningful decision in the round has a cost. Caching buys latency and pays in staleness. Sharding buys write throughput and pays in cross-shard queries and operational pain.

Say the cost out loud. “I would put a cache here, which means accepting up to sixty seconds of staleness — fine for a feed, not fine for a balance” is the sentence the round exists to hear.

When you do not know something, say so and reason from what you do know. Bluffing is the fastest way to lose a technical interviewer, and they will follow up on exactly the thing you were vaguest about.

Failure modes, because production has them

Senior candidates are separated from mid-level ones here. What happens when this queue backs up, this region goes down, this dependency starts returning 500s at ten percent?

Nobody expects a complete answer. Raising the question unprompted is most of the mark.

Questions to practise

What costs people the round

Designing in silence for two minutes.

Think out loud. An unspoken thought scores zero — the interviewer can only mark what they hear.

Reaching for microservices or Kafka by reflex.

Justify every component from the constraints you established. Unjustified complexity reads as inexperience, not seniority.

Presenting one design as the only option.

Name the alternative you rejected and why. That comparison is the clearest evidence of judgment you can give.

Try it against Kai

System design, trade-offs, and war stories from production. You will be scored on technical communication, engineering depth, ownership & collaboration, with the transcript attached.

Other rounds