Since I am currently on the lookout for a position, I thought I’ll share some tips that apply to system design or technical interviews — except the coding interview — that could help you prepare as well.
Be compliant, not arrogant#
It’s the interviewer’s job to throw the curve balls. Your role is not to dodge them. Always work with the new constraints, often when doing so, you find new ways to look at your problem.
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 the absolute shortest (as mentioned here), but don’t expend your energy on this; this is not the signal the interviewer is usually looking for.
Balance breath and depth#
The interviewer wants to find if you have the depth and breadth of knowledge that fit the role. You must play both angles: explore in breath whenever you need to expose 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 or you may not get that opportunity back: you rarely come back twice on the same question in an interview.
Quantities over qualities#
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 designs decisions. I included a data capacity ladder at the end of the article.
Break it down#
If the interviewer asks a vague question, you should break it down first before narrowing and going in depth on some topics. An example of vague question could be:
“I see that you have experience with AWS EC2, could you describe what it is?”
EC2 is one 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 AWS service that manages virtual machines running on the cloud. EC2 is made up of many subsystems required to run VMs: the node themselves (instances), the block storage (EBS), the images (AMI), the network security groups and network interfaces (ENI). 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 interview#
For system interviews specifically, you want to follow an expected plan together with an expected design system. I recommend using the C4 model as a design system 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 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 opportunity to the interviewer 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 details how your design can solve a specific problem.
For a 45 minutes interview, try to keep the Clarify and Dimension section 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 hierarchies.
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 behaved the nicest 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, don’t hesitate to ask for guidance. It’s better to show a bit of honesty in this situation. The interviewer will generally give you the clues needed so you can move forward.
Data transfer ladder#
Some illustrative operations or request per seconds to memorize when discussing distributed systems:
Similar chart for data transfer rates of some servers, proxies and messaging technologies:
