Succeeding in Your System Design Interview

You impressed everyone on your way to getting a job at QuintoAndar and there is only one last phase: the System Design Interview.

When interviewing for a Software Engineer role, especially at Big Tech™ companies or high-growth startups such as QuintoAndar, you will usually face system design interviews.

We have compiled the experiences of multiple QuintoAndar interviewers to explain what is expected from our candidates. In this type of interview, it is often unclear for the candidate what they are and how they should prepare.

If that is the situation you are in, fear not! We are here to lead you in the right direction.

Photo by Christina on Unsplash

What exactly is a system design interview?

The specifics of how these interviews are executed can vary across companies, role levels, and even the interviewers themselves. In general, the system design interview is an open-ended conversation where you have the opportunity to showcase your knowledge and experience in developing real-world systems.

Okay, but what does that really mean?

It means that the interviewers are interested in getting to know you! How you solve problems in general, and how you collaborate with others — such as your colleagues or the interviewers themselves — to arrive at a solution.

First, the interviewers will probably be interested in your past experiences. They might ask what kind of problems you have encountered in previous projects, your role in solving them, what did you learn from the experiences, and so on.

Then, there are the famous system design interview questions. They can be as general as “How would you design a URL shortener?” or can involve scenarios closely related to the job or the company. In any case, they usually start as broad and open-ended, and as you proceed with your solution, the interviewers will dive deeper into certain subjects.

Note that expectations are different for entry-level or more senior positions. In all cases, it is important to have a strong knowledge of Software Engineering fundamentals, a good starting point is The System Design Primer and you can find more references at the end of this article... At the end of the day, the more experienced you are, the more your real-world experience matters for the job and the interview

We will talk in detail about each one and of course, your experience may vary, but these two approaches are common enough, including here at QuintoAndar!

Let’s talk about your previous projects

Nothing beats real-world experience. As I said, the interviewers will probably be interested in your past projects as they are a testament to how you have worked in the past, which concepts and technologies you are already familiar with, and how much you have learned from them.

It is important to note that I am not talking only about previous jobs. If you are at the beginning of your career, your personal projects are just as valuable! The interviewers will want to know about them, so be prepared to talk about it, whether they are from college, boot camps, online courses, hobbies, etc.! They talk about your ability to perform the job well.

What to say about a project is important too. You should be prepared to discuss its technical components in-depth and also talk about the non-technical aspects as well, such as how you or your team prioritized tasks. For both cases, how much you are expected to know depends on the level of the role you’re applying for.

In summary, this is your time to shine!

You are expected to have an understanding of the fundamentals of the system, being able to always answer two main questions: what were the moving parts of it and why were they there?

I really like complete examples, so let’s suppose you are talking about a simple web application that was developed using Java for the back-end system, PostgreSQL for the database, and React for the front-end. You should be prepared to answer the technical and non-technical considerations of each choice.

• What are the benefits of using a SQL database when compared to NoSQL alternatives?
• Why did you (or your team) choose PostgreSQL instead of other options such as MySQL?
• What motivated you (or someone else) to develop the front-end in React?
• How does the front-end communicate with the back-end? Why was it designed like that?

These are just generic examples, the main point being how you should focus on being able to explain why decisions were made, as understanding them allows you to use your past experiences to make better decisions in the future.

Consider the last question example, let’s suppose that besides simple HTTP calls to the back-end’s API, you explain that the website also uses WebSockets for specific features. You should then explain what made you choose WebSockets, for example a need to receive in real-time a large quantity of updates from the server, a scenario in which HTTP calls would not be fast enough.

Even answers that might sound bad at first are valid and you should be honest about them. These kinds of answers are also a great way to show how much you have learned and grown as a Software Engineer. Let’s cover a couple of scenarios:

1. I was not the one that made the decision.
2. I didn’t really have a reason, it just felt the right choice at the time.

These are valid answers and these scenarios happen all the time. Maybe you wanted to try the current Cool New Tech™, maybe someone told you one option was better and you should do it that way. In that case, you should follow up with more details about the scenario in question, as the interviewer will want to understand your role and your current knowledge about the subject.

• Did you take part in the discussions leading up to the decision? What was your role in them?
• How did you handle the situation once the final decision was made?
• If you had to make the same decision today, how would you approach it? Which factors would you consider when choosing one option over the others?

The most important thing is to show the interviewer that you have grown as a Software Engineer. Also, demonstrate that if you had to make the same decision today, you would be able to make a better-informed one, even if it ended up being the same. After all, maybe you were right in that case, but how would you know if that choice would be right for your next problems?

As an anecdote, I once went through an interview in which this exact scenario happened. I had a bullet point in my resumé that proudly described something I did to improve the project’s maintainability. The interviewer then asked me why did I do that specific thing over other available options, and how did I know whether the maintainability aspect actually improved in the end. As I was answering, I fully realized how it was an uninformed decision based on personal feelings alone, and I told exactly that to the interviewer. I then proceeded to tell him what I would do differently if I encountered myself in that situation again, such as understanding better what and how I wanted to change the project, including the options I had and their respective trade-offs. And yes, I did get the job :)

In conclusion, go through each of the projects included in your resume and ensure that you can talk about them in detail.

Choose a few of them, which you played a central role in their development. Ensure that you can talk about the technical and non-technical components in-depth: the challenges, mistakes, technical decisions and their tradeoffs, and how you would handle the same scenario given your current knowledge.

How would you design a {system}?

