What System Design Interviewers Actually Look For (From 100+ Interviews)

I've conducted over 100 system design interviews at top tech companies. I've seen candidates with 2 years of experience outperform those with 10. I've seen brilliant engineers fail because they couldn't communicate. I've seen average engineers pass because they asked the right questions.

The gap between passes and fails isn't intelligence or experience. It's understanding what interviewers actually evaluate, and practicing the behaviors that demonstrate it.

This guide gives you the insider view. Exactly what I'm looking for in the first 5 minutes. The red flags that tank candidates. And the subtle signals that make me write "Strong Hire."

---

The Evaluation Framework

Before we dive in, understand how most companies score system design interviews. The specifics vary, but the categories are consistent:

The Four Pillars

The Rating Scale

Most companies use a 4-point scale:

The critical insight: You don't need to be perfect. You need to demonstrate competence across all pillars without any major red flags.

---

Pillar 1: Problem Exploration

What I'm Looking For

In the first 5 minutes, I'm asking myself:

"Does this candidate think before coding? Do they seek to understand, or do they assume they already know?"

Strong signals:

• Asks clarifying questions about scope and scale
• Identifies ambiguity and seeks to resolve it
• Establishes success criteria before designing
• Prioritizes features (MVP vs. nice-to-have)

Weak signals:

• Immediately starts drawing boxes
• Makes assumptions without stating them
• Doesn't ask about scale
• Tries to design everything at once

What Great Looks Like

Question: "Design a notification system"

Weak candidate:

"OK, so we'll need a service that sends notifications. We can use Firebase Cloud Messaging for push, SendGrid for email..."

Strong candidate:

"Before I start designing, I want to understand the scope. A few questions:

First, what channels are we supporting, push, email, SMS, in-app? All of them, or a subset?

Second, what's the scale? How many notifications per day, and what's our latency requirement, do some need to be real-time?

Third, is this a multi-tenant platform serving other teams, or a single system for one product? That significantly affects the architecture.

And finally, what's the reliability requirement? Can we lose some notifications, or is exactly-once delivery critical?"

The strong candidate demonstrates:

• Structured thinking (organized questions by category)
• Experience (knows the right questions to ask)
• Prioritization (focuses on decisions that affect architecture)

Red Flags in This Phase

1. Zero clarifying questions , Immediately assumes they understand
2. Superficial questions , "How many users?" without follow-up on what that means
3. Analysis paralysis , Asks 20 questions before drawing anything
4. Ignoring constraints , Doesn't ask about latency, scale, or reliability

How to Practice

For every practice problem, force yourself to spend 3-5 minutes asking questions before designing. Write down:

• What assumptions are you making?
• What would change your design if the answer were different?
• What's the MVP scope?

---

Pillar 2: Technical Design

What I'm Looking For

Once you start designing, I'm evaluating:

"Can this person create a system that would actually work? Do they understand how components fit together?"

Strong signals:

• Clear component decomposition
• Logical data flow (I can trace a request through the system)
• Appropriate technology choices with justification
• Considers failure modes and redundancy

Weak signals:

• Vague "boxes and arrows" with no substance
• Components that don't connect logically
• Technology choices without reasoning
• Single points of failure everywhere

What Great Looks Like

Weak design explanation:

"So we have the client, and it talks to the server, and the server talks to the database. We also have caching somewhere."

Strong design explanation:

"Let me walk through the high-level architecture.

Starting with the request flow: The client hits our load balancer, which distributes traffic across stateless API servers. These servers are horizontally scalable, we can add more as traffic grows.

For data storage, we have two primary stores. First, PostgreSQL for our core data, user accounts, settings, anything requiring ACID guarantees. Second, Redis for caching frequently accessed data. I expect an 80%+ cache hit rate given our access patterns.

For async processing, like sending emails after a user action, we use a message queue. Kafka gives us durability and replay capability. Consumer workers pull from the queue and handle processing.

Let me draw this and show the data flow..."

The strong candidate:

• Structures the explanation (request flow, then storage, then async)
• Justifies choices ("PostgreSQL for ACID guarantees")
• Quantifies ("80%+ cache hit rate")
• Shows awareness of trade-offs ("horizontally scalable")

The Diagram Matters

Your diagram should be:

• Clear , Someone unfamiliar could understand it
• Complete , Shows all major components
• Labeled , Components are named, connections are explained
• Logical , Data flow makes sense

Good diagram:
┌─────────┐     ┌──────────────┐     ┌─────────────┐
│ Client  │────▶│Load Balancer │────▶│ API Server  │
└─────────┘     └──────────────┘     └─────────────┘
                                           │
                      ┌────────────────────┼────────────────┐
                      ▼                    ▼                ▼
               ┌───────────┐        ┌───────────┐    ┌───────────┐
               │   Cache   │        │ Database  │    │   Queue   │
               │  (Redis)  │        │(PostgreSQL)│   │  (Kafka)  │
               └───────────┘        └───────────┘    └───────────┘

Bad diagram:
┌───────┐
│Server │──── DB
└───────┘
    │
  Cache?

Red Flags in This Phase

