Cracking Front End System Design Interviews: Chakde System Design Series

Welcome back to the Chakde System Design series. I am Chirag Goel. In this episode, we'll be talking about how to crack front end system design interviews. Yes, we will be talking about things to consider in front end system design interviews. What are HLDs? What is LLDs? What are the tech stack discussions? What are the other performance discussion? What are the requirement discussion in terms of the functional and all functional requirements, right? Component architecture, getting into the what are the things that need to be considered in the implementation detail, right? Not limited to that, we'll be talking about what are the different type of system designs which are asked in different companies, like Flipkart have product sense, Uber have UI architecture, Google have design round, right? Microsoft has system design round. So they are the different, different things which are basically asked in different interviews. All are around the system design rounds. It's more about few things are heavy on the company specific requirement. We'll be talking about all of them. Not limited to that, we'll be talking about tools that can help you to basically crack the system design interviews. Not limited to that, we'll be also talking about mantras of cracking system design rounds. So are you ready? So let's get started. Motu Bhai's offline business was going well. Now Motu Bhai saw that his competitors started having online business as well. So Motu Bhai decided that I would make an app and website online so that my customers can order easily. So what he decided, he decided that I would set up a tech team. Now if I want to set up a tech team, Motu Bhai knew that I wanted a senior developer. He wanted a junior developer. Senior developers who know things on high level, on infra level, how a system is made, how it is scaled, its performance, security, everything. Do you know about junior developers who can work under senior developers and can develop applications, can write code, can develop features. So this was the set. So Motu Bhai heard that system design is something which is very important and on the basis of which you can easily judge a candidate. Coding skills are required but on the basis of system design, you can understand senior developers that yes, how well designed the system and how much work it has done. So what he decided, he went to his friend. He went to his friend and said, I have heard about system design, tell me a little bit about it. So he went to his friend and he told that he had heard about system design interviews. So there is a round which is called system design, there is a product sense, in the product sense, your product, tech, UX, user experience, user interface, everything comes. In architecture, basically, your many things come like, your functional requirement, tech scoping, component designing, high level and low level designing, everything comes. In machine coding, mostly in low level designing, some things develop. Now Motu Bhai is confused, that I was only for the system design. Now there is a product sense, system design, UI, architecture, coding, machine coding, round, component design, what is this? He got confused. Did you got ever confused? Don't worry. We will be covering about what are these differentiation and what are these different companies asking about different rounds. As a system design round, we will be talking about in detail. But before covering this, let's talk about what are the things which are important in order to understand our system design round. So we will be covering about things to consider in the front end system design interviews. So couple of things. First important thing is requirement gathering. What are the things that you wanted to have in your application? In terms of two perspective, like functional requirement, non-functional requirement. Second is the scoping, prioritization. You can't build everything in the first shot. So you have to prioritize your MVP, basically. So then you basically make a tech choices. Which libraries, which frameworks, which technologies, which languages you will use in order to develop the application. Then you have a competent architecture. That is a big architecture that will drill down many requirements and see how it will look in terms of front end. Then it's more about how communication will be between them. How the APIs will communicate with the backend of the backend. How they will communicate with the protocol. Or their implementation details. So let's dive into each one of them. Most of the time, system design questions are very open-ended. Like build a grocery application like Flipkart, and big basket. It can be grofer's. Or it can be applications like you have to build a chatbot. Like web.whatsapp.com or WhatsApp, basically, similar kind of thing. You can build the Instagram. These are mostly the open-ended system design questions which are asked. So what you should start with requirements. Requirements are the same important. So when we say requirement, they are two kind of requirements. Those are very important and we should start with them. First requirement is functional requirement. So let's make it. Okay. So first, always start with the functional requirement. The second thing that you should start with non-functional requirement. Okay. So basically you have non-functional requirement. When we say functional requirement, so you have to basically first discuss with your interviewer what sort of area he wanted you to cover. Either that is demand side or supply side. Right. So when we say demand side or supply side, it's like, do you want to dive me into the B2B or B2C side of thing, which are very, very important. Right. So always discuss with your interviewer what sort of expectation he's having. Right. Second thing, start with high level and dive into the feature. When we say high level, you always start with a module level thinking. Right. And you dive into your feature level thinking. Okay. What it meant by, let's discuss. When we say module level, right. Any of the applications that are built, so that has some critical modules like you have user management, right. You have other things like help and support. Help and support. Right. You have other things like your payment pricing related stuff. Maybe payment gateway. You can say, right. You have your pricing and subscription related stuff. Pricing and subscription. Right. There are other sort of thing, which are also very important when you basically talk about any e-commerce application. If you are building like product listing page. And sort of thing. Maybe taking example, there can be card page obviously, where you basically add all the items. And finally you see, these are the item I wanted to basically purchase and finally you click on. Yes, this is the payment gateway. I wanted to go for and other things. It can be like your accounts management. We have discussed about the functional requirement from the product, from the user perspective, what are the features and functionality we wanted to deliver to the end user. Right. We wanted to have in our application. Now it's time for the non-functional requirement, which is actually going to boost your performance, the out of box features. And you can see the user experiences to the users in your application. Now, couple of things that we wanted to check. Either we are building for the mobile or we are building for the desktop. Right. Those expectation need to be set. Are we looking for a responsive application or the adaptive? Adaptive is like you wanted to build for a specific resolution or the breakpoint and responsive is like your application is going to work for all the device sizes. Right. Yeah. Then the next thing is what sort of internet speed and what sort of users, where the user will be coming from. Right. Which is the internet speed, localization, location basically, location in terms of in order to think in terms of the CDN, how fast you can deliver stuff. And obviously, what sort of devices they are going to use like they are having a tablet or they are going to use in the mobile. Those things are very important. Right. In terms of the accessibility, like are we also going to support people who have some, some disability sort of stuff? Right. So we have covered all those things in more detail in the previous recording that of the chakde system design. You can check out in the comment that link is shared. And we also wanted to discuss about like asset optimization. Are we thinking about the how well we are going to deliver our assets in terms of the CSS, JS, images, right? We have to think and discuss and how we are going to monitor our performance. So when we say monitor our performance, it's more about are we thinking about like FCP, are we thinking about LCP, are we thinking about TTI, right? In short, we can say are we thinking about web vitals or not, right? Which are very important. I can keep this together over here. So those things are very important when we, when we discuss about the performance, are we thinking about the client side rendering or the server side rendering? Those discussions are important. Are we even thinking about authentication and authorization, role based access of your web pages, your features functionality, thinking about the security like the cross-site scripting like SAP content security policy. So many things. Are we thinking about caching of caching of our resources, caching of the API responses, caching, wherever applicable, right? Are we thinking about the offline support or not? Those are important things to basically discuss in the interview. Are we even thinking about logging and monitoring, right? So those things are basically we should discuss in more detail and let quickly move this up so that we can add couple of more points. So we talked about logging and monitoring, right? So there are other things that need to be discussed. Like are we going to support the A-B testing in terms of the, are we going to provide the feature flag so that we can roll out things on the faster basis? We should have the testing like unit testing and the end to end testing. We thinking about the internationalization, right? Or say suppose localization. Are we even thinking about versioning of your application, right? So is that the requirement? The progressive web app, are we going to build, right? Or we are, are we thinking about CI CD pipeline, right? How, how are applications are going to be built? How are application is going to be served to the end customers? How it is going to be on the production, right? Are we thinking about some pipelines that we can have in our application to provide the better checks, right? It can be your code quality check. It can be running your automation shoot in terms of your testing. All sort of things can be discussed over here. When we have a huge list in terms of the functional and non-functional requirement, it's time to basically scope it, prioritize it. Because in 40 minute or 45 minute in one hour, we can't discuss everything that is there on the board, right? So we have to prioritize and it's time to prioritize the stuff. Once we have list of this requirement, we should not become Pushpa, right? We will tell the same thing that we have read, right? It's good to ask the interviewer like what he is actually looking for. Because different people have different expectations and he might be looking for some specific thing to be covered in the interview, right? So let's not become Pushpa and say, we will tell the same thing that we have read. Although we all have done this anytime in past, either in college or in our interviews. But let's not do in the system design round because that will become a problem, create a problem for you. Okay, now talking about the functional requirement. First, as we said, we have to make it clear either that is the demand side or the supply side. Most of the time, the interviewer can say, I want from the demand side. Like I want to see the B2C. Like you actually, where your customers are basically making a purchase, they wanted to dive into that. Then in terms of like freezing the modules, say suppose the requirement from the interviewer is, I wanted to discuss more on the product listing and the cart page. It can be product listing and he wanted to talk about the cart page. He want you to dive into that. Now, it's time to dive into the features on these basically modules. So try to dive as much as possible and then like discuss about what are the critical features that you wanted to like freeze on so that you upcoming time that you have in the interview, you can focus on that like features. Obviously, one thing is you wanted to have a search where you can search the product what you are looking for the listing of product, which is very important. Then capabilities like there should be a product detail where user can see the details about the product. There can be review section also where you can see the feedback sort of stuff of the product. There can be other critical things like there should be capability to add items to cart or whistlist. Whatever you are looking for, you can basically discuss about whistlist may not be the primary thing, but it's always good to double check with the interviewer. Now, the second is the cart list. Like you wanted to see all the items that are added into the cart in this one place, where there can be other more capabilities which are very critical like other capabilities. One is you wanted to see the price breakup, which is important. So how what are the taxes applied? What are the discounts that you have received and all sort of thing and definitely feature capability to add or remove basically products, which are also important thing to have in the cart page. Now, you have you have freeze. Do you have a scope certain things that you wanted to drill in more discuss about instead of talking about all sort of module that you have in mind because now the scope is freeze. You can dive into in more detail. It's time to go into the non-functional requirement. So in terms of non-functional requirement, again, you check with your interviewer what sort of expectation he's having. He might say, let's go for the for the desktop application. Let's focus on the responsive design. I want to build it once and it can be used at the multiple resolutions wanted to discuss about the accessibility as well. And he's actually looking for the asset optimization and the performance of stuff. Right. So it's okay. Like discuss about those things he wanted to discuss about as we said performance as well. What are the other things that interviewer might be interested in? Maybe he wanted to discuss in terms of the CSR and this is a client-side rendering in the server-side rendering and the most popular stuff related to the caching, right? How you are going to basically cache your application or all sort of thing he might be interested in. So with this, we have basically scoped our requirement and now it's time to dive more deeper into that. So our functional non-functional requirement is scoping is ready and we are we are basically done with that. And we will be diving into the tech choices. First thing is the library and the frameworks basically you are going to use in order to build the application. right Which is very important to discuss about. It can be like you may be talking about I wanted to build this feature of the functionality or this application basically on React, right? Because you might have worked upon that works for most of the people who have just started their career for a couple of years of experience and you can just showcase that similar kind of functionality and feature I worked in my previous organization in the requirement product basically and those work basically with the React or whatever library that you have worked with. Now for senior people, it doesn't work most of the time. Reason is like you should know what are the options which are present in the market and what is the best right of choice basically as per the requirement that you have. It shouldn't be like I have worked on this and I want that's why I wanted to use this particular library of the framework. It should be always combination of multiple things. What is the best suit basically for the requirement and what is the best fit available in the market and what are the skillset your team has right which is also a key factor in order to build things on a faster basis and to provide the best possible solution as soon as possible right. Second thing is your state management. There are so many like options which are available. It can be if you are using React, it can be context, Redux sort of thing right. There are other sort of state management that you wanted to do. Maybe your database management on the client using the index DB anything that you wanted to do as per the requirement that you have discuss about those choices available. The folder structure is also important. So when we say folder structure, it's more about you want to follow the duck model like how you wanted to have the different layers in your application, how services you wanted to create where you want to keep the common pieces right. All sort of thing need to be discussed over here. The packages is important because a couple of people wanted to have the NPM packages basically for the different module or people may wanted to have a mono repo sort of thing or the micro front end architecture right. So how you want to do basically structure your application so that these requirement can be fit and these can work for the large teams as well right. So those things can be discussed over here. Dependencies depending on what sort of requirement you are going to touch upon. You should always discuss these dependencies like these dependencies can be like you wanted to build some drag and draw functionality some some like mine chart or mine tree sort of thing application that you wanted to have. Maybe you wanted to use the canvas right you want some some like analytics to happen. So probably you wanted to have the SVG sort of stuff or you wanted to have some streaming or some gaming sort of stuff like RTC sort of stuff you wanted to have you should also discuss about the design system either you wanted to build your own design system or you wanted to latch on the existing design system like material design and design right. What sort of design system that you wanted to have so that it works for your all your applications would have similar look and feel and obviously it has consistency in terms of user experience. So those things are very important to discuss. Build tool is also key key thing that you should discuss depending on what sort of as requirement either you wanted to have a package or you basically you wanted to ship it for different use cases. You should always discuss like do you want to have the pack you want to have a roll up sort of thing right or you wanted to have parcels basically for your build it's not built it's for build tool right. So basically discuss about those things those are very important. So just freeze on that what are the tech choices you wanted to have you wanted to make before you move ahead and dive into the more granular level right. So we'll be getting into the more granular level but before that freeze on the tech choices for you are engineers for senior people. This tech choice is something which is very very critical and interview are very keen and looking into how you are making your choices at the different layers right. It's time to discuss for the component architecture when we say component architecture we have to give dive into the feature of the functionality that interviewer is looking into in terms of how we are going to construct and break that problem statement right. So couple of things which are very important like interviewer is saying let's let's dive into product listing right. When we say product listing they are couple of things that we should always discuss about first thing is how a component hierarchy is going to look like right. So when we say component hierarchy so it's it's quite similar to like how we wanted to basically have that hierarchy maybe something like let me quickly see how can we get that hierarchy. Okay something like this. So you have your main component with that main component you are having different other small small component it can be you are having a search along with that search you are having other capabilities in terms of the search different sort of search you are providing you have a listing basically in listing you have a product each product may be having a catalog or showcase thing that can have multiple other small small component like rating component your button component right. Your your image component you are certain different different component that you wanted to have. So try to dive into the component hierarchy we will be diving and we will be seeing this example in the upcoming sessions where we will be doing a mock interview on the different HLD and the LLD that are basically asking the interview don't worry about that it's more about just wanted to give you a high level stuff how this component hierarchy will look like. So try to use we will be talking about some tool that is going to help you basically build this hierarchy as well on a very quick and faster way. So this is this with this interviewer wanted to understand how you can break a big problem which is given and how granular basically you can think in terms of its implementation detail which is very important now. Second thing is very important is the routing routing in terms of how you can visualize your application how you are maintaining your state in terms of the route what are the things that you are considering why managing and building your application like you have a detailed page when you're opening something and some pop-ups basically comes up. Are you thinking about persisting those things in a route so that it can be shareable right. How you are going to share your data between the different routes those are very important. So data sharing is also very critical thing that you can discuss in the component architecture where how different component are going to communicate with each other how different routes are going to access the data at different layer how you are basically utilizing the cache when you are doing data sharing all those stuff basically can be discussed in the component level architecture. This is something which is very important and most important part of this is like how you are breaking down your components or how you are breaking down your big problem into the component level so that this can be reused at multiple places and how you are segregating your business logic with your you can say abstract or dumb component all together those kind of thing are basically checked inside this component architecture structure right. So now once you are done with the component architecture it's time to dive deeper into the data APIs protocols and the internal implementation of the component that you have just discussed about. So let's let's talk about that first thing first protocols. When we talk about protocol. What are the things that we should talk about like either we are going to use the rest or we are going to basically use the graphical endpoint right. So are we going to use SSE service and event or we are going to have some rPF sort of thing right. So these are the different protocols that we have we will be discussing about these in upcoming sessions although some parts we have already covered but we will be coming don't worry about that. So in terms of either we are going to have the JSON sort of response or we are going to have the protocol buffer like people may not be aware of the protocol buffer. Most of the times the developers have worked on the JSON sort of don't worry we will be discussing in more detail. It's more about you should have some idea what are these protocols all about and like what are these different type of response type as well. Right. So with this basically once we are discussed about finalize what are the protocol that we are going to use as per the requirement the next thing that need to be discussed is about the implementation detail. When we say implementation detail it's more about say suppose as interviewer said we wanted to discuss about the product list right in product list the key functionalities are related to your pagination right. You can say pagination or the infinite scroll. When we talk about infinite scroll it can be using throttling or it can be using international intersection observer. You should talk about those things in more detail so that it gives a better understanding to the interviewer that you have worked upon it and you know how things can be handled in such scenarios. You talked about the debouncing when you have the search like capability obviously the throttling related so that you understand what are what are these and you also discuss about the about controllers so that you understand you let them understand or the interviewer understand you understand about the cancellations of the API right you understand about the inconsistency that can happen because the API response of the previous query may come afterward and you might show the irrelevant information or the old information to the user right. So discuss about those things in more detail when you are discussing about the implementation detail and then chipping into the API's like when we say API's it's it's more about what are the API's that you need in order to build this application. Like product listing add to cart sort of capabilities you wanted to have what are the API's that you need like first API which I can think of is you want to get product list right you want the list of all the product given some parameter those parameters something that we'll be discussing but like list down all the API's that you need second is you need the product details right so for with respect to a particular product I wanted to get into the details and I wanted to see the details of that right there should be capability to add product to list right so there can be other requirements like remove product from list right which is your cart or you can say make it cart which is more better terminology over here right. So these are say suppose the API's that you are looking for you can come up with other sort of API's that you think which are required in order to build the application the features which you have just closed with the interviewer. Other thing is data modeling right this is very very important thing that you should discuss in more detail when we say this data modeling is data modeling is all all about that you are going to discuss what sort of like most of the time the UI at the front end the back end guides sit together in big companies in good companies basically in order to decide what sort of contract that you will be having in order to build this feature the functionality the first thing first is the URL what sort of URL that you wanted to have what sort of methods basically of these URL you will be having like you have get or post you have like delete what sort of method you will be having right update put basically and what sort of request and how the request will be sent either it is in the query parameter or you are going to pass in the body depending on either it is a get API or the post API right which is which is important apart from that let me quickly move myself okay apart from that the things which are important are your response but before that I'm just moving couple of things so that it can fit over here. Response are very important right you we discussed about the request how you wanted to have it either in the query or the body what will be the structure of that it's time for the response most of the time people discuss about what sort how the data will be passed in terms of the the actual required data that need to be consumed on the UI right but no one basically talks about how the error basically will be circulated like you talk about data in terms of this will be the array or it can be in the object form right can be any form but discussing about the errors are very important because you can think about if you are passing the right set of status code and you are passing the relevant context from the server to the client then the localization the internalization sort of thing can be taken care of and obviously certain things you don't want to reveal the exact information and sometimes you don't want to show the generic information as an error right so those things can be handled very well if you think about error passing the error in the your response in a well-structured format and have that contract with your backend team that can be standardized across right the status code are very important always saying that I will get a like 500 error for any sort of like errors that doesn't work right you should properly utilize like 4x6 5x6 and even when you have 2x6 let's utilize that in far better way where you know I just wanted acknowledgement I don't want actual data when I am updating something use a better status code in terms of the 2x6 so similarly once this data modeling is done which is very very important thing when you discuss when you have a proper contract with your your backend team the next important thing is the component like interviewer as your UI engineer interviewer is also looking into how you basically implement a component and how generic component you are building so that there can be multiple consumers they can utilize this as per their requirement right so how you are managing your state what are the props basically you are thinking in order to expose for that component so that it can be reused what sort of event handling that you are you are thinking about in order to consume right so what what capabilities you wanted to provide to your consumers so that they can handle right so customer what sort of customization you are going to provide an expose to the your consumers in terms of the teaming in terms of the layouting right so can they control the colors they can control the theme of your component that you have built so that they are more and more user and more generic implementation that you can think of then definitely the usability is definitely that is unsaid thing which is required in any of the component that you are building right so this discuss about that keep that in mind when when you are like designing your component then obviously the data source is something that need to be discussed when we say data source who is actually taking care of making the API call do you want to keep this logic inside the component or you wanted to give this capability to the consumer so that more and more consumer can decide how they wanted to face the data right it's more about you are passing the relevant requirement which the user have input in the component so that your business logic can be segregated and that can be abstracted from this component so those kind of thing that basically you should discuss in more detail and you should come up with some API component APIs when when you are designing that right so I you can say it component or you can also say it as a component API which is required sometimes an interviewer may be looking into like let's write the code in order to like have the implementation of this so we will be discussing about what are these interviews where the HLDs basically are asked and some of the interviews where LLDs are basically low level designs are basically asked and how to basically write those low level design we will be discussing about more and more detail now we have understood the different expectations right expectations of a system design around in terms of requirement functional non functional requirement scoping tech choices component architecture right the data API protocol in the implementation now we understand this it's time to understand what are the high level design and the low level design which are generally asked in the interviews right so if the system design round is mostly evolving about the HLD right which is high level design there is no point of discussing anything which is related to the low level design because you can basically optimize the time duration which is provided in the interview in so that you can focus more in detail of the high level similarly when it is low level design there is no point of talking about the high level because that high level design may be having a different round altogether in the interviews right so it's it's important to understand what sort of like mindset of what sort of interview round that is basically that is going to help you to dive better and meet the expectation of the interviewer in far better way right so with this we we discuss about requirement scoping in the tech choices right all of these basically comes into your HLD right this this is this is basically your high level design so this is basically you called it HLD maybe I can make it right color this this is basically HLD that that mostly people call it so in this HLD basically what is being asked is like are you able to discuss about the requirement can you come up with the functional the non functional requirement are you even think about prioritizing certain things are you even think about what what should be the first MVP what should be the key functionality that you should roll out obviously people wanted to build everything but you can't build everything in the one shot right so are you able to even prioritize what are the critical things and how you can roll out your P0 P1 and P2 sort of functionalities right are you able to even think in terms of your users they are requirement are you able to think as a product manager right so those things are very important tech choices are you even able to think in terms of the senior level architect right where you can make the right set of tech choices those are basically main areas where people wanted to focus on the high level design similarly when we talk about low level design low level design is it's like people have their expectation very clear they they wanted to dive you into the more granular you can say the implementation details instead of having the high level because high depending on your role right if if you are not a senior level architect people may not ask you the high level design people may want you to basically come up with the implementation detail and implement some some piece of the application right so some of the question that you might see like build a auto complete sort of application or build a chat application or build a cart right like any of the cart product cart basically sort of thing or build a product listing or you can be asked to build a customizable form right where some configuration is given and you generate a form out of that all sort of things basically are asked in this particular round which is called LLD which is low level design and the expectation over here is sort of very clear people don't want to dive into the internal details of that it's more about they wanted to see how well you implement and how well you basically create the API the component API is or basically how well you structure your protocols or how your communication are going to be the back end in the front end right how well you are going to model your data and how well you are basically going to have component hierarchy data sharing those kind of things which are very important obviously the best practices that you are going to use in your application in order to build so to make it very clear high level is mostly asked for senior people low level design are asked for almost everyone either that is senior or the low level like not low level it's more about the people who are just starting a career or having couple of years of experience right so you should know how to develop your application but high level designs are very critical for senior developer anyone like four five year plus most of the companies have started asking this high level and very interesting I have seen many startups many companies which have started asking this high level design even for two year three year experience they are not expecting much detail but they are expecting you to basically either you are able to think in those direction or you have just done some assignments or tasks that are being like asked by the senior people so sort of expectations are high in these days in the front end it's no longer to fetch the data and just show the data on the UI how did you forget that Motu Bhai is still confused right I understand in the product sense what about people talking about different terminology like system design, product sense, U.I. architecture, machine coding, component design when we say system design most of the time companies have a requirement companies have expectation that you will be going into the requirement scoping tech choices, component architecture and the data API and the implementation whatever we have just discussed previously almost everything you have to going to cover and obviously you have to speak a lot in order to like in the short duration you have to showcase the knowledge that you are holding right so that is the expectation that companies are having in the case of product sense around like system designs are mostly asked in like Microsoft in any of the big companies people are looking for the system design right so a product sense flip card do ask the product sense and many startups have started asking the product sense where the requirements and the expectation is like whenever the system design is basically called about it's more about the combination of multiple things are you able to think in terms of the business are you able to think from a product manager or the product side of thing right are you able to think from the design perspective in terms of the user experience user interfaces are you able to think as a front end developer in terms of not just the things which are visible to you the back inside of the front end right in terms of the optimization performance non functional requirement that we discussed and obviously the back end it's not about you are going to work on the back end it's more about how if you understand the back end guys well how what are the challenges they are facing what are the ways they use in order to optimize in order to basically implement certain pieces so basically you will be able to help in chip in and you will be able to discuss in more detail when you are having a contract discussion and when you're doing some solution so that's why this whenever the system designs are basically discuss about it's a combination of everything that is listed over here right so similarly when when a product since is basically consider it's more about are you able to think from a product side right are you able to list down the requirement properly are you able to scope those things in terms of the prioritization in terms of the like scoping right are you able to come up with some basic you can say data API's and the implementation that you wanted to have the back with the back end guy right so those kind of expectation are there in the like flipkart the other startup companies that they have started asking UI architecture is again people have expectations in terms of you will be diving into the requirement may not be very depth in terms of the module but yes certain pieces because the problem statement may not be very very big or open enough right similarly scoping the items that you have just discussing the in terms of the requirement tech choices people want you to dive into the very heavy tech choices discussion in the UI architecture and obviously competent architecture in order to understand either you are able to think in terms of the usability right sort of stuff obviously the data we are in the implementation so how you are going to basically fit and how your communication are going to have with the different back end teams because there are so many teams that you will be having a discussion micro services multiple stuff there are aggregator layers how you are what are the requirements that you may be having maybe people team or heavy managing their graph to your endpoints right so how well you are basically coming up with your requirements it's not about whatever is in database i will manage it it's not going to work at a large scale obviously there are a lot of latency and unnecessary like network layer load so those things need to be kept in mind so talking about the machine coding on the component design like most of the companies generally ask this in terms of the low level design they call it low level design where either your machine coding or a company design will be first or the second round where they will be giving you a small piece of application that need to be built right when we say small piece of application as we discussed it can be similar to building a customizable form or your card right it can be implementing a search capability auto sort of complete sort of thing right it may be simple functionality where you have to come with a pixel perfect some some design it can be a form it can be a multiple screen router sort of thing that can be asked right so over here the expectation is obviously how well you are structuring your application your code in order to implement but on top of it there are almost every company mentioning what is must have right do take care of that must have don't try to basically do a super cool stuff in that small duration because that round may vary from one hour to two or sometimes it's three hours sometimes people give you as an work at home sort of stuff as well right they will give you a big problem big application that need to be built and they want to be you written back in 24 hours 48 hours sort of things are there right over here the expectations are not never that everything you will remember in terms of the function or the code everything it's more about it's okay if you forget some method you can Google it out that works right it's more about how well you basically implement are you using the best practices in order to get into the those right so in in this the just make sure what are the expectation? what is the must have you have to basically consider while implementing just take care of that certain tools can basically help you to speed up the flow diagram or the speed of the things that you wanted to have in your system design right the way you wanted to present a couple of them which are very famous so there are ways like you can open any of the like paint also you can use your your pen and basically you can draw if you are that is a physical basically system design you can use whiteboard definitely in order to draw and basically represent what you wanted to have for the high level design for low level design obviously you need a system in order to code most of the time right but yes in terms of high level I feel it is an online interview these tools are basically going to help you to boost up your experience a lot just give a try before actually going to the system design round so that you know what tool what from where what you need to be picked most of the time people are open to use any of these tools but if they are not let's try this out because most of the company that I've seen using these tools one of these tools in order to basically ask your system design one is draw.io just look at it out and it is very cool and very easy to use gliffy.com is another the lucidchart.com is basically another very good example miro.com is another tool which is going to help one note from the Microsoft is also very good tool where you can use your joystick in order to basically draw certain things or use your mouse basically in order to draw or do a free hand drawing also Zenboard most of the time in Google UI or you can say Uber or many companies I've seen people asking you to use the Zenboard basically where you have multiple slides you use one slide for the requirement of the slide for different different purposes so these are very cool tool just get your hand dirty so that before actually getting into the system design round you know how to be more productive right it's more about productive you should be talking you should be discussing more in detail instead of searching how to connect this? should irepresent this with box or circle? so get rid of those things basically that will make you more productive while attending the interviews so yeah let's talk about most important part which is mantra to crack the system design round big talk for a small guy which is what Motu bhai also likes first thing is don't be like Pushpa as we said I am only going to talk about those things which I have studied. it's not going to work right so what what you should do you should always check the expectation from your interviewer right so keep on checking the requirements and the expectation which is very very important the next point is basically you keep on talking in the system interview round which is which is very important most of the people don't understand so keep talking that that will help the interviewer to gauge lot of information about you in a very short duration because most of the time they wanted to understand what sort of work you have done what sort of thought process you have what decision you will be taking in different use cases requirements right which is very important don't rush into the implementation which is very very very important right most of the people directly shoot into the implementation and they think he this is very important and like as we are a developer to be implemented it's going to work in system design this is not going to work most important right pick one problem at a time when you are going to discuss anything in detail don't jump into too many things like at a time this is this is not going to help you right so pick one get into the detail keep on asking with your interviewer what is the expectation and basically couple of things in terms of get familiar with with the tool also that is going to basically make you more productive during the interviews and where you won't be searching for what sort of tool how to use that tool your your thought process will be more about cracking the system design discussing about your your knowledge right the expectation that is there so other thing is like definitely go and practice two three system design how to basically create those HLD and LLD with the different tools and yes that is going to help we are also going to cover a lot of mock interviews mock example you can say the sample problem that will be discussing in the upcoming videos of Chakde system design series so keep watching that along with that the most important thing in the last thing which you should keep in mind is related to keep on discussing keep on thinking taking approach and basically discuss that approach finalize that approach and basically repeat keep on in trading so that you come to the better version of the expectation which is there right I hope you got a better understanding of how to crack a front end system design interview. If you like this video, don't forget to like, share and subscribe so that it can reach to the most of the people who are looking in order to crack the front end system design Also, do let me know in the comments what sort of mock interviews, what sort of HLD and LLD interviews question that you wanted to cover me in the upcoming episode. Thank you for watching chakde System Design series and see you in the next episode.

