The Conversation
A system design interview is less like a test and more like a design review meeting with a senior colleague. Unlike coding interviews where a solution either passes or fails, system design interviews have no single "correct" answer. They are open-ended discussions designed to test how you handle ambiguity and trade-offs — the same skills you use every day as an engineer.
You might be asked: "Design Twitter" or "Design a Rate Limiter". The interviewer is not expecting you to produce a production-ready architecture in 45 minutes. They are watching how you think.
What They Look For
Interviewers evaluate four dimensions simultaneously:
- Requirements Gathering: Do you ask clarifying questions before drawing a single box, or do you assume you already know what to build? Jumping straight to a solution without scoping the problem is the single most common failure mode.
- Breadth: Do you know the standard building blocks — Load Balancers, CDNs, Caches, Message Queues, SQL vs. NoSQL databases? Can you assemble them into a coherent architecture?
- Depth: Can you drill down into one specific area when asked? For example: "How exactly does your database replication handle a primary failure?" Breadth gets you in the door; depth gets you the offer.
- Trade-offs: Can you explain why you chose one approach over another? "I chose eventual consistency here because the cost of a stale read is low, but the cost of unavailability is high." This is the most important skill of all.
The interview is a simulation of your future job. Senior engineers spend most of their time navigating exactly these four dimensions — scoping requirements, choosing tools, going deep on hard problems, and defending trade-offs to stakeholders.