Most candidates walk into a system design interview thinking they need to memorize the architecture of Twitter, YouTube, or WhatsApp. They spend weeks cramming database choices and caching strategies. Then they get the interview, rattle off a rehearsed answer, and get rejected.
Why? Because interviewers are not testing whether you know the answer. They are testing whether you can think through a problem you have never seen before, make reasonable decisions under uncertainty, and communicate your reasoning clearly.
This lesson breaks down exactly what interviewers evaluate, how scoring works at top companies, and what separates a “lean no hire” from a “strong hire.”
The 5 Evaluation Dimensions
Every system design interview, whether at Google, Meta, Amazon, or a Series B startup, evaluates candidates across the same five dimensions. The weight of each may vary, but all five always matter.
Let us walk through each one in detail.
1. Problem Exploration
This is the first thing an interviewer observes: do you jump straight to drawing boxes, or do you first understand the problem?
Problem exploration means asking clarifying questions, identifying constraints, and scoping the problem before designing anything. It is the single most common failure mode in system design interviews — candidates who skip this step almost always end up designing the wrong system.
What good looks like:
Candidate: "Before I start designing, I'd like to understand the requirements.
Who are the primary users? Is this consumer-facing or internal?
What's the expected scale — are we talking thousands or millions
of daily active users?"
Candidate: "You mentioned a messaging system. Should I focus on 1:1 messaging,
group chats, or both? Do we need to support media like images
and videos, or text only?"
Candidate: "What's more important here — message delivery latency or
guaranteed ordering? That will significantly affect my design."What bad looks like:
Candidate: "OK, so we need a messaging system. I'll use a load balancer
in front of some web servers, a PostgreSQL database, and Redis
for caching. We can use WebSockets for real-time..."
[Interviewer thinking: They haven't asked a single question. They're
designing a system without knowing if it needs to handle 1,000 users
or 1 billion users.]The difference is night and day. The first candidate demonstrates that they understand real engineering is about solving the right problem, not just any problem. The second candidate shows they have memorized a template and are applying it blindly.
Senior vs Staff level:
- Senior engineers ask good clarifying questions and identify the main functional requirements.
- Staff engineers also uncover hidden requirements, identify edge cases the interviewer had not mentioned, and proactively scope the problem to a tractable size while explaining what they are deferring and why.
2. Technical Depth
This is the dimension most people focus on, and for good reason — you do need to know your stuff. But technical depth does not mean name-dropping technologies. It means understanding how things work under the hood and being able to reason about behavior at scale.
Strong signals:
- Explaining why you would choose a specific database, not just naming one
- Understanding the implications of your data model on query patterns
- Knowing how a technology actually works (e.g., how Redis handles expiration, how Kafka handles consumer offsets)
- Being able to reason about failure modes
Weak signals:
- “We’ll use Kafka for messaging” without explaining why or how
- Mentioning technologies you cannot explain
- Shallow knowledge across many tools but deep knowledge of none
Senior vs Staff level:
- Senior engineers demonstrate solid understanding of common components (databases, caches, queues, load balancers) and can design reasonable architectures.
- Staff engineers show deep expertise in specific areas, can reason about internals, understand non-obvious failure modes, and propose solutions to problems that require novel thinking.
3. Trade-off Analysis
This is arguably the dimension that separates hire from no-hire most consistently. Almost every design decision involves trade-offs, and interviewers want to see that you recognize and reason about them.
The spectrum:
- No hire: Makes decisions without acknowledging alternatives
- Lean no: Mentions that alternatives exist but does not compare them
- Lean yes: Compares alternatives with pros and cons
- Hire: Justifies their choice based on the specific requirements of this system
- Strong hire: Identifies second-order consequences and optimizes for the constraints that matter most
Example of good trade-off analysis:
"For the message store, I'm choosing between SQL and NoSQL.
SQL gives us ACID transactions and strong consistency, which matters
for message ordering. But at 200K writes/second, a single relational
database won't scale without significant sharding effort.
A wide-column store like Cassandra gives us excellent write throughput
and natural partitioning by chat_id, but we lose transactional guarantees
across partitions.
Given that our requirements prioritize availability and write throughput
over strict consistency — and messages are naturally partitioned by
conversation — I'll go with Cassandra. We can handle ordering within
a partition using timestamp-based clustering keys."Compare that to: “I’ll use Cassandra because it scales well.” The first answer shows engineering judgment. The second shows pattern matching.
4. Communication
System design interviews are fundamentally a conversation. The interviewer is simulating what it would be like to work with you in a design meeting, a whiteboard session, or an architecture review.
What strong communication looks like:
- You narrate your thinking as you work through the design
- You check in with the interviewer: “Does this make sense so far? Should I go deeper here or move on?”
- You structure your answer clearly: “Let me start with the requirements, then sketch the high-level architecture, and then we’ll dive deep into the hardest parts.”
- You respond productively to hints and pushback
What weak communication looks like:
- Long silences followed by jumps to new topics
- Ignoring interviewer hints or questions
- Talking for 15 minutes without pausing for feedback
- Being unable to explain your own choices when asked
Senior vs Staff level:
- Senior engineers lead the conversation with a clear structure and communicate their decisions effectively.
- Staff engineers guide the interviewer through the design like a collaborative partner, anticipate questions, and use the interviewer’s expertise to improve the design in real time.
5. Pragmatism
Pragmatism is the dimension that separates textbook architects from working engineers. It is about demonstrating awareness of real-world constraints: operational costs, team capabilities, time to market, migration paths, and the messy realities of production systems.
Strong signals:
- “We could build a custom solution here, but using a managed service like DynamoDB would be faster to ship and requires zero operational overhead.”
- “This design assumes we have a dedicated data platform team. If we don’t, I’d simplify this part significantly.”
- “In v1, I’d start with a simpler approach and add this optimization only if we see the bottleneck in production.”
Weak signals:
- Over-engineering a solution for requirements that do not exist yet
- Ignoring operational complexity (“We’ll just shard the database”)
- Designing for Google scale when the problem says “10,000 users”
How Scoring Actually Works
At most top tech companies, interviewers use a structured rubric. The exact format varies, but the pattern is consistent: each dimension gets a score, and the overall recommendation maps to a spectrum from “Strong No Hire” to “Strong Hire.”
The Scoring Process
After the interview, the interviewer typically writes feedback structured like this:
Dimension Scores:
Problem Exploration: 3/5 - Asked about scale and core features,
missed some edge cases
Technical Depth: 4/5 - Strong database design, good understanding
of caching, explained Kafka internals well
Trade-off Analysis: 3/5 - Compared SQL vs NoSQL well, but didn't
explore caching trade-offs deeply
Communication: 4/5 - Clear structure, good collaboration,
checked in regularly
Pragmatism: 3/5 - Reasonable approach but over-engineered
the notification system
Overall: Lean Hire / Hire
Justification: Strong technical foundation with good communication.
Would benefit from more emphasis on scoping and
pragmatic simplification. Meets the bar for senior.Important Scoring Realities
You do not need 5s across the board. A “Hire” rating typically means scoring 3+ in every dimension and 4+ in at least two. A single 2 can be survivable if the rest are strong, but a single 1 in any dimension is almost always a “No Hire.”
Interviewers calibrate against the target level. A “3” for a senior engineer is a “2” for a staff engineer. The same answer gets scored differently based on the level you are interviewing for.
The rubric exists to reduce bias, not to be a calculator. Interviewers still make holistic judgments. A candidate who demonstrates exceptional depth in a critical area may get a “Hire” even with a weaker score in another dimension.
“Knowing the Answer” vs “Demonstrating the Thinking”
This is the most important mental shift you need to make. Consider two candidates answering “Design a URL shortener”:
Candidate A (Knows the Answer):
"We'll generate a 7-character base62 hash for each URL. Store it in a
key-value store. Use a cache for popular URLs. Put a CDN in front for
redirect latency. Use a counter-based approach for generating unique IDs."Candidate B (Demonstrates the Thinking):
"First, let me think about what uniqueness guarantee we need. If two
users submit the same long URL, should they get the same short URL or
different ones? [Asks interviewer]
OK, different URLs. So we need a unique ID generation strategy. We
have a few options:
1. Random hash: Simple, but we need collision detection. At our scale
of 100M URLs, with a 7-char base62 space (3.5 trillion), collision
probability is negligible, but we should still handle it.
2. Counter-based: Guaranteed unique, but requires coordination if we
have multiple servers. We could use a distributed ID generator like
Twitter's Snowflake.
3. Hash of the URL + timestamp: Deterministic, no coordination needed,
but we need to handle the rare hash collision.
Given that we have multiple servers and want simplicity, I'll go with
option 1 — random generation with collision checking. The math works
in our favor, and the retry cost on collision is cheap. If we later
need strictly sequential IDs for analytics, we can add a Snowflake-style
counter as a second phase.
Let me sketch the write path..."Candidate A might have the “correct” architecture. But Candidate B demonstrates the engineering judgment that interviewers are looking for. They explore the problem space, consider alternatives, make a justified decision, and leave the door open for iteration.
Common Signals That Impress Interviewers
Having interviewed hundreds of candidates and debriefed with other interviewers, here are the signals that consistently stand out:
Positive signals:
- Structured approach: Starting with requirements, then moving through design systematically
- Thinking out loud: Narrating your reasoning as you work, not just stating conclusions
- Self-correction: “Actually, wait — if our read-to-write ratio is 100:1, caching matters a lot more than I initially thought. Let me reconsider.”
- Proactive depth: Diving deep into the hardest part of the problem without being asked
- Awareness of unknowns: “I’m not sure about the exact throughput of a single Cassandra node, but I know it’s in the range of 10K-50K writes/second. Let me use 20K as a conservative estimate.”
Negative signals:
- Jumping to solutions: Drawing boxes before understanding requirements
- Name-dropping without understanding: “We’ll use Kafka” but cannot explain why or how consumer groups work
- Ignoring the interviewer: Missing hints, not responding to questions, or steamrolling the conversation
- One-size-fits-all answers: Applying the same architecture to every problem regardless of constraints
- Inability to go deep: Staying at the box-and-arrow level without being able to explain any component in detail
What To Do Next
Now that you understand what interviewers evaluate, the next step is to learn the framework for structuring your answer. Having a clear methodology ensures you hit all five dimensions consistently, regardless of the specific problem.
In the next lesson, we will cover the 4-phase framework that gives you a repeatable structure for any system design interview question.
Key takeaways:
- You are evaluated on 5 dimensions: Problem Exploration, Technical Depth, Trade-off Analysis, Communication, and Pragmatism
- The difference between hire and no-hire is almost never about knowing the “right” answer
- Trade-off analysis is the most common differentiator between candidates at the boundary
- Your communication style matters as much as your technical knowledge — interviewers are simulating a design review, not a trivia quiz
- Pragmatism separates working engineers from textbook architects