The System Design Interview (for beginners)

#computerscience #beginners #career #firstyearincode

Honestly, when I first heard that system design was a part of many technical interview processes, I thought "isn't leetcode enough!?" And so, naturally, I put off studying for it as long as I could. But when push came to shove and I had to do a deeper dive into what is really being asked in these interviews, I realized it makes sense why this concept is so important.

These kinds of system design or architecture questions in interviews are just there to see your thought process. And as important as it is to see how you tackle problems on an algorithmic scale, it's just as important to see how you handle situations at a higher level.

That's just my two cents on system design interviews, but I thought I'd share a bit of my research with all of you. I recently had an interview that I felt pretty good about and I wanted to share the process in hopes that it could be helpful.

Introduction

From a quick google of "systems design interview questions" or "system architecture interview questions" you can find that there isn't just one rule of thumb for what to study. It's not as simple as "hey, do 100 leetcode problems and you're golden!". The interview is much less structured and much more open ended, which can be some of the difficulty.

You can get a nice idea of what to expect from googling these questions or watching a few youtube videos (I've included a few helpful ones below) but I'll break down how my interview went and my thought process.

Another interesting part about this type of interview is that you most likely won't be coding that much. There could be a bit to explain high-level what you're thinking or what your functions would do, but it wouldn't be anything nearly as detailed as an algorithmic question.

Note: quick note that this is just from my beginner standpoint and definitely not for mid-senior level positions. My understanding is that system design interviews for these levels are much more involved and require a ton more detail.

The Interview Guide

Now that that's out of the way, let's dive into my guide for the system design interview:

Fully understand the problem and what you can do to solve it
- It's a good idea to take a minute in the beginning to ask your clarifying questions and just ensure that you fully understand the problem that needs to be solved. Some good questions to ask yourself or the interviewer would be:
  - Will this need to be a full web app or just an API?
  - How can this product help solve users problems / what are they getting out of it?
  - How many people would be using this app?
  - How will the app or API be used?
- Note: Don't get too detailed right in the beginning as that could make it difficult to see the bigger picture. Keep it very general at the start and you can build more detail as you go along.
Scope and scalability
- Now that you have a good idea of what problem you're trying to solve, you should make a note of the scope and scalability of the app or API.
- You may have touched on this in the clarifying questions, but here you could start to imagine if thousands of users would be accessing this app all at once that could be a huge strain on one server. Whereas this could be an internal company tool that is only touched by a few people a day.
- You don't have to make any definitive choices now like "we will absolutely need 15 servers!", but as long as you have in the back of your mind a general idea of how this could scale later on, that's great.
Create a template for your general structure
- With all of this information, you should be able to make a very, very broad sketch of what your app or API would look like.
- Say you're making a cookbook app where you'd want to be able to create recipe cards and see all of your respective recipes as well as other people's. You'd most likely need a full app with a front end where users can add and view their cards as well as a backend with a database to hold the information about the recipes.
- You can be very creative at this point with how you would like to create your app or API, but just make sure you have a good reason for why you'd choose what you do.
Dive a little deeper!
- Awesome, you have your general structure set up! Now you can get a bit deeper into those details we talked about earlier. You can choose what you'd prefer to talk more about, but make sure that you are able to add a bit of detail to each part of the app or API.
- Front end: Here you could discuss what your pages would look like and how a user would access it. It could be nice to talk a little about authentication too if you feel it is necessary. You can also mention how the front end would communicate with the backend (REST style, etc.).
- Back end: I actually didn't spend very much time on the backend but I did mention what frameworks I might use and briefly explained why.
- Database design: A large portion of my interview was used to discuss the database schema. I actually had to write out the basic design of my tables and a few SQL queries. So I would recommend brushing up on SQL just in case that comes up.
Revisit scaling
- Now that you've really added a lot of detail to your app or API, it's a good time to revisit the scaling ideas we put off earlier.
- If your app or API is going to have a lot of activity like reads or writes in the front end, you may want to add a load balancer to handle all of your server requests. Here is a quick, helpful diagram for what a load balancer can do:

If you know that one of your servers is going to have a ton of requests, maybe hundreds of times more than your other servers, you may want to think about caching and how that could help. Or even think about splitting up what that specific server is handling or scaling that server by adding more power to it.
- Caching is helpful in that it allows more frequently accessed information to be stored and referenced more quickly than spinning up the database every time a request is made.

Tips

Remember that it is an open discussion!
- Initially I was a little hesitant to ask questions, but my interviewer was very helpful and we would discuss the pros and cons of different ideas I would bring up. It's nice because there really aren't any wrong answers, a lot of it is a matter of preference.
There are so many parts to this type of interview, don't feel like you have to know everything and be honest about what you do/don't know
- I think especially from a beginner perspective, it's amazing to know about all of these tools, but it's also okay to say what you don't know. Sometimes the interviewer will be nice enough to explain to you what something can do or help you think of different tools to use for a particular problem.