I would like to provide some advice for System Design interviews that is at odds with the guides provided by sites like HelloInterview and interviewing.io. I will start with the shortcomings of their method, and then I will tell you what I think you should do instead.
These sites teach a prescriptive formula for system design interviews. You just have to do functionalrequirementsnonfunctionalrequirementshighleveldesign! It’s so easy that you don’t even need to know anything about systems. (I mean no offense to the author of that blog post, whom I recall as an excellent career coach back in his Triplebyte days.) Hey! Here are some pithy remarks and segues to use throug…
I would like to provide some advice for System Design interviews that is at odds with the guides provided by sites like HelloInterview and interviewing.io. I will start with the shortcomings of their method, and then I will tell you what I think you should do instead.
These sites teach a prescriptive formula for system design interviews. You just have to do functionalrequirementsnonfunctionalrequirementshighleveldesign! It’s so easy that you don’t even need to know anything about systems. (I mean no offense to the author of that blog post, whom I recall as an excellent career coach back in his Triplebyte days.) Hey! Here are some pithy remarks and segues to use throughout your interview.
It all seems very smooth and convincing.
However, first of all, it’s very obvious when someone is following one of these guides, and it’s especially obvious when they’re leaning on the formula as a crutch. The candidate is primarily concerned with checking off each box in their plan — wasting time and distracting from the actual task at hand.
Second of all, I think people often treat these guides more literally than they are intended. What the training videos meant as situational examples, people interpret as part of the inherent structure of system design interviews that needs to be repeated in every interview. For example, the other day a candidate began as follows:
- Functional requirements (a few bullet points, not necessarily the most important ones)
- Non-functional requirements (again somewhat random)
- “And now, I’d like to address the CAP theorem.” Here the candidate announced that they would prioritize “availability over consistency,” although it wasn’t clear how we could evaluate such a decision, or what it applied to. But this was the point in the interview where Evan King discussed availability vs consistency in his Youtube system design tutorial.
Indeed, the candidate repeated so many remarks from Evan King that I felt as if I were participating in a fan fiction of sorts.
And look, I like Evan King! I think he’s a great communicator, and his videos are very educational. But it’s still obvious when people are desperately parroting the form of his interviews.
Okay, so what do I recommend that you focus on in system design interviews? Frankly, just two things:
- What am I being asked?
- What is interesting about this problem?
For some reason, candidates often procrastinate a long time before getting to the part of the problem I want to discuss. (And which I highlighted at the beginning of the interview.) Candidates will spend fifteen minutes painfully enumerating APIs and database schemas before addressing the core problem, if they even get that far. They treat the seven stages of the HelloInterview prep guide as a rote prayer that must be recited at all costs.
Look, all I want is for you to talk about the interesting part of the problem. While you enumerate POST bodies and draw boxes that say “API gateway” — I’m just waiting for you to get to the point. What is the essential issue that captures why the system is not a basic CRUD app? You can always talk about the boring parts of the problem later, but odds are I won’t let you get there, because we are having such fun discussing the important part.
To sum up: Don’t get stuck in an elaborate canned interview formula. Just confirm what the problem is and start exploring the most interesting part.
Published November 6, 2025