Stress

As mentioned in the earlier post, a system design interview is not about finding the right answer. It is about exploring the possibilities and what you know and understand about large scale distributed systems. Nobody has ever designed a system in its final form in 45 minutes. Even the largest tech companies started small and gradually iterated their way to the complex engineering systems they have today. Accepting and understanding this will help you deal with stress. The interviewer is not trying to get the ultimate design from you. They want to have a conversation about how we could go about building something like what was asked in the question, with what we know today.

There may be many ways to deal with stress. But unless you understand the purpose of the interview, I don’t think anything will help. As an engineering manager, I try my best to make my interview candidates comfortable - as comfortable as possible. I don’t create artificial pressure and stress my candidate as I want to see the best from the candidate not their worst. I want them to feel like I am working with them and they are walking me through a design proposal.

However, I am sure different companies based on their interview and engineering culture might conduct interviews differently. So be prepared to face quieter, less conversational type of system design interviews too. In those situations, convince yourself that the person interviewing you is a member of your team that has just joined and you are trying to design the system with them. That’s one way I’d approach the stress of situation.

Plan or strategy

In a system design interview, I expect the candidate to go through the following phases of approaching to solve the problem

  • Ask clarifying questions
  • Understand the data flow and storage needs
  • Discuss the different parts of the system at a high level
  • Focus on part at a time, discuss in more detail and go into the trade-offs of different solutions or technological choices

I generally guide the person through the process, as I might be hiring an engineer. But if I am interviewing a tech lead or an engineering manager, I would expect them to lead the conversation and direct the interview with very little nudge or direction from my side apart from maybe the occasional, “what about x?” type of question that I might ask.

Clarify

When building something, you have to understand the purpose of it. Why do you need it? Whom are you building it for? How many users/transactions etc. Be product manager and get asking these questions. The answers are important to write down somewhere so that as you discuss the details of your approach, you can check against what was originally discussed and suggest why your proposed solution might work better for the constraints defined. So always clarify.

This clarification phase also helps scope the interview. The interviewer might be focussed on a simpler version of the mega scalable application. So in order to do an interview in 45 minutes, your questions can help narrow down the focus to one feature of the application.

However, in order to approach system design, you must always consider to factors:

  • The functional requirements - ability to send a tweet
  • The non functional requirements - no performance degradation as more tweets are sent on the platform

The first is what the product manager will ask for when working in a company. The latter is often implied. But it doesn’t hurt asking during the interview to clarify.

Data - flow and storage

Understanding the characteristics of data helps us make the right data storage and processing components. Some helpful questions that you must ask yourself might be:

  • What is the size of the data today and what rate would it grow over time?
  • Is the data in this context read heavy or write heavy?
  • Do we value strict consistency over eventual consistency?
  • Data durability?
  • Privacy and regulatory requirements?
  • What about how the data is consumed by downstream components?

Different parts of the system

Understand where to use what like where is an API Gateway appropriate. Similarly, figure out how they interact with each other, like a database to a message broker or queue. What about the type of database, is it NoSQL or relational? When does it make sense to one over the other? These are questions you either answer yourself while explaining the different parts of the system or might be asked by the interviewer.

Trade-offs

There is always more than one way to solve a problem. Thus it is important to understand why there are so many ways to achieve the same thing. Every technology choice has its pros and cons. You must be able to demonstrate your understanding of these pros and cons. Knowing names of technology is not useful. Knowing why you would choose one over the other is more important.

Once you are done showing a simple approach, critique your design and point out what it is not suitable for and how you would make it such that it would work that case. This is an excellent opportunity to demonstrate depth.

Don’t

All this while we focussed on what to talk about and how to approach the interview. We didn’t really cover what not to. They are obvious but better to be aware

  • This is not a coding exercise
  • Do not build anything without clarifying questions
  • Don’t just keep the discussions in your head - talk it through
  • Don’t throw choices of tech without reasons
  • Don’t act like you know something when you don’t

If a design question is about something you are not aware of, like something other than the popular services like Twitter, Uber, S3 etc, then ask and find out what it is. Let the interviewer explain it to you.