Design Review vs Interrogation
There are two types of system design interviews. In the first, the interviewer asks questions and the candidate answers them one by one - like an interrogation. In the second, the candidate presents a design, narrates their thinking, invites feedback, and adjusts - like a design review with a peer. The second type always scores higher because it demonstrates how you actually work: leading technical discussions, making decisions under uncertainty, and collaborating with other engineers. The difference is not talent - it is posture.
The Driver's Playbook
How to Drive a System Design Interview:
Phase Driver (do this) Driven (avoid this)
----------- --------------------------- ----------------------
Opening 'Let me clarify a few Wait for interviewer
requirements, then I'll to structure the
present my approach.' conversation for you.
Design 'I'll start with high-level Draw in silence, then
architecture, then we can say 'so... what do you
dive into whatever you find think?'
most interesting.'
Decisions 'For sessions, I'm choosing 'It depends... we could
Redis because we need use Redis or Memcached
sub-ms reads. If durability or a database...'
mattered more, I'd use DB.'
Transitions 'I've covered the data flow. Wait for 'what's next?'
Next I want to look at the from the interviewer.
cache invalidation strategy.'
Challenges 'Good point - at that scale Get defensive: 'But
my approach breaks. Let me that won't happen
think through alternatives.' because...'
Time Mgmt 'We have 15 min left - let Realize at minute 42
me make sure we cover the there was no time for
notification subsystem.' deep dives.Handling Pushback Gracefully
When an interviewer challenges your design, they are not attacking you - they are testing how you handle technical disagreement. The best response pattern: acknowledge their point, evaluate it honestly, and either adapt your design or explain why your original choice still holds. Never get defensive. The candidate who says 'That is a great point - let me reconsider' projects more confidence than the one who doubles down on a flawed approach.
Interview Tip
Driving the interview means: announce your plan upfront ('I'll cover requirements, then architecture, then deep dives'), make explicit choices with reasoning ('I'm choosing X because Y, accepting Z'), narrate transitions ('Moving to the data model now'), and manage time openly ('15 minutes left, let me cover one more subsystem'). The interviewer wants to follow your thinking - give them a clear path to follow. Practice opening with: 'Let me ask a few requirements questions, then I'll walk you through my proposed architecture.'