Welcome back to the Chakde System Design series. I am Chirag Goel. In this episode, we&#39;ll be talking about how to crack front end system design interviews. Yes, we will be talking about things to consider in front end system design interviews. What are HLDs? What is LLDs? What are the tech stack discussions? What are the other performance discussion? What are the requirement discussion in terms of the functional and all functional requirements, right? Component architecture, getting into the what are the things that need to be considered in the implementation detail, right? Not limited to that, we&#39;ll be talking about what are the different type of system designs which are asked in different companies, like Flipkart have product sense, Uber have UI architecture, Google have design round, right? Microsoft has system design round. So they are the different, different things which are basically asked in different interviews. All are around the system design rounds. It&#39;s more about few things are heavy on the company specific requirement. We&#39;ll be talking about all of them. Not limited to that, we&#39;ll be talking about tools that can help you to basically crack the system design interviews. Not limited to that, we&#39;ll be also talking about mantras of cracking system design rounds. So are you ready? So let&#39;s get started. Motu Bhai&#39;s offline business was going well. Now Motu Bhai saw that his competitors started having online business as well. So Motu Bhai decided that I would make an app and website online so that my customers can order easily. So what he decided, he decided that I would set up a tech team. Now if I want to set up a tech team, Motu Bhai knew that I wanted a senior developer. He wanted a junior developer. Senior developers who know things on high level, on infra level, how a system is made, how it is scaled, its performance, security, everything. Do you know about junior developers who can work under senior developers and can develop applications, can write code, can develop features. So this was the set. So Motu Bhai heard that system design is something which is very important and on the basis of which you can easily judge a candidate. Coding skills are required but on the basis of system design, you can understand senior developers that yes, how well designed the system and how much work it has done. So what he decided, he went to his friend. He went to his friend and said, I have heard about system design, tell me a little bit about it. So he went to his friend and he told that he had heard about system design interviews. So there is a round which is called system design, there is a product sense, in the product sense, your product, tech, UX, user experience, user interface, everything comes. In architecture, basically, your many things come like, your functional requirement, tech scoping, component designing, high level and low level designing, everything comes. In machine coding, mostly in low level designing, some things develop. Now Motu Bhai is confused, that I was only for the system design. Now there is a product sense, system design, UI, architecture, coding, machine coding, round, component design, what is this? He got confused. Did you got ever confused? Don&#39;t worry. We will be covering about what are these differentiation and what are these different companies asking about different rounds. As a system design round, we will be talking about in detail. But before covering this, let&#39;s talk about what are the things which are important in order to understand our system design round. So we will be covering about things to consider in the front end system design interviews. So couple of things. First important thing is requirement gathering. What are the things that you wanted to have in your application? In terms of two perspective, like functional requirement, non-functional requirement. Second is the scoping, prioritization. You can&#39;t build everything in the first shot. So you have to prioritize your MVP, basically. So then you basically make a tech choices. Which libraries, which frameworks, which technologies, which languages you will use in order to develop the application. Then you have a competent architecture. That is a big architecture that will drill down many requirements and see how it will look in terms of front end. Then it&#39;s more about how communication will be between them. How the APIs will communicate with the backend of the backend. How they will communicate with the protocol. Or their implementation details. So let&#39;s dive into each one of them. Most of the time, system design questions are very open-ended. Like build a grocery application like Flipkart, and big basket. It can be grofer&#39;s. Or it can be applications like you have to build a chatbot. Like web.whatsapp.com or WhatsApp, basically, similar kind of thing. You can build the Instagram. These are mostly the open-ended system design questions which are asked. So what you should start with requirements. Requirements are the same important. So when we say requirement, they are two kind of requirements. Those are very important and we should start with them. First requirement is functional requirement. So let&#39;s make it. Okay. So first, always start with the functional requirement. The second thing that you should start with non-functional requirement. Okay. So basically you have non-functional requirement. When we say functional requirement, so you have to basically first discuss with your interviewer what sort of area he wanted you to cover. Either that is demand side or supply side. Right. So when we say demand side or supply side, it&#39;s like, do you want to dive me into the B2B or B2C side of thing, which are very, very important. Right. So always discuss with your interviewer what sort of expectation he&#39;s having. Right. Second thing, start with high level and dive into the feature. When we say high level, you always start with a module level thinking. Right. And you dive into your feature level thinking. Okay. What it meant by, let&#39;s discuss. When we say module level, right. Any of the applications that are built, so that has some critical modules like you have user management, right. You have other things like help and support. Help and support. Right.
You have other things like your payment pricing related stuff. Maybe payment gateway. You can say, right.
You have your pricing and subscription related stuff. Pricing and subscription. Right. There are other sort of thing, which are also very important when you basically talk about any e-commerce application. If you are building like product listing page. And sort of thing. Maybe taking example, there can be card page obviously, where you basically add all the items. And finally you see, these are the item I wanted to basically purchase and finally you click on. Yes, this is the payment gateway. I wanted to go for and other things. It can be like your accounts management. We have discussed about the functional requirement from the product, from the user perspective, what are the features and functionality we wanted to deliver to the end user. Right. We wanted to have in our application. Now it&#39;s time for the non-functional requirement, which is actually going to boost your performance, the out of box features. And you can see the user experiences to the users in your application. Now, couple of things that we wanted to check. Either we are building for the mobile or we are building for the desktop. Right.
Those expectation need to be set. Are we looking for a responsive application or the adaptive? Adaptive is like you wanted to build for a specific resolution or the breakpoint and responsive is like your application is going to work for all the device sizes. Right. Yeah. Then the next thing is what sort of internet speed and what sort of users, where the user will be coming from. Right.
Which is the internet speed, localization, location basically, location in terms of in order to think in terms of the CDN, how fast you can deliver stuff. And obviously, what sort of devices they are going to use like they are having a tablet or they are going to use in the mobile. Those things are very important. Right. In terms of the accessibility, like are we also going to support people who have some, some disability sort of stuff? Right. So we have covered all those things in more detail in the previous recording that of the chakde system design. You can check out in the comment that link is shared. And we also wanted to discuss about like asset optimization. Are we thinking about the how well we are going to deliver our assets in terms of the CSS, JS, images, right?
We have to think and discuss and how we are going to monitor our performance. So when we say monitor our performance, it&#39;s more about are we thinking about like FCP, are we thinking about LCP, are we thinking about TTI, right? In short, we can say are we thinking about web vitals or not, right? Which are very important. I can keep this together over here. So those things are very important when we, when we discuss about the performance, are we thinking about the client side rendering or the server side rendering? Those discussions are important. Are we even thinking about authentication and authorization, role based access of your web pages, your features functionality, thinking about the security like the cross-site scripting like SAP content security policy. So many things. Are we thinking about caching of caching of our resources, caching of the API responses, caching, wherever applicable, right? Are we thinking about the offline support or not? Those are important things to basically discuss in the interview. Are we even thinking about logging and monitoring, right? So those things are basically we should discuss in more detail and let quickly move this up so that we can add couple of more points. So we talked about logging and monitoring, right? So there are other things that need to be discussed. Like are we going to support the A-B testing in terms of the, are we going to provide the feature flag so that we can roll out things on the faster basis? We should have the testing like unit testing and the end to end testing. We thinking about the internationalization, right? Or say suppose localization. Are we even thinking about versioning of your application, right? So is that the requirement? The progressive web app, are we going to build, right? Or we are, are we thinking about CI CD pipeline, right? How, how are applications are going to be built? How are application is going to be served to the end customers? How it is going to be on the production, right? Are we thinking about some pipelines that we can have in our application to provide the better checks, right? It can be your code quality check. It can be running your automation shoot in terms of your testing. All sort of things can be discussed over here. When we have a huge list in terms of the functional and non-functional requirement, it&#39;s time to basically scope it, prioritize it. Because in 40 minute or 45 minute in one hour, we can&#39;t discuss everything that is there on the board, right? So we have to prioritize and it&#39;s time to prioritize the stuff. Once we have list of this requirement, we should not become Pushpa, right? We will tell the same thing that we have read, right? It&#39;s good to ask the interviewer like what he is actually looking for. Because different people have different expectations and he might be looking for some specific thing to be covered in the interview, right? So let&#39;s not become Pushpa and say, we will tell the same thing that we have read. Although we all have done this anytime in past, either in college or in our interviews. But let&#39;s not do in the system design round because that will become a problem, create a problem for you. Okay, now talking about the functional requirement. First, as we said, we have to make it clear either that is the demand side or the supply side. Most of the time, the interviewer can say, I want from the demand side. Like I want to see the B2C. Like you actually, where your customers are basically making a purchase, they wanted to dive into that. Then in terms of like freezing the modules, say suppose the requirement from the interviewer is, I wanted to discuss more on the product listing and the cart page. It can be product listing and he wanted to talk about the cart page. He want you to dive into that. Now, it&#39;s time to dive into the features on these basically modules. So try to dive as much as possible and then like discuss about what are the critical features that you wanted to like freeze on so that you upcoming time that you have in the interview, you can focus on that like features. Obviously, one thing is you wanted to have a search where you can search the product what you are looking for the listing of product, which is very important. Then capabilities like there should be a product detail where user can see the details about the product. There can be review section also where you can see the feedback sort of stuff of the product. There can be other critical things like there should be capability to add items to cart or whistlist. Whatever you are looking for, you can basically discuss about whistlist may not be the primary thing, but it&#39;s always good to double check with the interviewer. Now, the second is the cart list. Like you wanted to see all the items that are added into the cart in this one place, where there can be other more capabilities which are very critical like other capabilities. One is you wanted to see the price breakup, which is important. So how what are the taxes applied? What are the discounts that you have received and all sort of thing and definitely feature capability to add or remove basically products, which are also important thing to have in the cart page. Now, you have you have freeze. Do you have a scope certain things that you wanted to drill in more discuss about instead of talking about all sort of module that you have in mind because now the scope is freeze. You can dive into in more detail. It&#39;s time to go into the non-functional requirement. So in terms of non-functional requirement, again, you check with your interviewer what sort of expectation he&#39;s having. He might say, let&#39;s go for the for the desktop application. Let&#39;s focus on the responsive design. I want to build it once and it can be used at the multiple resolutions wanted to discuss about the accessibility as well. And he&#39;s actually looking for the asset optimization and the performance of stuff. Right. So it&#39;s okay. Like discuss about those things he wanted to discuss about as we said performance as well. What are the other things that interviewer might be interested in? Maybe he wanted to discuss in terms of the CSR and this is a client-side rendering in the server-side rendering and the most popular stuff related to the caching, right? How you are going to basically cache your application or all sort of thing he might be interested in. So with this, we have basically scoped our requirement and now it&#39;s time to dive more deeper into that. So our functional non-functional requirement is scoping is ready and we are we are basically done with that. And we will be diving into the tech choices. First thing is the library and the frameworks basically you are going to use in order to build the application. right Which is very important to discuss about. It can be like you may be talking about I wanted to build this feature of the functionality or this application basically on React, right? Because you might have worked upon that works for most of the people who have just started their career for a couple of years of experience and you can just showcase that similar kind of functionality and feature I worked in my previous organization in the requirement product basically and those work basically with the React or whatever library that you have worked with. Now for senior people, it doesn&#39;t work most of the time. Reason is like you should know what are the options which are present in the market and what is the best right of choice basically as per the requirement that you have. It shouldn&#39;t be like I have worked on this and I want that&#39;s why I wanted to use this particular library of the framework. It should be always combination of multiple things. What is the best suit basically for the requirement and what is the best fit available in the market and what are the skillset your team has right which is also a key factor in order to build things on a faster basis and to provide the best possible solution as soon as possible right. Second thing is your state management. There are so many like options which are available. It can be if you are using React, it can be context, Redux sort of thing right. There are other sort of state management that you wanted to do. Maybe your database management on the client using the index DB anything that you wanted to do as per the requirement that you have discuss about those choices available. The folder structure is also important. So when we say folder structure, it&#39;s more about you want to follow the duck model like how you wanted to have the different layers in your application, how services you wanted to create where you want to keep the common pieces right. All sort of thing need to be discussed over here. The packages is important because a couple of people wanted to have the NPM packages basically for the different module or people may wanted to have a mono repo sort of thing or the micro front end architecture right. So how you want to do basically structure your application so that these requirement can be fit and these can work for the large teams as well right. So those things can be discussed over here. Dependencies depending on what sort of requirement you are going to touch upon. You should always discuss these dependencies like these dependencies can be like you wanted to build some drag and draw functionality some some like mine chart or mine tree sort of thing application that you wanted to have. Maybe you wanted to use the canvas right you want some some like analytics to happen. So probably you wanted to have the SVG sort of stuff or you wanted to have some streaming or some gaming sort of stuff like RTC sort of stuff you wanted to have you should also discuss about the design system either you wanted to build your own design system or you wanted to latch on the existing design system like material design and design right. What sort of design system that you wanted to have so that it works for your all your applications would have similar look and feel and obviously it has consistency in terms of user experience. So those things are very important to discuss. Build tool is also key key thing that you should discuss depending on what sort of as requirement either you wanted to have a package or you basically you wanted to ship it for different use cases. You should always discuss like do you want to have the pack you want to have a roll up sort of thing right or you wanted to have parcels basically for your build it&#39;s not built it&#39;s for build tool right. So basically discuss about those things those are very important. So just freeze on that what are the tech choices you wanted to have you wanted to make before you move ahead and dive into the more granular level right. So we&#39;ll be getting into the more granular level but before that freeze on the tech choices for you are engineers for senior people. This tech choice is something which is very very critical and interview are very keen and looking into how you are making your choices at the different layers right. It&#39;s time to discuss for the component architecture when we say component architecture we have to give dive into the feature of the functionality that interviewer is looking into in terms of how we are going to construct and break that problem statement right. So couple of things which are very important like interviewer is saying let&#39;s let&#39;s dive into product listing right. When we say product listing they are couple of things that we should always discuss about first thing is how a component hierarchy is going to look like right. So when we say component hierarchy so it&#39;s it&#39;s quite similar to like how we wanted to basically have that hierarchy maybe something like let me quickly see how can we get that hierarchy. Okay something like this. So you have your main component with that main component you are having different other small small component it can be you are having a search along with that search you are having other capabilities in terms of the search different sort of search you are providing you have a listing basically in listing you have a product each product may be having a catalog or showcase thing that can have multiple other small small component like rating component your button component right. Your your image component you are certain different different component that you wanted to have. So try to dive into the component hierarchy we will be diving and we will be seeing this example in the upcoming sessions where we will be doing a mock interview on the different HLD and the LLD that are basically asking the interview don&#39;t worry about that it&#39;s more about just wanted to give you a high level stuff how this component hierarchy will look like. So try to use we will be talking about some tool that is going to help you basically build this hierarchy as well on a very quick and faster way. So this is this with this interviewer wanted to understand how you can break a big problem which is given and how granular basically you can think in terms of its implementation detail which is very important now. Second thing is very important is the routing routing in terms of how you can visualize your application how you are maintaining your state in terms of the route what are the things that you are considering why managing and building your application like you have a detailed page when you&#39;re opening something and some pop-ups basically comes up. Are you thinking about persisting those things in a route so that it can be shareable right. How you are going to share your data between the different routes those are very important. So data sharing is also very critical thing that you can discuss in the component architecture where how different component are going to communicate with each other how different routes are going to access the data at different layer how you are basically utilizing the cache when you are doing data sharing all those stuff basically can be discussed in the component level architecture. This is something which is very important and most important part of this is like how you are breaking down your components or how you are breaking down your big problem into the component level so that this can be reused at multiple places and how you are segregating your business logic with your you can say abstract or dumb component all together those kind of thing are basically checked inside this component architecture structure right. So now once you are done with the component architecture it&#39;s time to dive deeper into the data APIs protocols and the internal implementation of the component that you have just discussed about. So let&#39;s let&#39;s talk about that first thing first protocols. When we talk about protocol. What are the things that we should talk about like either we are going to use the rest or we are going to basically use the graphical endpoint right. So are we going to use SSE service and event or we are going to have some rPF sort of thing right. So these are the different protocols that we have we will be discussing about these in upcoming sessions although some parts we have already covered but we will be coming don&#39;t worry about that. So in terms of either we are going to have the JSON sort of response or we are going to have the protocol buffer like people may not be aware of the protocol buffer. Most of the times the developers have worked on the JSON sort of don&#39;t worry we will be discussing in more detail. It&#39;s more about you should have some idea what are these protocols all about and like what are these different type of response type as well. Right. So with this basically once we are discussed about finalize what are the protocol that we are going to use as per the requirement the next thing that need to be discussed is about the implementation detail. When we say implementation detail it&#39;s more about say suppose as interviewer said we wanted to discuss about the product list right in product list the key functionalities are related to your pagination right. You can say pagination or the infinite scroll. When we talk about infinite scroll it can be using throttling or it can be using international intersection observer. You should talk about those things in more detail so that it gives a better understanding to the interviewer that you have worked upon it and you know how things can be handled in such scenarios. You talked about the debouncing when you have the search like capability obviously the throttling related so that you understand what are what are these and you also discuss about the about controllers so that you understand you let them understand or the interviewer understand you understand about the cancellations of the API right you understand about the inconsistency that can happen because the API response of the previous query may come afterward and you might show the irrelevant information or the old information to the user right. So discuss about those things in more detail when you are discussing about the implementation detail and then chipping into the API&#39;s like when we say API&#39;s it&#39;s it&#39;s more about what are the API&#39;s that you need in order to build this application. Like product listing add to cart sort of capabilities you wanted to have what are the API&#39;s that you need like first API which I can think of is you want to get product list right you want the list of all the product given some parameter those parameters something that we&#39;ll be discussing but like list down all the API&#39;s that you need second is you need the product details right so for with respect to a particular product I wanted to get into the details and I wanted to see the details of that right there should be capability to add product to list right so there can be other requirements like remove product from list right which is your cart or you can say make it cart which is more better terminology over here right. So these are say suppose the API&#39;s that you are looking for you can come up with other sort of API&#39;s that you think which are required in order to build the application the features which you have just closed with the interviewer. Other thing is data modeling right this is very very important thing that you should discuss in more detail when we say this data modeling is data modeling is all all about that you are going to discuss what sort of like most of the time the UI at the front end the back end guides sit together in big companies in good companies basically in order to decide what sort of contract that you will be having in order to build this feature the functionality the first thing first is the URL what sort of URL that you wanted to have what sort of methods basically of these URL you will be having like you have get or post you have like delete what sort of method you will be having right update put basically and what sort of request and how the request will be sent either it is in the query parameter or you are going to pass in the body depending on either it is a get API or the post API right which is which is important apart from that let me quickly move myself okay apart from that the things which are important are your response but before that I&#39;m just moving couple of things so that it can fit over here. Response are very important right you we discussed about the request how you wanted to have it either in the query or the body what will be the structure of that it&#39;s time for the response most of the time people discuss about what sort how the data will be passed in terms of the the actual required data that need to be consumed on the UI right but no one basically talks about how the error basically will be circulated like you talk about data in terms of this will be the array or it can be in the object form right can be any form but discussing about the errors are very important because you can think about if you are passing the right set of status code and you are passing the relevant context from the server to the client then the localization the internalization sort of thing can be taken care of and obviously certain things you don&#39;t want to reveal the exact information and sometimes you don&#39;t want to show the generic information as an error right so those things can be handled very well if you think about error passing the error in the your response in a well-structured format and have that contract with your backend team that can be standardized across right the status code are very important always saying that I will get a like 500 error for any sort of like errors that doesn&#39;t work right you should properly utilize like 4x6 5x6 and even
when you have 2x6 let&#39;s utilize that in far better way where you know I just wanted acknowledgement I
don&#39;t want actual data when I am updating something use a better status code in terms of the 2x6 so
similarly once this data modeling is done which is very very important thing when you discuss when you
have a proper contract with your your backend team the next important thing is the component like interviewer
as your UI engineer interviewer is also looking into how you basically implement a component and how generic component
you are building so that there can be multiple consumers they can utilize this as per their requirement
right so how you are managing your state what are the props basically you are thinking in order to
expose for that component so that it can be reused what sort of event handling that you are you are thinking about in order to consume right so what what capabilities you wanted to provide to your consumers so that they can handle right so customer what sort of customization you are going to provide an expose to the your consumers in terms of the teaming in terms of the layouting right so can they control the colors they can control the theme of your component that you have built so that they are more and more user and more generic implementation that you can think of then definitely the usability is definitely that is
unsaid thing which is required in any of the component that you are building right so this discuss about that keep that
in mind when when you are like designing your component then obviously the data source is something that need to be
discussed when we say data source who is actually taking care of making the API call do you want to keep this logic inside the
component or you wanted to give this capability to the consumer so that more and more consumer can decide how they wanted to face the
data right it&#39;s more about you are passing the relevant requirement which the user have input in the component so that your business
logic can be segregated and that can be abstracted from this component so those kind of thing that basically you should discuss in
more detail and you should come up with some API component APIs when when you are designing that right so I you can say it component
or you can also say it as a component API which is required sometimes an interviewer may be looking into like let&#39;s write the code in
order to like have the implementation of this so we will be discussing about what are these interviews where the HLDs basically are asked and some of the
interviews where LLDs are basically low level designs are basically asked and how to basically write those low level design we will be
discussing about more and more detail now we have understood the different expectations right expectations of a system design around
in terms of requirement functional non functional requirement scoping tech choices component architecture right the data
API protocol in the implementation now we understand this it&#39;s time to understand what are the high level design and the low
level design which are generally asked in the interviews right so if the system design round is mostly evolving about the HLD right
which is high level design there is no point of discussing anything which is related to the low level design because you can basically
optimize the time duration which is provided in the interview in so that you can focus more in detail of the high level
similarly when it is low level design there is no point of talking about the high level because that high level design may be
having a different round altogether in the interviews right so it&#39;s it&#39;s important to understand what sort of like
mindset of what sort of interview round that is basically that is going to help you to dive better and meet the
expectation of the interviewer in far better way right so with this we we discuss about requirement scoping
in the tech choices right all of these basically comes into your HLD right this this is this is basically your
high level design so this is basically you called it HLD maybe I can make it right color this this is basically HLD
that that mostly people call it so in this HLD basically what is being asked is like are you able to discuss about the
requirement can you come up with the functional the non functional requirement are you even think about prioritizing certain things are you
even think about what what should be the first MVP what should be the key functionality that you should roll out obviously people wanted to
build everything but you can&#39;t build everything in the one shot right so are you able to even prioritize what are the critical things
and how you can roll out your P0 P1 and P2 sort of functionalities right are you able to even think in terms of your users they
are requirement are you able to think as a product manager right so those things are very important tech choices are you even
able to think in terms of the senior level architect right where you can make the right set of tech choices those are basically
main areas where people wanted to focus on the high level design similarly when we talk about low level design low level design is it&#39;s like
people have their expectation very clear they they wanted to dive you into the more granular you can say the implementation details instead of having the
high level because high depending on your role right if if you are not a senior level architect people may not ask you the high level design people
may want you to basically come up with the implementation detail and implement some some piece of the application right so some of
the question that you might see like build a auto complete sort of application or build a chat application or build a cart right like any of
the cart product cart basically sort of thing or build a product listing or you can be asked to build a customizable form right where some
configuration is given and you generate a form out of that all sort of things basically are asked in this particular round which is called LLD which is
low level design and the expectation over here is sort of very clear people don&#39;t want to dive into the internal details of that it&#39;s more about they
wanted to see how well you implement and how well you basically create the API the component API is or basically how well you structure your protocols
or how your communication are going to be the back end in the front end right how well you are going to model your data and how well you are
basically going to have component hierarchy data sharing those kind of things which are very important obviously the best practices that you are
going to use in your application in order to build so to make it very clear high level is mostly asked for senior people low level design are asked for
almost everyone either that is senior or the low level like not low level it&#39;s more about the people who are just starting a career or having couple of
years of experience right so you should know how to develop your application but high level designs are very critical for senior developer anyone like
four five year plus most of the companies have started asking this high level and very interesting I have seen many startups many companies which have started
asking this high level design even for two year three year experience they are not expecting much detail but they are expecting you to basically either you are able to
think in those direction or you have just done some assignments or tasks that are being like asked by the senior people so sort of expectations are high in these days
in the front end it&#39;s no longer to fetch the data and just show the data on the UI how did you forget that Motu Bhai is still confused right
I understand in the product sense what about people talking about different terminology like system design, product
sense, U.I. architecture, machine coding, component design when we say system design most of the time companies have a requirement companies
have expectation that you will be going into the requirement scoping tech choices, component architecture and the data API and the implementation whatever
we have just discussed previously almost everything you have to going to cover and obviously you have to speak a lot in order to like in the short
duration you have to showcase the knowledge that you are holding right so that is the expectation that companies are having in the
case of product sense around like system designs are mostly asked in like Microsoft in any of the big companies people are looking for the system
design right so a product sense flip card do ask the product sense and many startups have started asking the product sense where the requirements and the
expectation is like whenever the system design is basically called about it&#39;s more about the combination of multiple things
are you able to think in terms of the business are you able to think from a product manager or
the product side of thing right are you able to think from the design perspective in terms of the
user experience user interfaces are you able to think as a front end developer in terms of not
just the things which are visible to you the back inside of the front end right in terms of
the optimization performance non functional requirement that we discussed and obviously
the back end it&#39;s not about you are going to work on the back end it&#39;s more about how
if you understand the back end guys well how what are the challenges they are facing
what are the ways they use in order to optimize in order to basically implement
certain pieces so basically you will be able to help in chip in and you will be able to discuss
in more detail when you are having a contract discussion and when you&#39;re doing some solution
so that&#39;s why this whenever the system designs are basically discuss about it&#39;s a combination
of everything that is listed over here right so similarly when when a product
since is basically consider it&#39;s more about are you able to think
from a product side right are you able to list down the requirement
properly are you able to scope those things in terms of the
prioritization in terms of the like scoping right are you able to come up
with some basic you can say data API&#39;s and the implementation that you wanted to
have the back with the back end guy right so those kind of expectation are there in the like flipkart the other startup
companies that they have started asking UI architecture is again people have expectations in terms of you will be diving into the requirement
may not be very depth in terms of the module but yes certain pieces because the problem statement may not be very very big or
open enough right similarly scoping the items that you have just discussing the in terms of the
requirement tech choices people want you to dive into the very heavy tech choices
discussion in the UI architecture and obviously competent architecture in order to understand either you are able
to think in terms of the usability right sort of stuff obviously the data we are in the implementation so
how you are going to basically fit and how your communication are going to
have with the different back end teams because there are so many teams
that you will be having a discussion micro services multiple stuff there are
aggregator layers how you are what are the requirements that you may be having maybe
people team or heavy managing their graph to your endpoints right so how well you are
basically coming up with your requirements it&#39;s not about whatever is in database i will manage it 
it&#39;s not going to work at a large scale obviously there are a lot of latency and unnecessary like network layer load so those
things need to be kept in mind so talking about the machine coding on the
component design like most of the companies generally ask this in terms of the
low level design they call it low level design where either your machine coding or a company design will be first or the
second round where they will be giving you a small piece of application that need to be built right when we say small piece of application as we discussed
it can be similar to building a customizable form or your card right it can be implementing a search capability
auto sort of complete sort of thing right it may be simple functionality where you
have to come with a pixel perfect some some design it can be a form it can be a multiple
screen router sort of thing that can be asked right so over here the expectation
is obviously how well you are structuring your application your code in order
to implement but on top of it there are almost every company mentioning what
is must have right do take care of that must have don&#39;t try to basically do a
super cool stuff in that small duration because that round may vary from
one hour to two or sometimes it&#39;s three hours sometimes people give you as an work
at home sort of stuff as well right they will give you a big problem big application
that need to be built and they want to be you written back in 24 hours 48 hours
sort of things are there right over here the expectations are not never that
everything you will remember in terms of the function or the code everything it&#39;s
more about it&#39;s okay if you forget some method you can Google it
out that works right it&#39;s more about how well you basically implement are you using the best practices in
order to get into the those right so in in this the just make sure what are the expectation? what is
the must have you have to basically consider while implementing just take
care of that certain tools can basically help you to speed up the flow diagram or the speed of the things that you
wanted to have in your system design right the way you wanted to present a couple of them which are very famous
so there are ways like you can open any of the like paint also you can
use your your pen and basically you can draw if you are that is a physical
basically system design you can use whiteboard definitely in order to draw
and basically represent what you wanted to have for the high level design for low
level design obviously you need a system in order to code most of the time
right but yes in terms of high level I feel it is an online interview these tools
are basically going to help you to boost up your experience a lot just give a
try before actually going to the system design round so that you know what
tool what from where what you need to be picked most of the time people
are open to use any of these tools but if they are not let&#39;s try this out because most of the company that I&#39;ve seen using
these tools one of these tools in order to basically ask your system design one is draw.io just look at it out and it is very
cool and very easy to use gliffy.com is another the lucidchart.com is basically another very good
example miro.com is another tool which is going to help one note from the
Microsoft is also very good tool where you can use
your joystick in order to basically draw certain things or use your mouse
basically in order to draw or do a free hand drawing also Zenboard most of the time in Google UI or you can say Uber or
many companies I&#39;ve seen people asking you to use the Zenboard basically where you have multiple slides you use one slide for the
requirement of the slide for different different purposes so these are very cool tool just get your
hand dirty so that before actually getting into the system design
round you know how to be more productive right it&#39;s more about productive you should be talking
you should be discussing more in detail instead of searching how to connect this? 
should irepresent this with box or circle? so get rid of those things basically that will make you
more productive while attending the interviews so yeah let&#39;s talk about most important part
which is mantra to crack the system design round big talk for a small guy
which is what Motu bhai also likes first thing is don&#39;t be like Pushpa as we said I am only going to talk about those things which I have studied. it&#39;s not going to work right so what what
you should do you should always check the expectation from your interviewer
right so keep on checking the requirements and the expectation which is very very
important the next point is basically you keep on talking in the system interview
round which is which is very important most of the people don&#39;t understand so keep
talking that that will help the interviewer to gauge lot of information about you in a very short
duration because most of the time they wanted to understand what sort of work you have done
what sort of thought process you have what decision you will be taking in different use
cases requirements right which is very important don&#39;t rush into the implementation which is very very
very important right most of the people directly shoot into the implementation and they think he this is very
important and like as we are a developer to be implemented it&#39;s going to work in system design this is 
not going to work most important right  pick one problem at
a time when you are going to discuss anything in detail don&#39;t jump into
too many things like at a time this is this is not going to help you
right so pick one get into the detail keep on asking with your interviewer what
is the expectation and basically couple of things in terms of get familiar with with
the tool also that is going to basically make you more productive during the interviews
and where you won&#39;t be searching for what sort of tool how to use that tool your
your thought process will be more about cracking the system design
discussing about your your knowledge right the expectation that is
there so other thing is like definitely go and practice two three system design how to basically create those
HLD and LLD with the different tools and yes that is going to help we are also going to cover a lot of mock
interviews mock example you can say the sample problem that will be discussing in
the upcoming videos of Chakde system design series so keep watching that along with that the most important thing in
the last thing which you should keep in mind is related to keep on discussing keep on thinking
taking approach and basically discuss that approach finalize
that approach and basically repeat keep on in trading so that you come to the
better version of the expectation which is there right I hope you got a better understanding of 
how to crack a front end system design interview. If you like this video, don&#39;t forget to like, 
share and subscribe so that it can reach to the most of the people who are looking in order to 
crack the front end system design Also, do let me know in the comments 
what sort of mock interviews, what sort of HLD and LLD interviews question that you wanted to 
cover me in the upcoming episode. Thank you for watching chakde System Design series 
and see you in the next episode.

Transcript for:Cracking Front End System Design Interviews: Chakde System Design Series

Transcript for:
Cracking Front End System Design Interviews: Chakde System Design Series