The Ambiguity Problem
Coding problems have test cases. System design questions have none. You're asked to "design Twitter" or "build a distributed cache" with almost no constraints, and the interviewer watches how you handle the void.
This ambiguity is deliberate — it's testing your engineering judgment, not just your knowledge. But for anxious engineers, open-ended questions are particularly threatening because there's no clear benchmark for success.
The Framework That Removes Paralysis
Stop trying to jump to the solution. Treat the first 5 minutes as a requirements-gathering phase:
1. Clarify scale
- "How many users are we designing for? 100K DAU or 100M?"
- "What's the expected read/write ratio?"
- "Are we optimizing for consistency or availability?"
2. Define the core use cases
- Pick 2-3 core user flows to design around
- Explicitly deprioritize edge cases you won't address
3. Establish constraints
- "I'll assume we're building this for global scale"
- "I'll use a microservices architecture since this is greenfield"
Spending 5 minutes here accomplishes two things: it narrows the problem space (reducing anxiety), and it shows the interviewer you think like a senior engineer.
The High-Level Architecture First
Always sketch the 30,000-foot view before diving into components. A simple diagram with:
- Client → Load Balancer → API Gateway
- Core services
- Databases
- Caches
- Async queues
This gives you a map to navigate and shows the interviewer you can think at multiple levels of abstraction.
Depth Over Breadth
Many engineers try to cover every component at the same level. This is a trap — you'll run out of time and never go deep enough to demonstrate expertise.
Instead, ask the interviewer: "Would you like me to go deeper on the database design, the caching strategy, or the notification system?" Let them guide you toward what they care about. This demonstrates senior judgment — knowing that real engineering is about prioritization.
Talk Through Trade-offs
The single biggest differentiator between average and excellent system design answers is discussing trade-offs explicitly:
"I could use a relational database here for strong consistency, but given our read-heavy pattern, I'd choose a document store and handle consistency at the application layer. The trade-off is..."
"We could cache aggressively here, but that increases the risk of serving stale data. Given that this is a social feed, I think 30-second eventual consistency is acceptable, so..."
Interviewers aren't looking for the perfect answer — they're looking for evidence that you understand the problem space deeply enough to make principled decisions.
Practice by Explaining, Not Memorizing
System design can't be memorized. Instead, practice by explaining existing systems to a peer: "How would you design Slack's real-time messaging?" Then have them challenge your assumptions.
This builds the mental flexibility to adapt your knowledge to novel constraints — which is exactly what the interview demands.