1. No diagram , Verbal-only explanation
2. Missing components , No caching for high-traffic system, no queue for async work
3. Technology soup , "We'll use Kafka, Redis, MongoDB, PostgreSQL, Cassandra, and DynamoDB"
4. No failure consideration , What happens when the database goes down?

---

Pillar 3: Technical Depth

What I'm Looking For

When I probe on specific components, I'm evaluating:

"Can this person actually implement what they're proposing? Do they understand the details, or just the buzzwords?"

Strong signals:

• Can explain algorithms and data structures used
• Understands trade-offs at the implementation level
• Handles edge cases and failure modes
• Can discuss alternatives they considered

Weak signals:

• "We use caching" but can't explain cache invalidation
• "We shard the database" but can't explain how
• "Eventually consistent" but can't explain what that means for users
• No awareness of edge cases

What Great Looks Like

Interviewer: "Tell me more about how you'd implement rate limiting."

Weak answer:

"We'd use Redis to count requests per user and reject if they exceed the limit."

Strong answer:

"For rate limiting, I'd use the token bucket algorithm. Here's how it works:

Each user has a bucket with a maximum capacity, say 100 tokens. Tokens refill at a constant rate, let's say 10 per second. Each request consumes one token. If the bucket is empty, the request is rejected.

Implementation-wise, I'd store this in Redis. For each user, we track two values: the current token count and the last refill timestamp. On each request:

1. Calculate tokens to add based on time elapsed
2. Update token count (capped at bucket size)
3. If tokens > 0, decrement and allow
4. If tokens == 0, reject with 429 status

To make this atomic, I'd use a Lua script in Redis, this prevents race conditions when multiple requests arrive simultaneously.

One consideration: this is per-server if we use local memory, but per-user globally if we use Redis. For our distributed system, Redis gives us consistent rate limiting across all servers.

An alternative is the sliding window algorithm, which is more accurate but uses more memory since we'd need to track individual request timestamps."

The strong answer demonstrates:

• Algorithm knowledge (token bucket specifics)
• Implementation details (Redis, Lua scripts, atomic operations)
• Edge case awareness (race conditions)
• Trade-off discussion (alternatives considered)

How Deep is Deep Enough?

Different levels have different expectations:

At Senior level, you should be able to whiteboard the algorithm. At Staff level, you should know when NOT to use it.

Red Flags in This Phase

1. Buzzword soup , "We use sharding with consistent hashing for horizontal scalability" but can't explain how consistent hashing works
2. Can't go deeper , Every follow-up question gets "I'd need to look that up"
3. No edge cases , "It just works" without considering failures
4. Defensive responses , Argues when challenged instead of engaging

---

Pillar 4: Communication

What I'm Looking For

Throughout the interview, I'm evaluating:

"Would I enjoy working with this person? Can they explain complex ideas to different audiences? Do they collaborate or monologue?"

Strong signals:

• Structures explanations logically
• Checks in with interviewer ("Does this make sense?")
• Responds to feedback and pivots when needed
• Admits uncertainty honestly

Weak signals:

• 20-minute monologues without pausing
• Ignores interviewer cues
• Defensive when challenged
• Pretends to know things they don't

What Great Communication Looks Like

Interviewer gives a hint: "What about the case where the cache and database get out of sync?"

Weak response:

[Ignores hint, continues with previous point]

Medium response:

"Oh yeah, cache invalidation. We'd use TTL."

Strong response:

"That's a great point, cache invalidation is tricky. Let me think through the scenarios.

The main risk is: user updates their profile, database updates, but cache still has old data. Other users see stale data.

A few strategies:

1. Write-through: Update cache on every database write. Keeps them in sync, but adds write latency.

2. Cache-aside with invalidation: After database write, delete the cache key. Next read fetches fresh data. Simpler, but there's a brief inconsistency window.

3. TTL-based: Accept eventual consistency with short TTL. Simplest, but not suitable for all use cases.

For our system, I'd go with cache-aside with explicit invalidation. The 100ms inconsistency window is acceptable, and it's simpler than write-through.

Does that address your concern, or were you thinking of a different scenario?"

The strong response:

• Acknowledges the feedback ("That's a great point")
• Structures the answer (three options, clear recommendation)
• Re-engages ("Does that address your concern?")

The Check-In Habit

The simplest communication improvement: check in every 5-7 minutes.

"I've covered the high-level design. Before I go into the database schema, is there any component you'd like me to dive deeper on?"

"I've been talking for a while, does this make sense so far? Any questions?"

"I'm planning to discuss caching next. Is that the right direction, or would you prefer I go somewhere else?"

This shows:

• You care about the interviewer's needs
• You're collaborative, not just performing
• You can prioritize based on feedback

Red Flags in This Phase

1. Monologuing , 15+ minutes without pause or check-in
2. Ignoring hints , Interviewer tries to guide, candidate doesn't follow
3. Defensiveness , "That's not how I'd do it" when challenged
4. Dishonesty , Clearly making things up instead of admitting uncertainty

---

The Subtle Signals That Separate Hires

