The next one is actually about how to structure a comprehensive answer. By now, you have good guidelines on how to determine which are the most likely questions to come up for you. Next, we move a step forward and start talking about how to structure a comprehensive answer. For that, we're going to start by revisiting the question you'll probably get or how it looks like. How would you design X? That's all you get, and it's not much to hold on to. And, yeah, Wesley, again, you talked basically about what I wanted to talk about here in my next chapter because without a clear idea and a clear structure in mind, it's really difficult to almost be impossible actually to deliver a satisfying answer within 45 minutes. And what you can not foresee is the actual system you get. You can make educated guesses, but you're not going to be sure which one you get. But what you can definitely practice and be sure about is to have a systematic approach in place to answer the question you get. And therefore, I suggest actually to break down the answer into these six very common steps. And there we have requirements engineering capacity estimation data modeling api design system design and the design discussion and they're all building up on each other so let's look at each of them in detail this one is about requirement engineering. And in this first step, you need to clarify system requirements, the scale of the system, and the feature scope for the interview. And you should basically get a clear understanding in this step of the functional requirements, the non-functional requirements, the scale of the system, and that means you should capture a couple of numbers outlining the amount of users you need to design for. So your system needs to be able to handle that amount of users. Biggest opportunity here is to align with your interviewer and make sure you can include features you want to have in there. And you want to have those in there you know like best biggest threat you promise to design much more than you can actually deliver in the given time frame let's go to the next step and here we have capacity estimation and here you are actually expected to estimate the required capacity to handle the scale of that system. Meaning what's required here is to actually estimate throughput, bandwidth, and storage. Biggest opportunity is that you estimate the values, and you can use those values later to justify your design decisions. Biggest threat is to lose time and become really nervous because something goes wrong. But once completed, you actually would move on to the next step, which is the data model. And the idea behind this is to structure the data that is supposed to support the features you defined in the requirements engineering step. And you can consider this step to be complete once you have a data model, which should not be perfect data schema, because you don't have the time for that. And you should have a selection of databases that favors the requirements you defined before. And you should have a good starting point to discuss how you would scale SQL databases. Biggest opportunity here is that you gain a clear understanding of the data flow and the ideal selection of databases. Biggest threat is to spend way too much time on the schema. Once that one is complete, we get to the API design. And API design is about defining how a system would expose its features. It's basically the interface the front-end application would use. And your deliverables here are typically the central two to three day endpoints. You also have to define input and output parameters. And sometimes it also makes sense to define some like full URLs, for example, would be for specific search queries. Biggest opportunity is to show your ability to plan a system end to end. Biggest threat, you lose yourself in too much detail and again you get lost. Time, and this is really like once you get lost you lose time which is urgently needed for the next step which is the centerpiece of each interview and this is what all the other steps before lead towards and this is the system design. Here you create the actual design diagram, and it should convey your idea, serve as a foundation for the following design discussion. Best case, you can articulate clearly your design ideas and already highlight some bottlenecks that come with this initial design. Worst case, some knowledge gaps become very obvious. And this is especially a problem if you try to hide them before. So, yeah, we get to that again later on. And the following last step actually rounds up a well-structured interview. And this is the design discussion. And it offers the opportunity to go deeper into technical details. You can discuss alternative designs and optimize the current one. The expected outcome is an improved system design. And it's also a great opportunity to show off your expertise and your ability of critical thinking and problem solving. If things go south, well, you reveal the lack of such skill. With that,