1. How to Approach a Design Question
1
The picture to keep in your head2
1.1 What is a system design interview, and what isn't it?3
1.2 What is the interviewer actually scoring?4
1.3 What's the step-by-step framework?5
1.4 How do you manage a 45-minute round?6
1.5 What questions should you ask first?7
1.6 What's the difference between functional and non-functional requirements?8
1.7 What's an API, and why define it before drawing boxes?9
1.8 How do you sketch the data model?10
1.9 What does a good high-level design look like?11
1.10 How do you choose what to deep dive into?12
1.11 How do you talk about trade-offs?13
1.12 What if you get stuck or don't know something?14
1.13 What are the most common mistakes?15
1.14 What does the bar look like: fresher vs SDE-2?16
Memory card and where the analogy breaks17
Practice: five levels18
Interview questions19
Solutions20
Sources21
Code lab1. How to Approach a Design Question
1.12 What if you get stuck or don't know something?
3 min read+10 XP
Under pressure
At the architect's desk: A client asks about a special foundation the architect has never used. A good architect doesn't bluff. She says what she does know about soil and load, how she'd reason about it, and that she'd confirm with a structural engineer.
In the interview: Getting stuck is normal. What's scored is what you do next:
- Think out loud. "I'm deciding between X and Y. X is simpler but... Y handles..." Half-formed reasoning out loud scores. Silence scores nothing, because the interviewer can't see what's in your head.
- Go back to the requirements. Most "stuck" moments are solved by asking "what did we say matters most here?"
- If you don't know a technology, say so and reason from basics. "I haven't used Cassandra, but if it's a wide-column store, then I'd expect..." Honest reasoning beats a confident wrong answer.
- Use the interviewer. "Would it be fair to assume ___?" is a legitimate question, not a weakness.
Memory code: "Silence scores zero." Never go quiet. Reason out loud, even when unsure.