 Hello everybody, my name is Bilal Siddiqui. I am a technical program manager at Metta. I've been here with Metta for a couple of years. Before that, I have spent some time at Amazon, Compass, some of their big tech companies in the past. We're going to discuss a little bit of all the material that you're going to see today is my experience from previous companies and my experience here at Metta, and some of my students at Amazon on how to actually handle the design interviews. If you see the title of these things, I use the word multi-verse of design interviews. The reason I use that word, if you look at the multi-verse theory, every choice you make opens a brand new universe, and it's very true for design interviews as well. As an interviewer, as an interviewee, you have power how this design interview would go. There's a lot of confusion around it, how it's going to work just to clarify first of all, this is not official Metta or guidance towards Metta interview. It's more about what I have learned in the past about the design interviews and this is how I want to share this with the community. So design interviews are not as serious as they are at this point. So this is why the multi-verse, how many universes can you tap in one design interview? So first question that comes to everybody's mind is, why do companies have system or product design interviews? It's not that as a technical program manager or product manager, you're going to come in and you're going to start designing system and you're suddenly doing the solution design. There are qualified people who do that in every company, solutions architect, engineers, a lot of different role to actually do this for living. But as a technical program manager or technical product manager, it is very important for you to be part of that discussion. It is very important for you to add value to that discussion, not that you're going to design it, but being able to take part, being able to support the community, being able to ask questions about why a certain design, why a certain choice is a key to success for any TPM that is in the industry, especially in tech and also most of the non-tech companies. As a design interview, in the design interview, you want to see can you take a problem or a requirement and convert into a plausible solution that can be achieved? Not that it has to be perfect, not that it has to be super deep or super wide, but do you have that capacity to be part of those discussions? Can you also understand both the product side of it of a problem and the technical aspects of the problem? Can you be part of both the discussions? Are you heavy in one side or are you heavy in the other side? How are you going to work with the product folks? How are you going to work with the technical folks? The depth and breadth of your experience, how much have you done in the past? And would you be able to take part in engineering discussion? Because a lot of tech companies, a lot of big companies today, even the startups are very engineering heavy. And how do you gain trust of engineering organization is by going in there, ask valid question, be part of those design discussions. So the reason for doing those design interviews is to see your capacity and capability of being there, being part of engineering discussions, being part of product discussions, and bring value to those. So that's why companies do design interviews. Now, there's a lot of those things that I just talked about. It's very difficult to cover everything in 45 minutes or an hour or even in two hours in certain cases. So what I see most of the time, candidates focus on one part too much and not enough on the other part. And that's where the gaps come into the interview. What I'm trying to do here and from my own understanding, when I look at the design interview, I want to see three different areas where I want candidates to focus. So what are the main components of that design and if you're those three areas that I look into as an interviewer? First of all, product sense. It's very, very important for any product that you're developing is do you have a sense of what we're talking about? What problem are we solving? And how are we solving that problem with the product resolution? Usually you're giving a very ambiguous problem or very ambiguous statement and you have to find out what we are trying to do and what are the plausible possible solutions to that problem. Somebody can come and say, hey, can you, my kid has a problem eating his own lunch and he's always sharing his lunch with somebody. I want to build a system where kids can share lunch. This can turn into several different solutions. Do you understand what the solution is? Do you understand what the problem you're asking, who you are solving it for? So that product sense is very important. Second part is once you understand what the product sense is, what is being asked, what you're going to build, it's, and you define it clearly. I'm going to go into the details of that further down. You talk about the success matter. This is very important. How would you measure success of the product that you're going to build and also how are you going to measure the success of a technical solution? There are two different part of it, the business side of it and the operational or the technical side of it. Do you know how to measure success of the business product or the business solution that you are putting in there? If you are building an order management system, the success is how many orders, how many customers, how many products? Do you understand those and can you come up with something on the fly and ask questions? And then comes the technical side of it. Can you look into, can you figure out what are the technical success of the project, for example, how quickly can I pass an order and what is the response system? And there could be a lot of different areas depending on what product you're building. So success metrics is very important. And third thing comes in technical solution. And this is where the most interesting part is, if you don't understand the first two, the product sense and the success metrics, your technical solution is not going to be according to what you've been talking about. None of these areas are less or more important than each other. In an ideal interview, you would probably spend, I would say 30, 35% of time on product sense and then spend 10, 20% maybe more on success and less of them as technical solution. I have seen folks really jumping too quickly into technical solutions, which is not the recipe of success. Without understanding product, having product sense, without understanding your customer, without understanding your success metrics, without understanding how, what is a technical success look like, your technical solution is not going to be adequate for what you are building. So having technical components, how they work together, it's very important to know how many things you know, but it's more important to know how it works with your product and with your metrics. So spend time on all these three areas, define your product sense clearly, write it down, define your success metrics. You may not have exact metrics, but okay, I'm going to count the orders or I'm going to count the number of people using it, vote from business and technically clearly define them separately and then jump into technical solutions. So that's how the overall interview would look like and most of the time in most of the roles in most of the companies. Now let's talk about a little bit about product sense, how you build on product sense. Product sense have four or five different things that you can cover. There could be more, but the ones that I personally think are the good one is first of all, the landscape. The landscape of the problem you're solving. Can you clearly identify or write down what the landscape is for this whole product thing? Can you build in hypothetical scenario? Can you write down use cases of where this product will be used? Can you list the use cases? It's very important to understand use cases and not only for product, also for your technical solution and I'm going to go into the detail as well, but what are the three or four or five main use cases that you are creating a solution for? That's very important. Second, what's the objective? You have a use case you want to select, but what are you going to get out of it? Now that you know what you're building it, but what is the reason for doing it? What are you going to achieve out of it? What is the impact that you're going to create on your customers or the people who use your product? What is the objective? What makes you think about building this product? What brings you to the product? What is that you want to achieve with that product? Clearly define that. Then we're talking about, this is very important, features. What features, list of features you can have in the product and this is very interesting one. Spend time on features, list as many features as you can list. Don't worry about the scope at this point because scoping is part of design interview as well, and if you list five, six, seven, eight, 10, 20 features, that's fine. We're not going to build for all of this, but actually you know where the possible domain is and how big it can get, and this would also help you control the scope of your own product and of your design interview. So in an ideal world, I would list as many features I can think in a reasonable time. If I'm building order management, there's customers, there's orders, there are products, buy a product, change in order, shipping, payment, list everything that you can, and have an extensive list of feature to talk about what you're going to build in your feature, in your product. This is very, very critical to have a clear understanding of your landscape, your objective, and then list of features that your product can offer. You're not going to build for all of them, but you're going to prioritize those features. From there comes the concept of MVP. If I have 20 features listed in there, what are the two, three, four basic or most important feature that I want? I have to have for a workable product. So prioritize your feature. Once you have 20 features, these are the five I'm the built for. These are the five that are very critical to release the first version of the product. This will help you scope your technical solution. It will help you scope your metrics. It will help you scope the whole design interview. So I have, I know the landscape, I haven't understand the objective. I have list of features, but I think these are the five features that I want to build. And it's not just random list of features that you just randomly going to pick. You're going to come and say, these are the five features and here's a justification of using each feature. For example, product page. If you're doing a order management, you have to have a product page. If there's no product, there's no order. So that's a compulsory feature, right? And then five, six, seven, eight, whatever you think are your most important feature, understand the prioritization and then also what is your decision framework? Why do you pick feature number three, four or six? Why did you not pick number two? May I didn't pick number two because maybe I can go live without this feature and then we can bring it into the next phase and the product would still be workable, may not be ideal, but it will be the first release. So think on those lines. Once you have the prioritization, you said, this is my MVP one, this is what I'm going to release, this is what I'm going to release in the second phase or third phase, whatever works for your system. At that point, then you talk about what kind of product solution I'm planning to build. Maybe I just can build a website which is accessible on desktop. Maybe I can build a mobile solution, maybe I can build a hybrid, maybe I need to build something for the watch or some other IoT device. Now that you have a landscape, you understand your customers, you have your objective, you have your features, you have your prioritization, you can think about what kind of solution we're looking into. Even at this point, you're not ready to jump into technical solution right now, but you kind of have an idea of what we're going to do. So doing all of these in a product sense, you have, I would say 10, 15 minutes, and you can see how much information this is. So it is important to spend time on this. And without this, your design is not perfect. Your product solution is not going to be educated if you don't define all of this. Once you define all of this and you have a proper prioritization and product solution, now you drive your technical solution, you don't have to wait for interview or to ask you question. And one of the key thing I want to share here is in my design interviews, those are the best interviews where I have to ask the least questions, not because the other person answered every question, but because you are asking a question, then you're making assumptions and you're justifying your decisions. That's what we want to you to see that you're able to make assumptions based on some decision framework and based on that decision framework, you can justify your assumptions and come up with all these things. That's where the product sense comes in. If you have any questions, I guess you can ask in the chat box if we have there. So once you have all this, you can see you feeling great about this. You're going in the right direction. They're about 15, 20 minutes in the interview. Next thing you talk about based on your features, you talk about the success metrics. And as I mentioned before, there are two type of success metrics that you want to talk about. The functional success metrics, which is more around your business metrics, your business success, why, how come your solution is, at what point you say your solution is successful, and then definitely the technical metrics. So the functional metrics, quantifiable measure to track, monitor, and assess success of your business. Success of your product. Completely independent most of the time, independent of how the technical solution is working. Technical solution has to work. That's one point. But even with the best technical solution, if your functional metrics, if your product is not generating orders or if it's not product or not being used by customers, your technical solution is useless. So first success metrics is functional metrics where you can justify that, yeah, this is the great product that is working. I have so many visitors, I have X number of products sold, and I'm calculating how much time people are spending on the site, depending on doing XYZ business activities. So those are functional metrics. Define those based on the product sense and the product features and all of these things that you defined earlier. They have to tie back to again, you see your decision framework is very important that why you are making certain decisions and your metrics justifies that. Then you come into operational where, how is it technically working? Are you monitoring the success through how the design components are working? And so web servers responding fast enough. Is the products coming back very quickly? Are user able to finish the order in five minutes? Most of these technical components, you can improve on technical components to improve your operational metrics. So this is very important to define at this stage that technically I want to measure, these are the functional metrics, these are the technical metrics that I'm going to measure. After all that, you probably that would say over 50% of your interview time already passed, maybe more, and now is the time to jump into technical solution. Now is the time to jump into design and the components. And again, as I said before, don't jump into design too early, jumping into design too early is not successful, you're not a recipient of success. Your design interview is based on your ability to go from product to solution, not directly to the solution, especially in case of a TPM or a product manager position. This is very important, but even with software engineers, you have to understand your product in good detail before you directly jump into the component and the solution design. Once you have that, next thing comes your technical solution design. And technical solution is again, it has a lot to do with how much you know from a technical standpoint, how many components you use, but I'm going to give you one very generic tip before I jump into technical solution, is I have seen there's a tendency of using certain technical components in every design. Everybody loves to use cache or sharding or CDN, and that's fine, but whenever you use something, make sure there's a reason and to use that specific component. Just because sharding sounds cool and makes you look technical, doesn't mean you have to use it in your design. Just because of caching, everybody's use caching, I have to use in my design and I have to make a box that says I'm going to use XYZ's AWS service for it. If it's not required by the design or by your requirement, it doesn't look good on you just to use those things because you have seen it in some video or you have read about it. So that's another very important part of technical solution. Don't use a component if it's not really required by the design. If your MVP has only 100 people using your MVP, you probably don't need caching at that point depending on how much data you have. But if you're talking about millions of people, then yeah, you can use caching in multiple places to make sure you understand that. That's one thing. Another thing I want to talk before I go into the technical solution thing is whatever component you use in a technical solution and your technical design, it be it CDN or cache or load balancing, make sure you understand use cases, multiple use cases of using that product. Just understanding one use case and then thinking about maybe I can use in design is not a good idea. When I prepare in the past for my design interviews, if I have to use load balancing or if I have to use sharding, I read six, seven, eight, nine, 10 use cases of sharding because that gives me understanding, okay, what are the places I can use? So rather than going, especially in product manager and TPM design interviews, rather than going too deep into how to implement sharding, you should rather focus on what are the 20 use cases where the sharding can be used. This will help you use this component better than knowing too deep, but not understanding the use cases. Having said that, first of all, the reason again, we already talked about this, I'm gonna skip this one to understand your ability to move from product to solution to understand the technicalities. System design, it's a very high-level architecture at this point. Again, what does it look like? Do you understand how the apps work? What are the key components that Neo needs for your design? How do they interact with each other? For example, if somebody says, oh, I'm gonna use caching and you use caching in a wrong spot in the design, it probably doesn't look that good. So we want to know that when you talk about caching, you really understand what caching is and you know the use cases of those. What are the track trade-offs? If I use caching, what happens? And if I don't use caching, then what happens? In certain cases, maybe I have to remove caching from something and add caching somewhere else. Similar thing for any other component. Do you understand that trade-offs? How do you understand your trade-offs? You understand that trade-offs if you know the technical details and the use cases of those components. So make sure you understand those. Then once you have your design, I'm not gonna talk about how to design it, but there are tons of videos, tons of material out there. You can see what kind of designs are used. Go into each design, look at their components, understand their use cases. Do you have a good understanding of what it is? And can you understand that? Can you take your design and run a edge case around it? For example, if you are in a hotel management system and two people book the same hotel, same room at the same time, how do you handle it? Do you just say no to one person and give a bad design or you have another way of maybe you can lock the database or you can create a Kafka to pick and drop messages. And there's several different ways. Think about the corner cases. Even if you don't know how to handle it right then and there, knowing that corner case puts you in success or yeah, I know how to handle this, how to, what the problems are and then we can figure out how to handle it. And alerts and monitoring is really good to know as well that in your whole technical system design, how are you going to monitor, where are you going to put the monitoring? Are you going to put the monitoring in, make sure database is up, make sure APIs are up on all those things. So understanding what are the critical points where the alerts and monitoring needs to work shows the depth of your understanding on how and how well you are going on this design interview and how much value you can add to those discussions. So that's the third component. We talked about product sense, we talked about success metrics and the technical solution. So I personally want to see three areas in design interview. You start with the product sense, you do all your features, your landscape objectives and everything. Then you jump into success metrics. You talk about functional success metrics in a little detail. Then you talk about your operational metrics, your operational technical metrics. Then you get into design, system design, into the technical solution and talk about system design, talk about trade-offs or a corner cases and all that. During all that, there will be lots of questions asked. You will be asked why you are using certain decisions in certain components. And that's all around understanding your decision framework. Why are you making decisions? Why are you putting this design here? Why are you putting this design here? And then you might get challenged as well. And that's good, that's perfectly fine. If you're challenged into some specific component, at that point, the idea is not for you to completely defend or ideas not for you to completely take a step back and say, oh, I'm not going to do it. But use your decision framework. And these are the reasons I'm using. If these reasons are not good, if there's additional reason I don't know about, have a discussion with interviewer at that point. And I personally really love it when somebody comes back and said, these are the three reasons I'm using it. Do you think there's another reason I shouldn't use it? And I'll give them the reason and see, are you capable of taking on your own design and work on it? Again, it doesn't have to scalable from the MVP. MVP, depending how you define your MVP, you can put an option to make it scalable later or you can start with the scalable. It all depends on your requirements. So that's how these three areas and work in the design interview, you can go there. For a good, what is a good design interview? When I come out of an interview, some interviews I feel great. They're like, oh, why is it good? Because we talked about objective and goal of the solution. We talked about the user base. We talked about list of requirements. We talked about the MVP. We talked about success metrics. We talked about data and API. If you maybe pick one simple process and say, this is my API, might write that. Doesn't have to be syntax perfect in syntax, but input, output is all what we are looking for. There is an architectural diagram that actually have multiple components and it works with your product solution. And then you know how to scale up and scale down. For me, that's a perfect design interview. After that, if I want to, in the end before I finish, I want to give you guys some very interesting tips on design interviews. First of all, as we talked about it, interview the interviewer. The more you ask, the more assumptions you make based on the decision framework, better it is for your interview and interviewers love that too. But I'm just understand that every time you make an assumption, you have to have a decision behind it. You cannot just make an assumption and move on with it because we will come back and ask you why you make that decision. Do not dive into early, your design interview is not based on the perfect technical design that you create. It's not based on the diagram you create. It's cover all three things that we talked about before. Your product sense, your success metrics, and then part of the technical design. You do not need to cover everything. Sometimes candidates feel the need of going all the way everything. But as you define work with your interviewer and say, hey, this is where I'm going, this is where I'm going, this is what I'm working on. And maybe the interviewer will say, okay, this is good, move on to the next or they will go deeper. So don't have to cover everything, but as long as you have your mindset, has a framework that you're following. This is my favorite one, do not dig a hole. And a lot of candidates do it. I used to do that too. There's one component or one area that I'm very passionate about. I'm gonna go into that detail into that and just kept talking about it because I'm really confident on that. Let's say sharding. I really know sharding well and I'm just gonna go so deep in sharding. I spend so much time that I have as an interviewer, I have to pull somebody out of a hole and say, yeah, let's not talk about sharding. So passion is great, but it hurts you when you are going too deep into it or you just don't get a feedback from user that from interviewer that you have to go somewhere else. Requirements, most of the time you own the requirements but you have to define and you have to have a reasoning to define those requirements. Make sure you document that. Here's my requirement and this is why I'm choosing this. Even if you don't document it, let your interviewer know that's why you think it's important. Define a small population. This is nothing new to anybody. We do it in the real life as well. We do pilots, we do A.B. testing, we do small population to release products. Do that, start with the small population. I'm gonna release it in one city or I'm gonna release it in one school or whatever your thing in and define from there what you have to do. Spend quite a time on requirements. It's again, very important to have a good design and to have a good technical design to know your requirements. You will get a lot of interruptions from the interviewers, which is a good sign. It's not a bad sign. It's a good sign in two ways. Number one, either you talked about something that interviewer needs more detail, so they're gonna ask you, that's great. Or you're talking about something which is not important for interviewer, so they're gonna interrupt you as well. So which is also good because now you can spend time on what interviewer is looking for. So interruptions are good. When it comes from interviewer, don't get, I see people sometimes get discouraged that I'm having too many interruptions, but that's for your own good. That's really helpful for you to drive into the right direction. And this is again, very important. I talked about this before. Only use a component in your design if you really know it well. Just because before the design interview, you read about sharding, you're gonna use it. It's not a good idea. Interviewers have been doing it very often and they can go and figure it out that whether you know this tech or not. So just to mention Kafka and moving on, probably not a good idea unless you know the deep down details of how you can use messaging in your design. And tied to this, any technical component you use, make sure you can justify the use case in that design. Don't use it because it's just cool or don't use it just because everybody uses it. Make sure you have a use case or for that specific components. Design interviews require study, experience, and practice. It's not something that you can just watch five YouTube videos or read a few books and do a good design interview. When I say study, study your technical components, study the use cases, not just one or two design videos. For every component, you should see in a video which has six, seven, eight, 20 design components. Go through the use cases of all those components. It will help you a lot. Practice, try to design it yourself. You have a framework that you have to do the product that extends the metrics and the technical design. Pick up a random question and interview yourself. Record a video of how you're gonna do it. And that's practice will also, I mean, experience is very important in doing it in the industry, but if you have not done it in the industry, you can still gain experience by trying to design and then match your designs with the original industry design. There are tons of resources available. So a lot of study, a lot of experience, a lot of practice. As far as study is concerned, I cannot emphasize enough that understand the use cases of anything you use in your design. With that, I think I'm going to wrap up here. There's a lot of information in a very short time. Go back, see it again. If there are any questions, if you have anything, feel free to reach out to me on LinkedIn or the product school. And thank you very much everybody's time, special thanks to Product School giving me opportunity to come talk about the subject that I am very passionate about and whoever has designed the interviews coming forward. Good luck, guys. Thank you.