Common Mistakes to Avoid for Front End System Design Interviews
Know the mistakes candidates often make during front end system design interviews and how to avoid them.
Unlike coding interviews which are much more common and you can somewhat practice/simulate interview conditions, it is much harder to practice for system design interviews.
Here's a list of common mistakes made by candidates when they are answering system design interview questions and many of them are not specific to front end system design interviews. Hopefully you will remember these points and avoid them for your own interviews.
Jumping into answering the question immediately
Don't jump into answering the question immediately! Take the time to gather requirements and clarify assumptions by asking questions. Answering the wrong question well is worse than answering the right question poorly.
Approaching the question in an unstructured manner
Because system design interviews are very open-ended with no explicit completion milestone (unlike coding interviews where you have to produce working code), some candidates might just talk about whatever that comes to their mind and the answer might end up appearing messy to the interviewer. Use the RADIO framework to help you.
Write down each step of the RADIO framework on the whiteboard at the start of the interview and ensure that by the end of the interview you have covered each section sufficiently. Note that you don't necessarily have to complete each section in order and you can always revisit previous sections if you've missed out on certain things.
Insisting on only one solution or the best solution
Don't insist there's only one solution, especially if the interviewer prompts you for alternative approaches. More often than not, there are multiple ways to solve a problem, each with its own tradeoffs.
The interviewer wants to see you identify a solution with the right tradeoffs for the issue at hand, not you saying that there's only one right or best solution. The other solutions might be clearly bad and is very obvious to you, but the interviewer wants to hear you explain why they are bad.
Remaining silent the entire time
On the opposite of the spectrum of answering too quickly, there are people who remain too silent. Don't remain silent the entire time and thinking only in your head – think out loud!
System design interviews are meant to be collaborative exercises between you and the interviewer. Treat your interviewer as a coworker, bring up issues you've identified, bounce ideas, and discuss possible solutions with them.
Going down a rabbit hole
Don't go down a rabbit hole of diving too deep into a particular component. Define an initial architecture/high-level design first, then proceed to elaborate on the various parts of the system. Focus on the parts which are most important to the problem.
If you are unsure, ask the interviewer if you should dive deeper into a specific component. It'd be bad to spend too much time discussing about an unimportant component, wasting precious time without providing useful signals to the interviewer.
Using buzzwords without being able to explain them
Don't use buzzwords or terms you can't explain well. It might be tempting to throw out some cool terms like "Virtual DOM", "DOM Reconciliation", "Partial Hydration", "Streaming Server-side Rendering" and you can if they're relevant to the current topic!
However, if you do, make sure you are able to explain the term you just used as your interviewer is likely going to probe for more information to test your knowledge. It's a red flag if you are unable to explain the term you just used.