how to deliver a comprehensive answer. Before we had have learned about this six-step structure and this is the foundation but acing the interview you need more than knowing the theory, your systems, good structure. On top you need a top-notch delivery and let me illustrate this with an example. And let me illustrate this with an example. Here you see two YouTube videos. The one on the left-hand side is a recording of the famous MIT 6033 computer systems engineering class. This is delivered by world-class computer scientists and researchers. It's basically MIT education for free. Has been uploaded 14 years ago and only 160,000 people ever watched it. And on the right hand side you have a TED talk held by Mark Roberts. He's a YouTuber, former NASA engineer. And it got just in four years, 15 million views. And it's about how to trick your brain into learning about, yeah, how to trick your brain into learning by using the Super Mario effect. And you think, you get my point here. It's really about delivery. And the beautiful thing about the system design interview, you don't have to bump up your presentation skills to test level, definitely not. And you already have everything you need to deliver a comprehensive answer. Let me explain that. To put this together, you need to know which kind of questions to come up, you know how to get there, how to structure your answer. We talked about that. How to adjust to different interviewers. Yes, we can take that. And while this is an assumption, in the process of you preparing, you're going to learn what's your strengths and weaknesses. And with all that knowledge, you have everything you need to actually make sure your delivery is outstanding. And to achieve that, there's actually three things you should do. Be smart, strategic, and control the interview flow. And I just want to run you through the six steps again, this time with a focus on delivery. In requirements engineering, this is the moment when you should make up your mind about what kind of interviewer you're working with. Once that's clear, adjust your delivery based on that. You select the support features because you can control them. Everything besides the core feature is in your control. And you choose the ones you're most confident with, the ones that you practice most, which still make sense in the context of the system. If you get a high-level generic system, it's so large that you can almost pick any support feature. And obviously, you need to confirm with your interviewer, but you have a lot of freedom. And then take very easy to work with numbers describing the scale of the system. And this will be key for your capacity estimation in the next step. What you should avoid really is to let the control slip to the interviewer. You really want to present yourself as a capable tech lead as well as you want to make sure you can make the calls on the features and the numbers. And the capacity estimation, well, you profit a lot from you being able to make the choice on numbers you're going to work with. And then you should use shorthands for quick delivery of the required estimations, because otherwise you're spending a lot of time on this single step here. With shorthands and numbers defined by yourself, you have a lot of free mental capacity to actually explain the interviewer what you're doing. So this is very important, this step here, so they're not being left in doubt why you're using shorthands, for example, and what this actually means. And no matter how confident you feel about your estimations here, always double-check and make sure the calculations are simple and correct because you want to be sure the interviewer doesn't think you might lack attention to detail. It's like a super important skill they're looking for. To avoid sabotaging yourself. Yeah, don't even try to get accurate estimates for the real world system. Plausibility is not really a matter here. It's mostly about you being able to show them the process of estimating and that you're capable of doing that. A data model, that's what we're going to look at next. And always include SQL and NoSQL databases in your design. This allows you to show your knowledge of the different capabilities of those database types and the differences. And this is something very easy to practice. And then you can just roll it out and show that you own that topic. Also, you previously created storage capacity numbers here in your reasoning. It always makes you just look smart if you base your decision on data. And when you learn support features, also learn the underlying data structure with them because this allows you to be really quick here and again leaves enough mental capacity to very neatly explain what you're doing and why you're doing it. What you really should avoid is creating to very neatly explain what you're doing and why you're doing it. What you really should avoid is creating a perfectly normalized data schema for the whole system because just a portion is going to end up in an SQL database. The API design is very similar, actually, to the data model. Your delivery will be most convincing when you already have a good idea how the support features are going to look like. So you can also just sketch out the APIs for those very easily and you can focus on the core feature. What hurts your delivery is if you show a lack of control when it comes to scoping. So really just focus on two to three, maybe four endpoints. System design, the most important one, really. And here you can bump your delivery to the next level using just a couple of best practices. For example, always start designing the core features first before adding any support features. They should wait for a second iteration. And that way you reduce the risk of running out of time without even having completed the critical features first. out of time without even having completed the critical features first. And if we take the Netflix example, again, first you would model how you can upload data and then how to stream it out again before you even bother to add a recommendation engine to it, full text search, whatever bells and whistles would make the picture complete. Additionally, support features are also mostly simple on a high level diagram, so you can worst case add them last minute. Always aim for end to end solution. And if you find out that it's not an ideal solution, which is very likely to happen because, well, we all know time is limited, defer optimizing to the design discussion. Yeah. What you should avoid really is drawing your diagram in silence. It's really important that you explain what you're doing. And if you spot bottlenecks or things that are not optimized, point them out, but defer them to the design discussion. Don't aim for perfection. I mentioned that before. And yeah, the real risk is also not to include any of the findings from the previous steps. It's really well perceived if you can draw your diagram and relate back to the APIs you created before, to the scale, and obviously to the requirements you defined at the very first step. And in an engaging delivery, it's also like a very natural process to get from the system design step into the discussion. And when you discuss optimization options, it's really critical to lay out multiple options, how it could be optimized, then show the trade-offs between the different options, and then very important to make the call. Because you're the tech lead, you're not an advisor or something. You really need to make the call. Another really smart strategic move here would be to point out bottlenecks or topics you're very familiar with and you're confident, and then really start a deep dive discussion on that topic. It's killing time in the end because it's obviously really good if you can spend time on topics you enjoy, you feel natural in, and, yeah, do that instead of not being lured somewhere where you're not feeling so comfortable with. Yeah, talking about not feeling comfortable, really avoid name-dropping because sometimes people do that. They hear about a technology, then come up in the interview, just say, oh, we could use Redis for this. And then once the interviewer asks one question about Redis, they don't have an answer anymore. That is something you should avoid. Really just state technologies you know enough about. It's a rule of thumb to at least answer one additional question.