Most Candidates Don’t Fail System Design Interviews Because They Can’t Design Systems
They fail because they’re performing instead of problem solving.
I’ve run hundreds of system design interviews across American Express, Anduril, and Shopify. The meta game most candidates miss is understanding what I’m actually evaluating.
I’m thinking, “Can I put this person in a room with stakeholders and trust they won’t shit the bed? Will they figure out the right things to build? When they hit ambiguity, do they freeze or discuss tradeoffs at a 30,000 foot level instead of getting lost in the weeds?”
The failure pattern I see constantly is candidates who memorized chapters from Designing Data Intensive Applications saying “let’s put a cache here” without knowing why they’re putting in the cache. When I’m running a system design interview, I’m not ticking boxes. I’m vetting what it’s actually like to work with you.
Three Things That Actually Matter
Requirements gathering is the most neglected and most important. If I ask you to design Twitter, that’s not a spec. That’s on you to start co-creating the spec with me. Which Twitter? 2009 Twitter? 2025 X? (Spoiler: if you want to make 2025 X, just fire 75% of your staff and make sure the service goes to shit.)
Part of requirements gathering is negotiating scope. You have 45 minutes to design Twitter. You can’t design all of Twitter. Propose what part is interesting. The red flag is jumping straight into arrows and boxes. I see it all the time and it just has a very junior smell to me.
Tradeoff articulation matters more than your technology choices. I do not give a shit if you pick SQS or Kafka. It’s probably not important to the scope of the problem we’re discussing. I care that you can tell me why you selected your given tech, what it gets us, and what it loses us.
“It depends” gets thrown around a lot. You should be able to say it depends on what. What’s your clear rationale for choosing the tradeoff?
Staff level answers sound like this: “I would choose XYZ technology because at our current scale this solves this issue better than another technology. With the caveat that if we scaled 10x, we would need to revisit this decision.” That’s forward thinking. That’s discussing tradeoffs clearly. Huge win.
Failure mode analysis is where you can really shine. As soon as a candidate finishes their first pass, I’m going to ask: what breaks first when we flood traffic into this? When one node in a cluster goes down, what happens?
If you were discussing tradeoffs well, you’d know right off the bat. A strong signal for senior or staff level is identifying where those breaking points are before I even ask.
Leveling Signals
Junior to mid level developers focus on the happy path. They prematurely optimize for problems that aren’t problems yet. They treat requirements as fixed instead of negotiable.
Seniors start looking at business and people dynamics. They ask “what is the cost if we are wrong here?” They propose phased approaches. They identify organizational gaps like “this is gonna require a data team that in the scenario you presented we don’t have.”
Staff plus will challenge the problem framing itself. They connect technical decisions to business outcomes and risks. Most importantly, they know when to not build something. They will actually ask: do we need this component? Can we get by without it for a quick launch?
Two Failure Modes I Hate
The overbuilder interviews at a Series A startup proposing Google level architecture. Read the room. Google level architecture is good for a Google system design interview, not for a small startup.
The rote memorization person is probably my least favorite. They regurgitate pre-made solutions, clearly having studied a bunch of system design content and just regurgitating answers. This can come off as senior or even staff level until you start kicking the tires or throwing constraints in. Which I’m going to do, because I want to see you think on your feet. This is an investigation into how you actually work.
Parting Tips
State your assumptions clearly: “I am assuming we are designing a system for 100k daily active users. Is that assumption correct?”
When stuck, verbalize it. If you’re genuinely weighing pros and cons between database A and database B and the reasons are nitpicky, say that. Talk through it. That’s the interesting thing to see.
If you’re in doubt about how deep to go, ask. Present your caching strategy, then ask if they’d like more information or if you can move on.
One More Thing
I know I’ll get pushback on this. There’s tons of content out there that’ll have you memorizing patterns and solutions. Study is good. But ultimately what I’m looking for is how a person vibes in real time designing a system. It’s not a memorization test.
I did the system design interview at Google L6. I passed the bar but got flagged on one interview because I had too much discussion, too much back and forth. They wanted a cleanly regurgitated answer. Judging correct or not correct.
You have to reflect: do I want to work at a place where they’ve hired a bunch of people to just regurgitate textbook answers? If yes, then you’re doing something that’s maybe not quite engineering. It’s more of a memorization test.
For me, when a system design question rubs the interviewer the wrong way because I’m not giving a cookie cutter solution and instead we’re dynamically solving the problem together, that’s not a company I want to work at. No creative engineers there.
This is also an interview from your side of the table. Make sure it’s the kind of dialogue and vibe you want when you’re designing systems on the job. Because hopefully if you get that offer, you’re gonna be with that person.
If you’re prepping for system design interviews or trying to figure out what the next level looks like for your tech career, I’m running a free coaching pilot in January. Reply to this post or DM me if you’re interested.