What do interviewers expect in a System Design interview?
System design interviews are so intimidating because you don’t really know what the interviewer is looking for.
Do they want you to do back of the envelope calculations to figure out scaling factors first? Or should you figure out the high-level components? Should you start with a simple design and iterate to a more complicated solution? Should you go deep into one part of the system or go broad and cover as much as possible?
And on top of it, you only have 45 minutes to go from an understanding to a somewhat complete design. And in most cases, the interviewer won’t give you many hints.
Unfortunately, these confusions don’t help and you fail to deliver your best. Or you thought you did well until you get a rejection email.
Thankfully there are several tricks to make System Design interviews less thorny and the outcomes more predictable. And it starts with understanding the expectations better from the interviewer’s standpoint. As a hiring manager, I found most of the candidates spend time on things that matter less and then don’t spend enough where it matters the most.
Different interviewers indeed have slightly different expectations but there are some good rules of thumb.
1. Lead the conversation
The interviewer expects you to lead the conversation proactively. Don’t get stuck or wait for help. This is your show and you need smoothly move from one step to another.
As an interviewer, I want to know how you deconstruct a large problem methodically.
Repeatedly guiding the interviewee doesn’t create a good impression from the interviewer’s side. It demonstrates a lack of expertise in large scale system design and can be seen as a big weakness.
Make sure you have a mental framework to divide the problem into smaller steps first before you dive into the deep water.
2. Talk numbers
Most of the System Design problems ultimately lead to designing large scale distributed systems.
But in most cases, the interviewer won’t explicitly tell you that. They might just say design Twitter. If the scale was not a factor a single machine monolith would just do fine. We all know that the interviewer does not want you to just do that.
However, as an interviewer, I don’t want the interviewee to jump right into designing a scalable system without providing the rationale. They should rather follow a logical progression.
A quick capacity planning during the interview demonstrates strong analytical skills and makes the interviewer confident about the interviewee’s expertise. Make sure you do some back of the envelope number crunching, make assumptions about daily active users and other scaling factors to justify the need for distributed systems.
3. Draw a high-level design
I know it is already common knowledge. It’s a design interview and how else you can depict your design? Right, the interviewer expects you to draw a clear (and somewhat complete) picture of your high-level design.
This is not a drawing test. Nevertheless, make sure your drawing is legible. Don’t forget to include all the critical subsystems and their connections. Ideally, it should look more like a sculpted garden and less like a wild forest.
Unlike some other parts of a technical interview, this is a real-life applicable skill. In real life, you will have to be in front of whiteboards with markers many more times to explain some ideas to your coworkers. This shows that you can explain complicated systems using a whiteboard.
4. Identify and solve core problems
Some System Design problems are too broad (example: Design Twitter). Your high-level design may contain components like Authentication, Profile, Feed, Notifications, etc. You can not realistically cover all of them in 45 minutes.
Here the interviewer expects you to “gracefully” disregard the boring parts and dig deeper into the core components.
I have seen candidates making the mistake of trying to cover everything or dig deeper into one of those “not so fun” parts.
In Twitter’s example, skip dull parts like Authentication or Profile, and double-click on critical problems like Feed. This allows the interviewer to evaluate your skills in solving more interesting scalability problems. This also shows that you can identify more demanding parts in a system and can prioritize your tasks independently.
5. Talk about trade-offs
There is no single right answer in a System Design interview. Your interviewer also knows that. But how do they score your solution then? Ultimately, it comes down to how well you could sell your prescribed solution.
Albeit you are selling to an engineer so you can’t just coin a fluffy jargon like “NoSQL” without any substance to support them.
The best way to sell is to briefly describe different alternatives and their tradeoffs wherever applicable. Then use data/fact driven rational to lean towards your preferred tool/solution or technology.
As an interviewer, I have existing prejudice and prefer one solution over another. But the interviewee can win over by discussing different approaches and their trade-offs.
Talking about the tradeoffs gives you a chance to showcase your comprehensive knowledge on the subject matter and impress the interviewer.
6. Make assumptions
Interviewers want you to make educated guesses. Making rational assumptions is encouraged over routinely asking for things like the number of registered users etc.
Questions like “how many write per hour are we expecting?” — creates a bad impression. As an interviewer, I expect engineers to figure out a ballpark number by themselves.
One quick tip, start by assuming daily active users (DAU). Most of the ops/sec can be easily derived from DAU. After you state an assumption, wait for a couple of seconds for the interviewer’s feedback or just verify it with them if you have doubts. Also, remember your peak traffic will be much higher than your average.
By making assumptions, you are showing that you have a good understanding of the scope and the scale some of these companies operate in.
7. Welcome interruptions
The interviewer may not be passive all the time and may try to course correct you. They may also want you to directly deep into some interesting parts of the system. Or they may just interrupt by asking some follow up questions.
I have seen interviewees get visibly irritated by feedback or interruptions. Don’t do that.
When this happens the interviewer expects the candidate to engage accordingly. Interruptions can break your train of thought but it’s just a part of life. If they want you to solve some particular part of the problem, do that. If the interviewer is providing some feedback or opinion regarding your choices, take them positively. The interviewer is trying to see how you handle difficult situations or react to criticism.
The best candidates can adapt and change their course as needed. Be nimble and keep calm.
Final notes
Ultimately a System Design interview is more like a stage show with only one audience — your interviewer. You are the only star of the show, so make sure you are running it throughout.
At the same time, System design interviews are as much behavioral as technical. Interviewers get a lot of different signals about your soft skills as you go through the distressing process. A tough situation reveals true character. It amplifies the strength as well as the weakness.
Don’t make the angst to cause panic, focus your mind and shine on your strengths.
Top comments (0)