The Diagram That Got an L6 Offer at Meta
A staff engineer at Meta once said: 'I can tell a candidate's seniority level within 60 seconds of them starting to draw.' Senior candidates draw client on the left, data on the right, clean layers in between, and narrate every box. Junior candidates draw a tangled web of boxes with crossing arrows and no labels. Your whiteboard diagram is not decoration - it is the primary artifact of your interview. A clean diagram signals clean thinking.
The Standard Layout
System Design Diagram Template:
LEFT CENTER RIGHT
-------- ---------------- --------
[Client] ------> [API Gateway] --------> [Database]
[Mobile] - Rate limiting PostgreSQL
[Web] - Auth (primary)
- Routing |
| [Read Replica]
| (read-heavy)
[Service A] |
[Service B] ----------- [Redis Cache]
[Service C] TTL: 5 min
|
[Message Queue] -------> [Worker]
Kafka / SQS Async processing
Rules:
1. Flow: Left to Right (user -> system -> data)
2. Sync calls: solid arrows
3. Async calls: dashed arrows
4. Label EVERY arrow ('read', 'write', 'async event')
5. Name technologies ('PostgreSQL' not just 'DB')
6. Add numbers ('5K writes/sec', 'TTL: 5 min')Narrate As You Draw
The biggest diagram mistake is drawing in silence. When you draw a box and say nothing for 30 seconds, the interviewer is guessing what you are thinking. Instead, narrate every action: 'I am adding a cache layer here because our read-to-write ratio is 100:1, so most reads should never hit the database.' This turns your diagram from a picture into a design narrative. The interviewer hears your reasoning in real time, can ask questions at the right moment, and does not have to wait for a 'finished' diagram to understand your approach. Think of it as pair-designing - you are leading the conversation while the interviewer follows along.
Common Diagram Mistakes
Diagram Anti-Patterns:
Mistake Why It's Bad Fix
----------------- ----------------------- ----------------
Unlabeled boxes Interviewer guesses what Name every box
'Service' means with technology
Crossing arrows Shows tangled thinking Rearrange layout
Hard to follow flow to avoid crossings
No data direction Which way does data flow? Add arrow labels:
No one knows read/write/event
Draw then explain Awkward silence while Narrate as you draw
drawing for 3 minutes 'Adding a cache here
because...'
Too detailed Class diagrams, schemas Stay at component
Code-level detail level, not code
No numbers No sense of scale Add key metrics:
Anywhere QPS, storage, TTLZooming In and Out
Start with the complete high-level diagram even if it is rough. Draw all the major boxes (client, gateway, services, databases, caches, queues) with labeled arrows between them. Then zoom into specific subsystems when the interviewer asks for depth or when you want to show critical details. A common mistake is drilling into one component's internals before showing the full picture - the interviewer cannot evaluate your design if they cannot see where a component fits in the overall system. Keep a mental note of which boxes you drew simply and return to add detail when it is their turn for a deep dive.
Interview Tip
Draw as you speak, speak as you draw - never draw in silence. Use the standard layout: clients left, services center, data right. Label every box with its technology name ('Posts DB - PostgreSQL' not 'DB'), label every arrow with data direction, and annotate key numbers. Start with the complete high-level diagram (even if rough) before zooming into any subsystem. Take 15 seconds to mentally plan your layout before the first stroke.
Key Takeaway
Your whiteboard diagram is the primary artifact of a system design interview. Use the left-to-right layout (client to data), label every box and arrow, narrate as you draw, and always show the complete picture before zooming into subsystems. A clean diagram signals clean thinking.
