Agile in Theory, Waterfall in Interviews
Why our system design interviews don’t reflect how real systems are built and what we should test instead
We say we value iteration.
We say feedback is everything.
We say agile is how good software gets built.
Then we walk into an interview…
And ask someone to design Twitter at scale. All in one go.
No iteration. No product context. No user feedback.
Just: “Design it. Now. All of it.”
It’s a weird contradiction.
System design interviews are supposed to test how well someone can architect real-world systems.
But real systems aren’t designed in a 45-minute whiteboard session.
They evolve.
They respond to changing needs, product feedback, scale surprises, and team constraints.
So what are we really testing?
Often, we’re testing:
Who’s memorized the “correct” boxes and arrows
Who can perform confidently under artificial pressure
Who’s seen the “Netflix architecture” diagram enough times to fake it
We say we value iteration and ambiguity.
But we test for finality and certainty.
We say we want thoughtful builders.
But we optimize for performers.
So what should we test instead?
Can they ask clarifying questions?
That reveal product intent and ambiguityCan they break the problem down?
In a way that makes trade-offs visibleCan they communicate their thinking?
Not just the end state, but how they got thereDo they show awareness of context?
Scale, users, constraints, and when assumptions break
A good engineer doesn’t start with the final diagram.
They start with understanding.
Then they build with the team one decision at a time.
Ironically, the ‘ask questions, break it down, think in trade-offs’ approach isn’t radical — it’s what system design interviews were meant to test before they got reduced to architecture talent shows.
System design interviews won’t go away. And they can be useful.
But maybe it’s time we align how we interview with how we actually build.
We say we’re agile.
Let’s interview that way, too.
🎯 If you’re a candidate walking into one anyway…
You can’t change the format. But you can shape how you show up:
Start with questions. Shape the problem before solving it.
Think in trade-offs. Show how you evaluate paths, not just where you land.
Keep it simple. Clear beats clever.
Use first principles. If you haven’t built at massive scale, show how you think.
Aim for a conversation. Not a final answer.
System design interviews may not reflect how we build.
But how you think still matters.
Make that visible.