01. What Interviewers Actually Evaluate — Structure beats sparkle¶

~12 min read. The best candidates do not sound magical. They sound organized.

Built on the ELI5 in 00-eli5.md. The restaurant — the whole system working together — matters more than any one clever appliance.

1) The real signal is not perfection¶

Most candidates think the interview asks one question. "Can you design the right system?" Look. That is not the real question. The real question is this. Can you take a messy problem. Can you turn it into clear house rules. Can you move one order ticket at a time. Can you explain tradeoffs without getting defensive. That is the signal. A strong interviewer knows the problem has many valid designs. They are not expecting the exact internal diagram from one company. They are checking whether your thinking is stable under pressure. See. System design interviews are closer to architecture reviews than exams. Nobody gets full marks for saying random component names quickly. You get credit for sequence. You get credit for judgment. You get credit for saying what you know. You also get credit for saying what you are assuming. Here is the mental model.

candidate answer quality
        │
        ├── requirements clarity
        │        "What are we optimizing for?"
        │
        ├── architecture shape
        │        "What are the main parts?"
        │
        ├── tradeoff judgment
        │        "Why this, not that?"
        │
        └── communication
                 "Can others follow the plan?"

If these four are strong, the design feels senior. If even two are weak, the design feels shaky. Simple, no? A candidate can mention Kafka, Redis, and sharding. Still fail. Another candidate can start with a single database. Still pass. Why? Because the second person is driving the conversation. They are building the restaurant in layers. They are not dumping furniture into the room.

2) The four dimensions interviewers score silently¶

Different companies use different rubrics. The buckets are still almost the same.

A. Requirements gathering¶

First, do you ask good questions. Not fifty questions. Just the ones that change the design. Who are the users? What is the main user action? What scale matters? What latency matters? What consistency matters? What is explicitly out of scope? This is where you set the house rules. Without house rules, every box you draw is suspicious. Now what is the problem? Most weak candidates fear looking slow. So they skip this part. Then they solve the wrong problem beautifully.

B. Architecture¶

Second, can you produce a clean first draft. Not the final draft. The first draft. The best answers start simple. Client. API. App logic. Storage. Then they refine bottlenecks. They do not begin with ten microservices. They give the interviewer a stable map. That map should explain the order ticket journey. Where does the request enter? Where is it validated? Where is it stored? Where does it fan out? Where can it fail? That is architecture. Not decoration.

C. Tradeoffs¶

Third, can you compare options honestly. SQL or NoSQL. Push or pull. Precompute or compute on read. Strong candidates do three things here. They name the benefit. They name the cost. They tie both back to requirements. So what to do? Say things like this. "Reads dominate writes, so I will pay extra write cost for faster reads." Or this. "I prefer one primary database first because the consistency rule is strict." Tradeoff talk is where seniority shows. Anyone can add components. Few people can justify restraint.

D. Communication¶

Fourth, can you keep the room with you. This dimension is underrated. Interviewers are imagining future meetings with you. Can you structure a review. Can you summarize decisions. Can you recover when interrupted. Can you say, "I will park that and return in two minutes". That matters. A design interview is partly a collaboration test. If your explanation is hard to follow, your design feels weaker. Even if the boxes are fine. Good communication sounds like this. "Let me start with scope." "Now I will draw the happy path." "Next I will stress the write hotspot." "Finally I will discuss tradeoffs and failure cases." See the difference? The interviewer can relax. They know where the conversation is going.

3) A worked scoring example¶

Let us score two candidates on a common prompt. Prompt: design a URL shortener. Assume the interviewer silently uses 0 to 5 per dimension. Total possible score = 4 dimensions × 5 = 20.

Candidate A¶

Asked only one question. "How many users?" Then immediately drew API, cache, DB, queue, analytics pipeline. When asked why a queue is needed, they said scale. When asked read-heavy or write-heavy, they guessed fifty-fifty. When asked latency target, they said as low as possible. Let us score it carefully. Requirements gathering = 1/5. Reason: one question, no scope, no SLA, no consistency rule. Architecture = 3/5. Reason: boxes are recognizable, flow is incomplete. Tradeoffs = 1/5. Reason: components named, reasons weak. Communication = 2/5. Reason: fast talking, little signposting. Total = 1 + 3 + 1 + 2 = 7/20.

Candidate B¶

Asked six questions in ninety seconds. Functional scope: shorten URL, redirect, basic click count. Out of scope: custom aliases and abuse detection. Traffic: 20 million new URLs per month. Read/write ratio: 100:1. Latency SLA for redirect: under 50 ms at p95. Availability target: 99.9%. Then they drew one app tier and one database. Then they said cache comes later because reads dominate. Then they explained why key generation must avoid collisions. Then they parked analytics as async. Now we score again. Requirements gathering = 5/5. Architecture = 4/5. Tradeoffs = 4/5. Communication = 5/5. Total = 5 + 4 + 4 + 5 = 18/20. Notice something important. Candidate B did not draw a more complex restaurant. They drew a more justified one. That is exactly what interviewers reward.

