Recently, I hosted an Educative webinar on the System Design Interview (SDI). I showed attendees how the conversation is expected to go and provided ways to stand out in the interview. Then, we covered how to prepare for an SDI and how to gain experience in System Design. (If you missed it, don’t worry. You can watch it below or on YouTube.)
During the webinar, I was able to answer a few audience questions live. But because we received so many fantastic questions from attendees – far more than we had time to get to during the event – I wanted to write a blog to answer even more of the best and most commonly asked SDI questions.
System Design Interviews take a lot of careful preparation and practice. Only one in five candidates pass the entire technical interview process at top tech companies after they make it past the screen. Their most common pitfall is the System Design Interview. It’s important to know this interview because it’s become vital for landing a job and establishing the trajectory of your career. As I’ve written before, the SDI determines your level of seniority when you interview for a role.
Over 15+ years, I designed large-scale distributed systems and conducted hundreds of System Design Interviews. I drew on that experience to answer these 20 common questions.
Let’s take a look.
We’ll cover:
By approaching the conversation with RESHADED, you can be sure that you’re on the right track. It can be overwhelming to tackle such a complex topic in such a short amount of time. Practice outlining distributed systems using the aspects of System Design in this format so that it is second nature when you actually sit down with an interviewer.
This is a good question as one of the trickiest parts of an SDI is that formal education does little in the way of covering the specifics of System Design. Historically, knowledge of System Design comes from actual experience working with and designing real distributed systems. Most applicants don’t actually have experience working in this space, and your interviewer knows this. SDIs gauge aptitude for your problem-solving and design abilities. They let your interviewer understand how you are to work with.
Thankfully, Educative has a one-course solution for developers of any experience level: Grokking Modern System Design Interview for Engineers and Managers. The course starts by covering the components you’ll need to build a high-level design, and then it dives into the designs of real-world applications like Uber, YouTube, and Instagram.
I have been in these situations before, and they are never fun. But here is my advice: sometimes the best thing to do is to be as honest as possible as early as possible. If you know that you can’t solve the problem in front of you, or if you don’t understand how to answer what they’re asking, the best thing you can do is be honest.
That said, there are some non-negotiable things that you have to know. Every candidate should understand how to cache information, for example. If you need to, you can fall back on this foundational knowledge if you are asked a question outside of your skillset. An effective response communicates something along the lines of: “I don’t know about this particular cache-invalidation technique but I can explain a few techniques and their pros and cons.”
If you don’t have an understanding of something close to the topic your interviewer is looking for, your best option is to explain to them how you would go about learning the topic.
Senior engineers can discuss the inner-workings of every component in a software system. Working with a team of engineers, they design a system to be scalable and resilient.
Staff and principal engineers take their design conversations beyond the forecasted requirements of the system. They are not only concerned with the longevity of the software system itself, but how it can be successful over time, even in the event of unforeseen problems.
These levels of engineers may design around a number of different concerns. Here are a few example talking points broken down by level.
Senior:
Staff:
Principal:
There’s no quick answer to this question. Crossing this gap between engineering levels can take a long time and it’s not something worth rushing. To start, you should be extremely good at your current role. After you are intimately familiar with what your team is working on and comfortable with the example talking points above, start paying attention to some crucial soft skills. Staff engineers need to be excellent communicators and wise leaders. This is one of the biggest discrepancies between a very technically skilled senior engineer and a staff engineer.
To read more about different engineering levels, how they approach an SDI, and developing soft skills for the SDI, please check out our new, free course, The System Design Interview Prep Handbook.
This is a great practical question that is good to consider when preparing for a technical interview. There are several different scenarios to consider. Of course a piece of paper or a whiteboard is probably the most accessible way to illustrate your design, but with remote interviews becoming the norm, it’s likely that you’ll have to work with some sort of drawing tool. Let’s go over some of the tools you may be asked to use:
It’s good to have some knowledge of one of these tools so that you are prepared in the event that your interviewer wants you to use a digital drawing tool. Sometimes, interviewers will draw your ideas themselves. This takes another type of skill: being able to articulate your ideas clearly and accurately so that someone else can bring them to life visually.
This is a great question. Understanding the company that you’re interviewing for is obviously important when it comes to putting your best foot forward. But, it can also be helpful in anticipating the types of technical questions they’ll want to ask.
The SDI can be replaced with different types of design interviews. Sometimes this means you’ll be up against an Advanced System Design (ASD) interview. Your interviewers will ask you more focused questions based on improving/optimizing your high-level designs. Other times, you may be subject to a Low-Level Design interview. During these interviews, you’ll be tasked with designing objects and classes. These require a more programming-centric approach and are used to better understand your coding abilities.
For example, Fintech companies are extremely latency sensitive. They need to serve pages and deliver data quickly as markets change. As a result, their engineering teams are concerned with multithreading and concurrency-related topics.
The more you interview, the more you’ll see trends like this. Companies want to be sure you’re equipped with the technical skills required to do your job, so by researching ahead of time, you can stay one step ahead of your interviewers.
This is a common question when it comes to System Design. As we mentioned earlier, most interviewers know that a majority of applicants don’t have real-world experience building scalable systems.
There are tons of resources available to you to learn System Design, but if I were a beginner developer I would start here on Educative. Our System Design resources are created specifically to get you interview-ready. Make sure you understand low-level, object-oriented design first, and then you can get started prepping for your eventual System Design interview.
A strong hire from an SDI means they’ve done a lot of things right. By walking through the aspects of System Design in RESHADED, we can determine the areas where a strong-hire candidate communicated the right technical information at the right time.
One of the biggest things that interviewers look for, other than technical understanding and aptitude, is how well the conversation goes. What I mean by that is they want to gauge how well they can work with you. By looking at the SDI as a way to showcase how you perform as an engineer, a collaborator, and an employee, you can more holistically demonstrate your talents.
popular right now. Do they matter in System Design?
You’re right that machine learning and artificial intelligence are highly popular in tech news right now. It’s likely that the demand for engineers who are skilled in these areas will increase. Tech heavy hitters like Google and Microsoft have announced that some of their biggest products will be heavily invested in AI tech moving forward. A lot of other companies are going to follow suit, so if you have an interest, I highly recommend starting to learn AI and ML related concepts now.
As far as the System Design interview goes, it’s difficult to say how much AI and ML knowledge will help. If you are applying for an AI/ML engineering position, it is definitely important to give space in your SDI to talk about AI/ML.
For example, when choosing where to go in-depth, you should focus on machine learning processes, or how to design an AI-dependent system to be as compute-efficient as possible. We’ve seen OpenAI really struggle with scaling and server costs ever since ChatGPT exploded in popularity, and trying to address that problem is a very relevant challenge in the AI/ML space.
Capacity estimation calculations (sometimes called back of the envelope calculations) can be somewhat daunting given the amount of mental math they require. One of the biggest tips I have for this part of an SDI is to make it easy on yourself and purposefully use nice, round numbers. This means you should fives, and tens whenever possible. Otherwise, you’ll just waste time doing grade school math in front of your interviewer.
A blog I wrote about how to Design Spotify walks through how to approach these simple calculations throughout the System Design conversation.
Product management faces a slightly different side of the SDI than other traditional engineering roles.
But SDIs are still very important for technical product managers. While it is not crucial that TPMs be stellar coders, it is important that they conceptually understand the system that their team is working on. In order to effectively do their job, TPMs should know the relevant software building blocks but also how they fit into the larger system.
In an average SDI, most beginner- to mid-level candidates will not mention security when diving deeper into their high-level design. Security in a System Design context is important, but especially if you’re applying for a security role. Ensuring the system is healthy (and virtually impregnable) is only possible if you can acutely understand how it all works together.
The individual weight that an interviewer will place on an SDI for a security engineer role varies case-by-case, but for a significantly scaled system it becomes crucial that security-based roles know the ins and outs of their system very well.
This is a great question. Being a professional developer means signing on to become a lifelong learner, too. This constant upkeep of technological trends and Silicon Valley news is one of the reasons that we founded Educative. We wanted to make it easier for developers to stay up-to-date and competitive in their roles and in the job market.
Reading press releases and engineering blogs can be tough to make a habit of, but we have you covered with this newsletter. You can intentionally devote some time every Wednesday to catching up in the world of software engineering and interview prep by reading what we deliver to your email inbox.
Solution architects are concerned with aspects of System Design, but typically, they have a different perspective. System Design and the SDI require you to consider the system at a very high level and how to meet basic requirements. Solution architecting takes the individual software components into consideration, but from more of a business and cost-conscious angle.
Solution architects need to understand the basics of System Design, but they are not expected to be intimately familiar with the code and the minute inner workings of the building blocks they are managing.
Microservices are not the focus for System Design. Given the time frame, you are not able to dive deep enough to design a fully fledged microservice architecture.
Microservices segment a system to achieve independence from one piece to the next. This helps large-scale applications stay modern and scale later in their development. System Design is not really (usually) about scalability. Interviewers are more interested in the sustainability of the design than your aptitude for scaling. Outlining a sustainable architecture that meets the initial requirements shouldn’t really require you to discuss microservice-level scalability.
A certificate or a bootcamp may help you get an interview, but it’s not likely that the professional or university certificate programs cover the specifics of a system design interview in detail. Certificates help develop problem-solving skills and other technologies you’ll need in a software development profession, but when it comes to interview prep there are more specific resources available.
Both approaches are useful in different scenarios. Vertical scaling could get expensive but is relatively less complex. However, vertical scaling has its limits. Horizontal scaling is complex but can scale better. In a real system, you might end up leveraging vertical scaling for a smaller amount of critical data stored in a classic relational database management system (RDBMS) while a lot of user data (E.g. logs, images, documents, etc.) will require a horizontally scaled NO-SQL database.
The short answer to this question is yes. Depending on your specialization of choice, your interviewers will bend the SDI to more acutely test your abilities. For example, someone applying to be a data engineer would be questioned more on how to build scalable pipelines. Making sure that a system can ingest and sanitize large amounts of data is key to meeting the SDI requirements.
While web developers or software engineers are concerned with meeting the needs of millions of users, data engineers are designing solutions to gain insights from all of the telemetry collected by the system.
That said, the fundamentals of the SDI are still the same. You’ll still need to articulate a high-level design and defend your choices based on requirements and tradeoffs.
Thankfully most SD interviewers know that junior engineers won’t have the practical experience to dive in depth and explore a system like more senior candidates can. So, some of the best things that junior engineers can brush up on are the individual components of a large-scale system.
Know how the building blocks fit together and how to explain them. You should be prepared to discuss how they work in tandem to meet the requirements set forth by the interviewer. Here is a list of some of the most important building blocks:
The System Design Interview is an involved process, but we’re here to help you prepare every step of the way. You can start your SDI prep with our free course: System Design Interview Prep Handbook.
Being prepared for an SDI could mean the difference between being offered a mid-level and a senior engineering role. Therefore, SDI success can be the determining factor in gaining tens of thousands of dollars in salary – and opening up future career opportunities. It pays to be prepared!
What did I miss? Let me know if you have more questions.
Happy learning!
Free Resources