Beyond the four pillars, here are the subtle behaviors that push candidates from "Hire" to "Strong Hire":

1. Proactive Trade-off Discussion

Don't wait to be asked about trade-offs. State them as you design.

Average: "We'll use Cassandra for the database."

Strong: "We'll use Cassandra for the database. The trade-off is: we get excellent write throughput and horizontal scalability, but we give up strong consistency and flexible querying. Given our write-heavy workload and simple access patterns, that trade-off works."

2. Quantified Reasoning

Numbers make your arguments concrete.

Average: "We need caching because the database can't handle the load."

Strong: "At 100K QPS, we need caching. PostgreSQL with read replicas can handle maybe 50K QPS for simple lookups. Redis can easily handle 500K+ QPS. With an 80% cache hit rate, we reduce database load to 20K QPS, well within capacity."

3. Self-Correction

Strong candidates catch their own mistakes.

What it looks like:

"Actually, wait, I said we'd use a single Kafka partition, but that creates ordering guarantees we might not want. Let me revise: we'd partition by user_id, so each user's events are ordered, but we can parallelize across users."

This shows intellectual honesty and deep understanding, both strong signals.

4. Productive Response to Challenge

When I push back, I'm testing how you handle disagreement.

Weak: "I disagree. Kafka is the right choice."

Strong: "Interesting, what's your concern with Kafka here? [listens] Ah, I see. You're right that operational complexity is higher. If the team isn't familiar with Kafka, RabbitMQ or even SQS could work for our scale. The key capability we need is durable async messaging. I'd go with whatever the team can operate confidently."

5. Operational Awareness

Who pages when this breaks?

Average candidates design systems. Strong candidates design systems that teams can operate.

"For monitoring, I'd track three key metrics: p99 latency, error rate, and queue depth. We'd set alerts for latency > 500ms, error rate > 1%, or queue depth growing faster than consumption. On-call would be the platform team, with runbooks for common scenarios."

---

The Common Failure Modes

After 100+ interviews, these are the most common reasons candidates fail:

1. The Premature Optimizer

What they do: Jump straight into micro-optimizations without establishing basics.

What it looks like:

"For the database, I'd use a custom B-tree implementation with bloom filters and optimistic locking..." before they've even defined what data they're storing.

Why it fails: Shows they can't prioritize. In real systems, getting the fundamentals right matters more than micro-optimizations.

2. The Buzzword Machine

What they do: Name-drop technologies without understanding them.

What it looks like:

"We'll use Kubernetes for orchestration, Istio for service mesh, Cassandra for storage, Kafka for messaging, and Redis for caching."

"Why Cassandra over PostgreSQL?"

"It's more scalable."

Why it fails: Technology choices should be justified. "More scalable" isn't a reason, what specifically about your workload requires Cassandra's scalability?

3. The Non-Listener

What they do: Ignore interviewer hints and continue with their planned answer.

What it looks like:

Interviewer: "What about the case where..." (tries to guide) Candidate: "So anyway, as I was saying..." (ignores)

Why it fails: System design is collaborative. Ignoring guidance suggests you'd be difficult to work with.

4. The Perfectionist

What they do: Try to design a perfect system that handles every edge case.

What it looks like:

"And we'd also need to handle daylight saving time, leap seconds, and the case where the user is in two time zones simultaneously..."

Why it fails: In 45 minutes, you can't design a perfect system. Focus on the core design and most important edge cases.

5. The Under-Communicator

What they do: Draw in silence, give terse answers, don't explain reasoning.

What it looks like:

[Draws boxes and arrows for 5 minutes without speaking] "So this is the design." [Silence]

Why it fails: I can't evaluate thinking I can't see. The explanation matters as much as the diagram.

---

How to Get Better

1. Practice Out Loud

The biggest gap between preparation and performance is verbalization. Practice explaining designs out loud, not just thinking through them.

Exercise: Record yourself explaining a system design. Listen back. Would you hire yourself?

2. Time Your Practice

Real interviews are 45 minutes. If you practice without time pressure, you'll misjudge pacing.

Framework:

• 5 min: Requirements
• 5 min: High-level design
• 25 min: Deep dive on 2-3 components
• 10 min: Wrap-up, trade-offs, questions

3. Practice Trade-offs, Not Solutions

Most candidates prepare by memorizing solutions. Strong candidates prepare by understanding trade-offs.

For every system, know:

• Why SQL vs. NoSQL for this use case?
• Why async vs. sync processing?
• Why cache here but not there?
• What changes if scale 10x?

4. Get Real Feedback

Mock interviews with feedback are worth 10x solo practice. Find someone who can tell you not just if your design works, but how you're perceived.

Ask them:

• Did I communicate clearly?
• Where did I seem uncertain?
• What would you have done differently?
• Would you hire me based on that interview?

---

Final Thought

The best system design candidates aren't the ones with the most experience or the smartest solutions. They're the ones who:

1. Understand the problem before solving it
2. Communicate their thinking clearly
3. Make reasonable trade-offs and justify them
4. Collaborate with the interviewer

You can develop all of these skills with practice. Now you know exactly what interviewers look for.

Go practice.

---