4) What strong answers sound like in real time¶

A good answer usually has this rhythm.

┌──────────────┐
│ 1. Scope     │  What problem are we solving?
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ 2. Baseline  │  Simplest design that works.
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ 3. Stress    │  Where does it break first?
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ 4. Improve   │  Add only needed complexity.
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ 5. Summarize │  Tradeoffs and open questions.
└──────────────┘

Look. This rhythm is interview gold. It shows control. It also creates checkpoints. If the interviewer interrupts, you know where to resume. Now what mistakes break this rhythm? Mistake one. Over-answering the first minute. You dump the final system immediately. The interviewer cannot see your thinking. Mistake two. Treating every prompt like "design Twitter". You force-feed queues, shards, and global caches. Even when the scope does not need them. Mistake three. Never stating assumptions aloud. Then the interviewer must guess your model. That is risky. Mistake four. Arguing for a tool instead of a property. Say "I need lower read latency" first. Say "so I add cache" second. Not the reverse. Mistake five. Forgetting the human in the room. The interviewer is not a syntax checker. They are evaluating whether they can work with you. So what to do when you get stuck? Reset with structure. Say, "Let me step back and restate the core flow." Then walk one order ticket from user to storage. Then name the hottest bottleneck. Then offer two options. That recovery itself scores points.

5) A practical rubric you can self-check¶

Before mock interviews, grade yourself on four questions. Did I set clear requirements in under two minutes? Did my first diagram stay simple enough to explain quickly? Did every major component have a reason tied to a requirement? Did I speak in a sequence the listener could track? If one answer is no, fix that first. Do not chase fancy breadth. Fix the missing dimension. Think of it like this. A weak answer is usually unbalanced. Maybe strong architecture, weak communication. Maybe strong speaking, weak tradeoffs. Your goal is not genius in one corner. Your goal is competence across all four corners. That is what feels hireable.

Where this lives in the wild¶

Swiggy order platform — staff backend engineer: clarifies delivery-state requirements first, then chooses idempotent writes and async notifications.
WhatsApp messaging infra — senior distributed systems engineer: explains delivery guarantees, fanout tradeoffs, and failure recovery before naming brokers.
YouTube home feed — staff recommendation engineer: frames freshness, ranking latency, and fallback behavior before talking about candidate generation.
Razorpay payments stack — principal engineer: anchors the whole review on consistency, reconciliation, and auditability, not on flashy services.
Uber driver dispatch — senior platform engineer: communicates the hot path, surge constraints, and regional failure handling with crisp sequencing.

Pause and recall¶

What are the four evaluation dimensions interviewers usually score?
Why can a simpler design beat a more complex design in interview scoring?
What is the difference between naming a tool and naming a tradeoff?
If you get stuck mid-interview, what sequence helps you recover fast?

Interview Q&A¶

Q: Why spend time on requirements, not jump straight into architecture? A: Requirements define the house rules the system must satisfy, so they tell you what to optimize before you pick components. They also expose scope and constraints early; without them, you can build a polished design that solves the wrong problem.

Common wrong answer to avoid: "Because interviewers like clarifying questions." — The goal is not to perform curiosity; it is to remove ambiguity so later design choices are grounded.

Q: Why start with one simple diagram, not the final scaled-out version? A: A simple baseline lets the interviewer watch your reasoning instead of guessing whether you memorized a template. It also gives you a clean starting point for showing where bottlenecks appear and why each added component is justified.

Common wrong answer to avoid: "Because microservices are too advanced for interviews." — The issue is not sophistication level; it is that complexity should follow evidence, not appear before the baseline exists.

Q: Why is communication scored separately from architecture quality? A: Senior engineers succeed by making tradeoffs legible, aligning people, and explaining why a design is safe enough to ship. If your system is hard to follow, teammates cannot review it well, operators cannot run it confidently, and risks stay hidden.

Common wrong answer to avoid: "If the design is correct, communication should not matter." — A design that cannot be explained clearly is hard to validate, challenge, or operate in the real world.

Q: Why compare options using properties, not product names? A: Product names vary by company, but the underlying properties you need to reason about do not. Latency, throughput, durability, and consistency let you compare choices in a portable way and map them to any stack.

Common wrong answer to avoid: "Naming popular tools proves practical experience." — Tool recall is not the same as design judgment; interviewers care more about why a choice fits the requirements.¶

Apply now (5 min)¶

Take one prompt: design a file upload service. Do not solve it fully. Instead, do only this. Write five clarifying questions. Then list the four rubric dimensions. Under each dimension, write one sentence you want the interviewer to hear. Then sketch from memory: - one simple baseline diagram - one likely bottleneck - two tradeoffs you would discuss next

If you can do that in five minutes, you are interview-ready in structure.¶

Bridge. You know what they evaluate. But where do you start? With requirements. The house rules come first. → 02-requirements-before-boxes.md