Since I am currently on the lookout for a position, I thought I’d share some tips that apply to system design or technical interviews — except the coding interview — that could help you prepare as well.
Growth mindset#
It’s the interviewer’s job to throw curveballs. Your role is not to dodge them. Always work with new constraints; often, when doing so, you find new ways to look at your problem. It’s okay to not know something, so long as you demonstrate how you’d move forward:
“I don’t know this part, but here is how I can find out or tackle it”
Focus on the technical#
It may sound obvious, but if asked a question about your experience or if asked to provide more details about a line on your resume, focus on the technical. Mentioning your stint as a manager or the fact that you took a sabbatical break to travel the world may be okay if kept to an absolute minimum (as mentioned here), but don’t expend your energy on this; this is not the signal the interviewer is usually looking for.
Balance breadth and depth#
The interviewer wants to find if you have the breadth and depth of knowledge that fit the role. You must play both angles: explore in breadth whenever you need to outline your solution, but don’t miss an opportunity to explore in depth when answering a question. If you answer a specific question with hand-wavy statements, you may not get that opportunity back: you rarely come back twice on the same question in an interview.
Research!#
You know what never happened in 20 years of interviewing: company working in domain A asking a question about domain B. Every single technical interview will center around something the company already does or will do very soon. Therefore, those who do extensive research about the company’s domain stand to have an edge: you understand hints and questions better, it becomes easier to speak the same language as the interviewer.
Things you should research before a technical interview:
- Blogs or engineering articles by the company or its competitors,
- Discover as much about the company’s systems and technologies in use as you do about its process, regulations, and other domain constraints,
- Map the organization, how it relates to its customer base,
- Understand its engineering culture,
- Harness AI to be a mock interviewer to train on related topics from the information you gathered.
Quantitative over qualitative#
If you can quantify something, it’s better than qualifying it. But if you can’t quantify it, then qualifying it is better than nothing. For example, prefer:
“DynamoDB can handle 1M QPS (read and write) compared to MySQL 10K QPS (reads and writes)”
Over:
“DynamoDB can handle much larger QPS (read and write) than MySQL.”
Numbers are king, and help you justify your design decisions. I included a data capacity ladder at the end of the article.
Divide and conquer generalities#
If the interviewer asks any question, you should evaluate whether to break it down first before narrowing and going in depth on some topics. An example of a vague question could be:
“I see that you have experience with AWS EC2, could you describe what it is?”
EC2 is one of the most complex AWS services, one that could take the entire interview to answer. Typically, the answer calls for a breakdown after a short intro:
“EC2 is an AWS service that manages virtual machines running on the cloud. EC2 is made up of many subsystems required to run VMs: the nodes themselves (instances), the block storage (EBS), the images (AMIs), the network security groups and network interfaces (ENIs). It provides autoscaling capabilities through Auto Scaling Groups. Instances can be provisioned on-demand, spot, or reserved. Would you like me to zoom in on any particular subsystem?”
This is a top-level breakdown of EC2, only 1 layer deep. It’s not in-depth on any system but gives enough insights to the interviewer that you are comfortable with the topic. That last hook gives pause and allows the interviewer to decide how it wants to spend its time.
Structure of the system design interview#
For system design interviews specifically, you want to follow a structured plan and a design methodology. I recommend using the C4 model as a design methodology because it is hierarchical and feels natural. Usually, the plan is:
- Clarify: make sure you understand the focus of the exercise. You don’t want to dwell on sub-components that the interviewer does not care about. At this stage you should have an understanding of the domain and you should be able to draw your system context. Ensure that you do not miss any “meaty” parts of your system.
- Dimension: pin down the spatial scope (e.g. world-wide vs city?), temporal scope, and the quantity of data exchanged and stored in each context. At this stage, you should have a rough understanding of the orders of magnitude for every dimension. This will drive the justifications of your design.
- Overview: break each system context into its constituent containers. This is where you describe your approach to the interviewer. You should label the flow, the main functions and give a brief description of how each container satisfies the constraints of the problem, e.g. how the system scales to meet its demand.
- Deep-dive: give the interviewer the opportunity to ask specific questions and propose to zoom in on some particular component of your design. It’s a good time to discuss protocols, define APIs and describe in detail how your design can solve a specific problem.
For a 45-minute interview, try to keep the Clarify and Dimension sections under 15 minutes total. You want to spend most of your time in Overview and Deep-dive. Finally, if it helps (it does for me) restate the objective of what you are trying to demonstrate at each hierarchy.
Practice#
Nothing replaces practice, no matter how confident you are in your skills; being able to demonstrate that confidence in a short interview context requires practice.
- Start with your CV items,
- Identify the technical questions based on the keywords or claims in your CV,
- Write down your narratives,
- Practice answering these questions.
Remember to smile#
An interview is a stressful setting. But all things being equal, candidates who came across best get the gig.
Sometimes, it’s better to ask#
Most interviewers prefer to be engaged in an interview. I certainly do, when I interview. If you feel out of your depth on a particular task or question, don’t hesitate to ask for guidance. The interviewer will generally give you the clues needed so you can move forward. It’s better to show humility in such a situation than to speak incorrectly about something you do not know or understand well, or — worse — leave no doubt about your ignorance of the subject.
Get past your impostor syndrome#
The interview is not the place to question your (lack of) knowledge constantly. The biggest disservice you can do to yourself is selling yourself short. Do not provide information about the limits of your expertise, as that could further be misinterpreted. It is already difficult enough to convince the interviewer that you know enough in a particular area, in such a short span of time. Give yourself a break and a bit of confidence.
Data transfer ladder#
Some illustrative operations or requests per second to memorize when discussing distributed systems:
Typical data transfer rates of some servers, proxies and messaging technologies:
