[0:00]If you click play on this video, then you probably have an interview coming up. My guess is that you feel good about how to prepare for coding interviews, but system design makes you a little bit nervous. I'm Evan, I'm a former meta staff engineer and I've conducted many hundreds of interviews. And I'm now the co-founder of Hello Interview. Hello Interview is a platform that helps candidates just like you prepare for their upcoming interviews. In this role, I've now worked with hundreds of thousands of candidates, and through that, I've gained a really good understanding of what works and what doesn't. And so I know that system design can feel incredibly overwhelming, but it doesn't have to be. The key, just like with lead code for coding prep, is to work backwards from common problems. I'm going to tell you exactly which problems I would focus on and in what order a little bit later on in this video. But before diving into specific questions, you would need a basic foundation. And so the first thing I would do is I would understand what the hell is system design interview actually is. Then I would go ahead and refresh on my fundamentals. These are going to be concepts that you likely learned back in college and just need a touch-up. From here, I'd get familiar with the basic components that are present in almost every single system design. And then we can finally start to work backwards from those common problems so that we can build a deeper understanding. Now, you'll probably note this strategy mirrors how you're already preparing for coding interviews, identifying patterns across problems, rather than memorizing random solutions. Let me show you what I mean. So first off, what is a system design interview? Well, the system design interview evaluates your ability to architect complex, scalable systems that solve real world problems. Sounds like something out of a textbook, what is it really? You come to a whiteboard, the interviewer asks you design a system, something like Ticketmaster or Uber, and you draw boxes explaining at a high level what services and interactions are necessary to pull off designing the system. You're not writing code, it's typically just boxes and arrows. Now, this diagram shows that there are a few types of heavily overlapping design interviews. In this video, we're talking about by far the most common, which are product and infra design problems. Now, a product problem, this is when you're designing an app or a website that you use every day, something like Dropbox or Uber, Netflix, all of these things that you know well. Infra on the other hand, infrastructure design problems, these are non-user facing systems. So components like designing a rate limiter, maybe designing a message queue, or even data processing pipelines, things like an ad click aggregator. But in general, when you have a system design interview, it's likely going to come out of one of these two buckets, either product design or infrastructure design. When you get into an interview, it's really, really important that you follow a framework. This keeps you focused and it makes sure that you're on time. And so as you prepare, you'll want to choose a framework that works really well for you. I strongly recommend that you choose this framework here. What you're going to do when the interview starts and you're asked to design a system, like design Ticketmaster, is you're going to start by outlining the requirements of the system. Now, this includes both the functional requirements and the non-functional requirements. Functional requirements are just the features of the system, like a user should be able to book a ticket, and a non-functional requirement is the quality of the system, like booking tickets should be low latency, right? Or the system should be able to scale to whoever many number of users. This ensures up front that you and your interviewer agree on what you're going to be designing. Next, you want to outline the core entities of the system. These typically map directly to the tables in your database. These are just the entities that your system will persist and that your API will exchange. So think like a user, an event, a ticket, simple as that. Then you're going to outline the basic APIs needed to meet your functional requirements. Nine times out of 10, these are probably going to be rest endpoints, but there might be unique cases where graph QL or something else makes more sense. But from here, you then get into the fun stuff. You get to head over to that whiteboard and you're going to start drawing boxes and arrows starting with a really simple high-level design, where the goal of the high-level design is to meet the functional requirements of your system. So a really simple, not complex design that can allow users to say book a ticket. From here, you're going to get deep. And this is where you're going to enhance that initial high-level design via deep dives, where the goal of the deep dives are to satisfy your non-functional requirements. So now that I can book a ticket, how do I make sure the booking it is low latency? How do I make sure that it's strongly consistent? How do I make sure that it can scale to those scale numbers that you might have agreed upon with your interviewer? Now, the last step in understanding what a system design interview is is understanding how your interviewer is going to be evaluating you. Now, every company is slightly different of course, but they all evaluate you on some permutation of the following. One, your problem solving skills. So, this is most importantly your ability to recognize and prioritize the core challenges of the system. So if you're designing Ticketmaster, you're focused on the booking flow, you're not focused on authentication, for example. Next is your solution design. This is your high-level design from that framework that we showed just a moment ago. Did you weigh trade-offs and did you arrive at something that meets those functional requirements? Next is your technical excellence. And this is where you're going to show off in your deep dives that you have technical expertise in some, not all, but in some areas of the system. Can you go deep, talk about specific technologies, talk about specific areas where things could break, all of this. And then lastly, of course, is your communication skills. Can you clearly explain complex technical concepts? You'll be talking for 35 minutes to an hour during the system design interview. You need to be clear and competent in doing so. Next up, you're going to want to make sure that you have at least a basic foundational understanding of some of the fundamentals. And so people are going to provide these long, overwhelming list, you've probably seen them online of all these things that you need to know. But in reality, knowing these six concepts here are going to get you 90 plus percent of the way there. And so this is where I would focus my time. First up is storage fundamentals. When it comes to storage, you should be able to discuss various data storage models and the appropriate use cases. And so be prepared to explain things like how data is organized in a relational database, where you have normalized tables with relationships, versus document stores, where you have nested JSON-like structures like this, and then also key value stores, where you have a simple lookup mechanism based on a key. Your interviewers is also going to expect that you understand acid properties for transactional systems in particular, and that you're able to compare and contrast these with base principles for distributed databases. You should be able to articulate when each storage paradigm makes sense based on access patterns and the given consistency requirements of your system, which you probably agreed upon in your non-functional requirements. Now, next up when it comes to the fundamentals is scalability. And scalability is just the concept of how do we scale our system so that we can support more users and more requests. And scalability almost always comes up in a system design interview. And so when you're talking about scaling compute, when you're scaling your servers, you should know about vertical scaling, beefy your machines, more CPU, more RAM, and also horizontal scaling, let's just add more machines to be able to service these incoming requests. You should also understand how to scale storage. And so this is techniques like partitioning and sharding, splitting data instead on a single database across multiple database instances, as well as how to distribute data efficiently across these different instances, like the famous consistent hashing algorithm. We actually have a video on the channel that goes into detail on consistent hashing. So, if that's new to you, check that one out. Okay, so next up is networking. Uh, when it comes to networking, you probably remember learning about these OS O S I layers, excuse me, in college. And I have good news for you. When it comes to your interviews, you only really need to know three of them, the application layer, transport layer, and network layer. And so the application layer is going to be the most important for your interviews. And this is where you are going to want to know things like API design, rest versus graph QL versus GRPC, which makes sense when. And you also want to understand real-time communication by web sockets or server sent events, this is what you'll use in the case of designing, for example, a chat app. And then second is the transport layer. And so for infra style interviews in particular, knowing about TCP versus UDP, for example, and the request life cycle is going to be really important. And then lastly, when it comes to the network layer, you should have some basic understanding at least of load balancing and maybe understand firewalls or access control lists. Uh, but unless it's a a specific type of interview, this is maybe less likely to come up. Now, just like with consistent hashing, we have a really excellent detailed video on all thing networking essentials. And so, if you don't have this already down, that's the first thing I would do, head over to that video and check it out. Fourth is latency, throughput and performance. And so, there's a decent chance that you're going to be tasked with optimizing performance somewhere near your interview. And so you should be able to recall approximate latency numbers for common operations, things like memory access, disk reads or network calls. And then when discussing your requirements in the beginning of the interview, you're going to want to demonstrate your ability to understand some throughput limitations and maybe perform some basic capacity planning estimations. And so you should be prepared to identify also performance bottlenecks, maybe even proposing solutions in your distributed architecture. For example, adding a cache to lower latency. And so, I've linked down below an article that should cover everything that you need to know about performance optimizations as well. Second to last, we have fault tolerance and redundancy. And so this is relatively basic, you should be able to recognize and communicate to your interviewer that failures are inevitable in distributed systems. And so you should be ready to discuss things like replication strategies and failure detection mechanisms. Your design should incorporate redundancy at the appropriate levels, servers, racks, maybe data centers, so that you can recover from these failures gracefully. Last up is CAP theorem. You're going to talk about CAP theorem earlier in your interview, often times in the non-functional requirements. And you're going to want to make sure that your system upholds whatever decision you make in as it pertains to CAP theorem. And so CAP theorem of course is consistency, availability and partition tolerance. Your system can only have two of the three. Partition tolerance is a guarantee. And so your only decision is should my system prioritize availability or consistency. And now, if this is foreign to you, you don't know what I'm talking about, don't stress it. We have a really detailed video on CAP theorem as well. I think it's less than 10 minutes long, should go quick, and that's also linked below. And then we have our database. And so this is where your data lives when the power goes off. You have options here. You've got a traditional database like Postgress, which is going to keep everything organized in these strict little tables with with uh clear and defined rules. You also have maybe relatively newer options like MongoDB. This is going to store information more in documents and JSON blobs. And then you have other things like Redis, which is going to store simple key value pairs that you can look up really quickly. Now, importantly, and I see this mistake a lot, don't get caught up in the old SQL versus no SQL debate. Most modern databases can scale well and can maintain data integrity. And so the real question isn't SQL versus no SQL, it's how does your app need to read and write data? And then you should choose the option that makes those common operations fast and simple for your use case. For your cache, you can think of this like your system's short-term memory. And so caches, Redis being a popular example, they store frequently accessed data so that you don't have to keep hitting your database. Now, they're way faster. Um, but they do come with their own challenges, mainly around keeping data fresh. And so you need to decide, for example, how long information stays valid, when do you kick it out of the cache? The main thing to remember when you're introducing caches is that they're going to make your system lightning fast for repeated requests, but managing them adds some additional complexity to your design that you're going to want to be aware of. Message queues are how different parts of your system can talk to each other without having to wait around. And so instead of making direct calls, one service can drop a message into a queue. Popular ones are like Kafka, RabbitMQ, maybe SQS. And then another service can pick it up and process it when it's ready. And so, you can think of this like texting instead of calling. You don't need both sides available at the same time. It can happen asynchronously. Now, this helps your system handle traffic spikes and it keeps things running, particularly if one service were to crash, for example. But the main challenges, making sure that messages actually get delivered in the first place. And so, sometimes they get delivered once, sometimes potentially they get delivered multiple times, and you're going to need strategies in order to handle this. You can think of a load balancer as the traffic control for your system. And so load balancers take incoming requests and they direct them to different servers so that no single machine gets overwhelmed. So, this server box here, typically will horizontally scale it, meaning we'll need more than just one computer, we'll need multiple servers, and then a load balancer is going to be determining when a new request comes in, which of those servers it should route that request to. That's simple. Your database is designed for organized, structured data, like user accounts or product information. It's not designed for storing large files, things like images or videos. And so, trying to cram those things into your database is like forcing a square peg into a round hole, it's going to bloat your database and it's going to slow down all of your queries and make backups a nightmare. And so that's why services like blob storage services, S3 being a popular example, exist. They're specifically built to handle these types of unstructured data. This is typically media, large text files, etc. And they can host them at a much cheaper cost. And so always keep your structured data in your database and you keep your unstructured data in your blob storage. Your CDN, or your content delivery network, um, it's just a cache. The CDN confuses a lot of people, but it's just a cache, uh, and it serves as your global distribution system. And so you can place your content closer to users around the world. So popular CDNs are like CloudFlare, uh, is is one, and they can store the copies of the images and the videos and other static files, often times that you're hosting in your blob storage, but they're going to store them closer to the user. And so it's going to make it a lot faster for users to download these resources because they don't have to go all the way to, for example, America, if they're in India, they can just pull in these images and files directly from a CDN server in their native country. Okay, finally, the most important part. So, if you're thinking that everything that I just talked about was not foreign to you, then you are already ready to start working through the problems, even if you weren't an expert on everything that we just described. For anything that was maybe less clear, I've added a bunch of links below, as you know, and you can go either watch the videos or read the written resources in order to help close that gap for you. But in reality, most of your learning is going to come from working through core problems. And so I recommend that you work through these problems that you see on the screen here in this order, starting with Bitly, then Dropbox, Ticketmaster, and then all the way around until you end with post search. This is 10 problems here and they cover the overwhelming majority of concepts that you're going to see in a system design interview. And so with each, with each one of these problems, excuse me, you're going to be introduced to techniques and patterns that are going to continue to reappear in problems later on in this list, which is going to help reaffirm these concepts to you. Now, Stephen and I have written detailed breakdowns and recorded videos for each of these 10 problems, as well as over 15 others. And so you have something to guide you throughout this journey. If for Bitly and Dropbox and maybe even Ticketmaster, you can start by just passively consuming the video. I think that's reasonable. But after those three, the key and this is so, so, so, so important, the key is to try it yourself. And so open an online whiteboard, start a timer and work through the problem. At the end, you're going to know exactly where you were confused. These are what we call your known unknowns. And so you can open up Google, you can open up ChatGPT and you can start searching and filling in those blanks that you have in your understanding. And then and only then should you fire up YouTube uh or open the website and watch the video or read the breakdown. And this is going to show you then all of the unknown unknowns, or the things that you didn't even know you were missing. And then rinse and repeat the cycle through all 10 of these questions, and I promise you that after doing so, you are going to have a really solid understanding of system design concepts and feel really comfortable going into your interview. Now, if you happen to be a Hello Interview premium user, then we've made this iterative cycle really easy for you and hopefully kind of fun. So for each of these 25 problems, you can open up what we call guided practice. And you can work through problems in order in the delivery framework that we just showed. And then in each, for example, answering this deep dive question, we're going to analyze your whiteboard, as well as whatever your text response is, and then give you inline feedback to teach you concepts and help you improve as you go. So, try guided practice, Ticketmaster's actually free to everybody. But for premium users, this is probably even a better way to handle that practice iteration than opening up just a raw whiteboard yourself.
[21:42]So there you have it, folks, that is how I would prepare for a system design interview today. You have all the links below, go through them, especially in the concepts that are less clear to you and make sure that you're practicing. The only last thing that I would add, of course, is that a system design interview is also about presentation. So make sure that you are actually audibly practicing, ideally with somebody else. This could be friends, colleagues, co-workers, peer mock interviews. We at Hello Interview also have professional mock interviews where you can interview with an interviewer from your target company. So for example, an interviewer who's actively an interviewer at Meta. Um, consider that, but I hope that this was useful to you. Feel free to leave any comments, questions, I'll try to get to those. And I'll see you guys again soon. Good luck with your interviews. Take care.
