Reading the Prompt: What's Actually Being Asked
Part 2 →
Capacity Estimation That Holds Up
Most system design interviews are lost in the first two minutes — not because the candidate lacks knowledge, but because they start solving the wrong problem. The prompt "Design Twitter" contains roughly a dozen different problems depending on what the interviewer actually cares about that day. Getting this right is the real skill.
The Prompt Is a Compression
Interviewers hand you a compressed statement. "Design a URL shortener." "Design a ride-sharing app." "Design a notification system." Each of these compresses years of product decisions, technical constraints, and team-specific pain points into six words. Your first job is decompression — not solution.
The candidates who impress say things like: "Before I start, I want to make sure I understand the scope. Are we focused on write-heavy ingestion, or is read latency the main concern here?" That sentence alone signals seniority.
Dimensions to Always Clarify
Every design prompt hides at least four dimensions you must surface:
Scale: How many users? Concurrent or burst? Reads vs. writes? The answer changes everything from your data model to your replication strategy.
Consistency requirements: Is it okay to show stale data? Can we drop an event? Financial systems need ACID. Social feeds can tolerate eventual consistency.
Latency targets: p50, p95, or p99? A 200ms p50 is trivially achievable. A 50ms p99 under load is a different architecture entirely.
Operational scope: Are we designing just the happy path, or do we need to address failover, DR, and observability? Interviewers at staff+ levels often care more about your failure handling than your happy path.
Reading Interviewer Signals
Interviewers telegraph what they care about, but subtly. Pay attention to:
What they add unprompted: If they say "oh and assume millions of uploads per day," they want you to talk about storage and ingestion pipelines. If they say "users are globally distributed," they're testing your geo-awareness — CDN, edge caching, regional failover.
What they skip: If they wave away your questions about auth, they don't want to spend 20 minutes on JWTs. Move on.
Follow-up phrasing: "Interesting — how would that behave under load?" means go deeper on scaling. "What happens if that service goes down?" means go deeper on resilience. The follow-up is a steering wheel, not a gotcha.
Silence after a design choice: They may be waiting for you to defend it. Don't backpedal immediately. Say why you made the choice, then offer the alternative and its tradeoffs.
The Restatement Step
After your clarifying questions, always restate the problem in your own words before drawing anything. This does three things:
- Confirms you understood correctly — interviewers will correct you here rather than 40 minutes in.
- Forces you to commit to a scope, which protects you from scope creep during the interview.
- Demonstrates structured thinking, which is itself an evaluation criterion.
A restatement sounds like: "So we're building a notification delivery system that needs to handle roughly 50 million pushes per day, target sub-500ms delivery for high-priority alerts, and we're not covering the rules engine or templating layer today — just the delivery path. Does that sound right?"
What "Simple" Prompts Actually Mean
Some prompts are deceptively simple. "Design a key-value store" could mean:
- An in-memory store for a single service (Redis-style, single node)
- A distributed store with partitioning and replication (Dynamo-style)
- A durable, linearizable store (etcd/Zookeeper-style)
Each is a completely different system. Jumping in without disambiguation means you might spend 45 minutes designing something the interviewer had zero interest in.
The tell: if the interviewer is senior, they almost always want the distributed version. If they mention "operational simplicity" early, maybe not.
Common Mistakes in the First Five Minutes
Starting to draw immediately: Boxes without context. You look reactive, not architectural.
Asking too many questions: Three or four targeted questions is ideal. Twelve questions makes you look like you need to be hand-held.
Agreeing to everything: If the interviewer suggests an approach that you think is wrong, say so politely. "That could work — I'd want to think through the consistency implications. Can I walk through both approaches?" Interviewers want to see you push back with reason.
Skipping the restatement: The restatement is not overhead. It is the foundation.
A Framework for the First Five Minutes
You have roughly 45 minutes of design time. The five you spend here pay back tenfold because every subsequent decision is anchored to a shared understanding.
Key Takeaways
- The prompt is a compression — your first job is decompression, not solution.
- Always clarify: scale, consistency model, latency targets, and failure scope before drawing anything.
- Restate the problem in your own words before you begin — it's a safety check and a signal.
- Read interviewer signals: what they add, what they skip, and how they phrase follow-ups all steer you.
- Three or four sharp clarifying questions beats twelve vague ones — specificity demonstrates expertise.
- Pushing back on a flawed suggestion (with reasoning) is a positive signal, not a social risk.
Part 2 →
Capacity Estimation That Holds Up