The System Design Interview: What Interviewers Actually Want

What Two Hundred Interviews Taught Me

I have conducted over two hundred system design interviews as both a hiring manager and a mock interview coach. The patterns that separate strong from exceptional candidates are consistent, and almost none of them are about knowing the right frameworks.

What Interviewers Actually Want to See

The purpose of a system design interview is not to test whether you can design Twitter in 45 minutes. It is to observe how you think under uncertainty. Interviewers want to see: How do you clarify requirements before diving in? How do you make trade-off decisions and articulate them explicitly? How do you respond when they poke holes in your design?

The candidates who struggle most jump immediately to drawing boxes and arrows. They produce technically correct designs but reveal nothing about their thinking process. Interviewers are not grading the diagram — they are grading the conversation that produced it.

The First Ten Minutes Are Everything

Spend the first 8–10 minutes purely on requirements clarification. What are the scale targets? Read-heavy or write-heavy? Strong or eventual consistency? Geographic distribution requirements? Candidates who skip this phase produce designs that solve the wrong problem. When the interviewer introduces a constraint that invalidates their design, they have no foundation to pivot from.

Trade-offs Are the Interview

Every architectural decision is a trade-off. SQL vs NoSQL is not a quiz question — it is a trade-off between consistency guarantees, query flexibility, and scale. When you choose one, name the trade-off explicitly: "I am choosing PostgreSQL here because the join patterns favour relational data, and we can shard at the application layer if we hit write throughput limits."

Candidates who say "I would use Kafka" without explaining why are giving a vocabulary test. Candidates who say "I would use Kafka because the consumer group model lets us fan out to multiple pipelines independently, which matters because..." are designing.

Back-of-Envelope Estimation

Estimation is a forcing function for realism. If you estimate 10 million writes per day, that is ~115 writes/second — comfortably within a single Postgres instance. If you estimate 1 billion writes per day, that is ~11,500 writes/second — requiring a very different architecture. The numbers should drive your design decisions, not the other way around.