On top of getting to know how you have approached problems in the past, the interviewers will probably want to see it firsthand, by asking you to design an arbitrary system with them.

There are classic examples of this type of question: an URL shortener, a web crawler, a chat application, etc. Each question has its own caveats and specificities, and with that in mind, this article will focus on general principles to follow when solving these kinds of problems in an interview.

The interviewer is working with you, not against you

When solving this kind of problem, you and the interviewer are working together in search of a solution. Communication is key and your thought process should be clear to the interviewer.

Hence, be open about what you are thinking in regards to the problem you are currently solving. Talk about the options you are considering, their tradeoffs and how you are comparing them, which parts of the system you are going to attack first and why, etc.

In counterpart, the interviewer is also there to help you with any barrier you encounter. It might be something that is at the tip of your tongue but you can’t remember, or a topic that you have never encountered or studied in depth. The interviewer will be there to help you to overcome these gaps and achieve the full potential of your current skills.

Finally, as mentioned at the beginning of the article, the interview is an open-ended conversation. It is normal to focus and think in silence sometimes, but try not to keep the interviewer in the dark for long periods of time, as collaboration is an important factor and you are expected to lead the conversation.

A well-defined system

System Design interview questions are commonly open and ambiguous by design. Their goal is to understand how you approach open and non-defined problems in your day-to-day work.

In scenarios like these, there is a realm of possibilities when talking about how to solve the given problem and it is your responsibility to guide the direction of your solution. In general, it is a good idea to follow three fundamentals of a data-intensive application: reliability, scalability, and maintainability. [4]

Remember that the interviewer is working with you. You should validate with them any assumptions you have about the system, and feel free to directly ask them any questions that might pop up.

Partner with the interviewer to narrow the system definition down and understand which aspects of the design should be the focus of the conversation. At first, understand the general aspects of the system:

• What will the system be used for? What goal does it try to achieve?
• Who are the users? How will they access the system or what are the entry points?
• What are the inputs and outputs of the system?
• […]

Once the general aspects are defined, you can discuss topics that although are more specific, will be important when designing the system architecture.

• Should scalability be a concern at the moment?
• Which components of the system should be the main focus of the discussion for now?
• Which technologies, data structures, or algorithms are useful for this scenario?
• […]

These are not necessarily questions for the interviewer, but points to consider when leading the design with them, as they will probably be interested precisely in knowing your answers to these questions given the other information you already have available. If you are not sure of how to proceed at a given moment, remember that you can always ask more clarifying questions for the interviewer to help you get unblocked.

For example, if you are trying to decide how much scalability is important at the moment, you can ask the interviewer how many users are expected, or the rate of requests per second to the system. If you are not sure which technologies could be useful or trying to decide among a few options, you can ask for more details of the expected behavior of the system and then think out loud with them about how that impacts your considerations.

In summary, defining the system is an important and continuous task throughout the interview, where you should focus on clarifying aspects and assumptions with the interviewer and leading the architecture design with decisions based on the information you have.

Diagramming

As you proceed through the question, the interviewer will be interested in simple diagrams that describe in high level the architecture of the system you are designing. You will probably draw them on a whiteboard if the interview is in-person, or via online tools such as diagrams.net if the interview is remote.

The key aspect of drawing a diagram is basically the same one of defining the system, start simple, with general aspects, and then drill down on certain components as necessary. This will help you, and the interviewer, to identify the entry points of a system, e.g. an endpoint in an HTTP API, possible performance bottlenecks, and other important considerations.

By diagramming the architecture, it should also be clear how the responsibilities of the system’s components are separated, which in turn helps you to reason about which components should be more precisely described and which can be summarized.

For example, depending on where is the focus of your design, you might decide to describe the database as a simple component of your system responsible for persisting data, or dive into the details by including its schema in case it is important for the task at hand.

The “whats” and “whys”

Throughout the interview, you are the one responsible for designing the systems and making decisions. Just like when talking about your past experiences, you are expected to have a good understanding of what you are applying to your solution and why you are applying it.

In any steps you take, try to make it clear why this step is important for the problem you are trying to solve. If you are asking a clarifying question, show the interviewer why and how the answer is useful for the task at hand. If you are making a choice, describe what you are expecting with this choice and why it was selected over the other options.

In summary, being able to describe your decisions and the reasoning behind them in real-time, to the interviewer, shows that you understand how Software Engineering involves tradeoffs after tradeoffs, and that you are capable of understanding the pros and cons of different approaches.

In conclusion of this article, there is no silver bullet when it comes to System Design interviews, but there are guidelines on the best approaches to show your skills and knowledge to interviewers. We hope this article helps you to land your dream job!

Take a look at our tech blog and check out all of the amazing projects we are working on! We are hiring and would love to hear about your most exciting projects on one of our interviews. If you are interested, come work with us by applying via our careers page.

Work@QuintoAndar

Huge thanks to Pamela Peixinho, Luciano Holanda, Eizo Nishime, Tiago Santos, and Mateus Pelluchi.

References

• [1] The System Design Primer — Knowledge base about studying and practicing for System Design interviews.
• [2] Preparing for the Systems Design and Coding Interview — Collection of resources for preparing for System Design interviews.
• [3] System Design Interview — An Insider’s Guide by Alex Xu — Great book about teaching how to design “real-world” systems.
• [4] Designing Data-Intensive Applications by Martin Kleppmann —A thorough overview of the fundamental principles “behind reliable, scalable and maintainable systems”.