Frontend Design System Interview - 2 questions in one interview, 2024

Hey guys, in this session we're gonna be doing design system interview question for frontend developers that was asked in 2024 by one of the FAANG companies. This was a design system last interview. In, in the row of interviews. This was the last one, so it contained 2 questions. We're gonna start with first one: Design email application. So because it was 1 hour and a half and it had 2 questions, so the requirements was and more overview, more overview design, and not drawing and not going to a lot of details. So it was 2 questions in 1.5 hours and more kind of overview and understanding of application and what you need to consider. When designing such an application. Okay, so let's start design email application, application like Gmail, for example, this type of application. So we need to, we need to define In this question, what is requested is to define functional requirements and non-functional requirements and just list most of them. Sometimes functional requirements and non-functional can— it's hard to detect which one is functional and which one is not functional, but the most important thing is that you put it in one of these categories. And the idea is, from what I understood, it was just if you fit all the checkboxes that are expected from you to talk about, then this is the, this is the goal of this interview. Okay, so we're gonna start with functional requirements. Functional requirements. Okay, so what our functional requirements— what it means? It means that all the requirements that application says it, it supports and visible to user, that's what it should do. So the basic seeing that application, as it says, email application. So the ability to— we can call it core features— the ability to send email, send, send emails, receive, receive res— sorry, receive email, emails, not one but many emails. Okay, this is a core feature, so we want to be able to send emails, we want to be able to receive them. Also, we want to be able to receive our emails in, so if email was sent to me at X time and then email was sent to me at X plus 15 minutes time, then I shouldn't see first X plus 15 minutes and then X, but I should see, no, sorry, I shouldn't see what was sent in X time first and then X plus 15 because I need to see see the recent one, and then after I should see the older ones. So how we can define, but it's— I'm not sure if it's functional or unfunctional, but you can just— we can mention that receiving emails as the latest first and the oldest after emails by time. We can say by time they were sent. Again, this one can be a non-functional requirement because our application says is that we should send and receive emails. This is what the application should do. Also, one of the core features— and, and again, this one also can be as non-functional— but it should have users. Obviously, you don't— you want to have your own user account and then all the emails associated with you and your account. So we can say user authentication, which, which will contain the users, users, also it will contain permissions User permissions, user permissions. And everything that I'm writing, it was— I wasn't required to write it down, but it was just— you just spoke about all these things. And also, it can be functional, it can be non-functional, but Encryption, we can remind that we want our email to be encrypted. And re-encryption. And, and, and again, and again. So because my app says it sends and receives emails, so they can be sent and received just without encryption. Encryption adds obviously security, and this is what you would want. But the email app will work even so. You can have a non-secure email app, for example, but you would, you would want it to be secure, okay? Okay, so these are the core features, and now we're gonna do non-functional requirements. Okay, so this is a bigger part. Non-functional requirements. Non-functional requirements. Okay, so there is a lot of points that you can add here. You can deep dive into every one of them, but we just want to cover the main one. And then, so make sure you covering the main ones, and then you can add to the main section. Okay, so this is what we're gonna do. So we're gonna first cover the main ones. Okay, so performance, performance. It is very important that the application have high performance, which means that it is always available to the user and it loads fast. And, and every time user wants to do his, uh, as a function, he, he gets— so he gets his email fast, he sends his email fast, and there is no, no delay in this. Okay, so this is the performance section. We're gonna come back to it. Then the second one is one of the most important one is security. Security, and again, don't, um, don't think it's security is important, but again, it would be defined by the application what type of security. Again, you can have high-level security, you can have low level of security. So it is important. And yes, you can define an application with no security which sends and receives emails that maybe don't contain any, any very important information. For example, I can just tell you one out of the— it can, if it just contains some marketing, marketing ads or promotions and they are sent, so this type of application is not very— should be very secure. But again, we're talking about regular email applications, so the security is very important there. So security, this is the second main part. The third one is also important is usability. So that user, if you have an app and it has some features but it's very hard for user to use, this is also not good because it can be high performance, high performance of the app, it can be very secure, but user can have a hard time to use it and eventually he gives up and he leaves this app. So we want usability, usability, okay. Fourth is we want to have— we want the app to be scalable. So for example, we want to go from 1 user to millions of users to billions of users. So we want to have it scalable. Scalable. And then you can just say by words what you mean by that. Another important non-functional requirement is we want to have monitoring of the app. We want to know when the server is down, when the user have errors. So this is related more to development, but it's, it's very important. So monitoring, monitoring is very important. 6. Backup and Recovery. Again, it can be under some of the sections, but we put it as a separate, separate section. So Backup and Recovery, because user want to be able to access all his emails that are on the server. Okay, back, backup and recovery, wants to recover emails. Um, reliability and availability, this is what we want from our apps, which means it is reliable. As I said, when I send the email, I want to know, I want to be sure that my email was delivered, okay? And, and if someone sends me email, it can be very important email, I want to be sure that this email will reach me at, at the minimal time possible it takes for email to reach me. Okay, so it's reliability, and maybe we will separate reliability— this is what we said— and availability, which means that the app is available, always up and running, so the server cannot be down and I cannot access the emails that I should receive. So the downtime should be as minimal as possible, it should always be available to me, and all my emails on this app should be available to me. And next part is customizability. Okay, so we want to be able to customize, for example, number of servers, or we want to be able to customize. So it would mean that we can extend to the new feature and it is easy to extend. For example, if I want to add another feature, so it is easy for me to add new API and support the feature. So it's easy to, to customize, um, database, extend database, create new features for this app. And where it needs to be generic, it should be generic. So, um, yeah, and we can also extend, like we said, when, when it is scalable. So we can also extend a number of servers, number of clients, and put load balancer between them, and, um, and we just can handle much more users. Okay, so What, what I mean by here is that it's easy for us to extend more features, to customize application in terms of code and backend and number of servers or databases. Okay, so we'll call it customizability and and extendability, and extendability. Okay, and these are the main ones. Again, you can put some of them inside, so scalable can be under performance. Again, it's no need to be so precise which part under which, but we can we can extend a couple of them. That, that performance, for example, it implies that I have high responsiveness, okay, high response, responsiveness from the app. And it's also a performance apply on optimization, which, which means it's optimization in terms of the code optimization. This is what under performance. Also under performance, we can also add, um, also here scalability, that it is scalable, but we did it separately, so it doesn't really matter. So don't— as long as you hit the main points which discussed here. And let's extend one of them is, for example, usability. So it's, um, it should be easy to use UX, which is, um, very important. Easy to use UX. Then It should be— it should have accessibility, which, which is important for screen readers or people with disabilities. So accessibility is very important. It's also important to have mobile-friendly, which means responsive design for small screens, large screen. So we'll call it mobile-friendly and responsive design. Mobile-friendly. Okay, these are the main functional and non-functional requirements. Again, some of them, some of them merge, can merge, and don't worry if you put something in functional or in non-functional as long as you mention. So this was our idea, and you can expand any of these points and talk about it in deep. Again, if you don't know into deep some points, then you can always say what you know and then say, um, there is more to learn, I'm sure I can go deep down, I'm just not working on this specific issue. We have, um, usually there is a specific team that working on this, but I'm sure I can read about it and easily learn more about this topic and and you are. Anything can be learned. So these were the main points, and this is what was required in this interview. No, no, there was no need to, to draw the design of client and server and, and API roles. Okay, so now we're gonna move to the second to the second design system question in the same interview again. So I'm gonna move this up and, and create a new question. So it was design a chess game. Okay, so let's define functional and non-functional requirements. Okay, so we also need to ask some questions because, because you can define chess game with different features. So again, we need to know what exactly is required, what exactly interviewee has in mind. So maybe we can ask some questions first. And not maybe, but we should ask questions. So we can ask, do we want user authentication? Why? Because it is possible to create a chess game when you don't need to log in, and we can use your user as a session user, and when it's closed, the, the user will be deleted. And you can play when your session is open in the browser, so it is also possible. Or do we want to define it like a game where you need to log in, and then we can have a history of the users. We don't know what interviewee have in mind, so we need to ask questions. So we need— do we need authentication? Authentication. And yes, the answer is yes in this case, again, because yes, you can do it based on session and then just play live without doing the login, and then your user will just be inactive once your session is over. And this is it. And so yes, we want authentication. And we can also ask, do we want to have a chat in the game? Chat in a game. Um, and the answer is no, we don't need the chat in this case. So it is a game with authentication. And, um, we can also ask how do we pair users. Do we want user to choose a player or do we want them to be paired, um, first in first paired. Okay, so we can ask, how would you like us to pair users? Um, pairing users to game. Sorry, pairing to game. To game mechanism, mechanism, and it should be automatic. First come, first paired, paired. Bird. Okay, this is basically, um, all the questions. So now we're gonna go, um, to, uh, requirements. Let's move it a little bit. Oh, we don't see it now. Okay, just let me, let me put it here. And the questions, I'm gonna move— yeah, we're gonna move the questions here. And now somewhere I added text, never mind. Okay, so functional requirements, so functional requirements, requirements. So first we want authentication. Authentification. Second, we want, we want users to be able to play chess, plain chess, plain chess. It's functional requirements. Users should be able to play chess. Well, I guess this is it. And when one user wins, he wins. But this is basically all the functional requirements. The most— the more important part is of this interview is non-functional requirement. Non-functional requirements. Requirements. Okay, so, uh, again, it's very similar to what we had in email. So, so all of this, basically, if I go up these non-functional requirements are very generic. And yes, we do want, we do want the same, the same requirements. Basically, when you are a developer, so you want, no matter what application you create, so sorry, you want You want your application to, to have all these non-functional requirements because if your app going to be used by many users, so this is what you want it to be. So we can basically take these non-functional requirements and apply it to any application we create because as a developer we always want to strive to the best application if it's an email or if it's a chess game. But this is not all in, in this question. So then we were asked how, how would you, how would you implement connections. So, so now we want to, we want to talk about communication between client and server. So for this case, I I can, I can draw, um, User 1, User 1, and I can draw User 2, User 2. Okay, and then we have our server, so I will have a quick draw, but in this case we So we, we do have client interface, so we start with a client, client, and then we also have a server. We have a server here, server. So this is a, um, this is very, very standard draw. So we have two users using the client and we have the server and we can add some errors. So this user, they both using the same interface and, and the client talks to the server while back and forth back and forth. Okay, and this is just to display that users have inter— is using interface of the client and client talking to the server. And if we will draw here, um, I don't see that I have specific thing for DB, but obviously I have database here, DB. And yeah, so the question is, so how would you implement? So one user registers, and then for example, on, on app we have a feature, I want to play a game, okay, but then we need, we need to, for the user to, to have a match for a different user. And as we said, we, um, gonna use a mechanism that is first come first paired. So for this case, we're gonna use a queue in DB. I'm gonna just make it smaller. I'm just gonna add description here. So we're gonna have a queue in DB which store the first server that comes. So even if the user log in, so for example, the UX will be if you want to play a game, you can log in and not play games, but if you want to play a game, you can say I want to play, you click the button and then you add it to the queue. And the queue is first come first served. Okay, so for example, one client clicked I want to play and he's waiting. So in the server we added to the queue User 1. So for example, User 1 is in the queue. So we have this queue and we have User 1 and he's, he's waiting. And then we see User 2, he comes to the queue. So User 1 now and then User 2. And then the server can take these two and pair them and Start playing. Okay, so when they start playing, first user. So we can add feature if the user want to— if the one who was first, he's gonna start first, or the colors he gonna play, or you can choose, but we will ignore it for this, for this design. But you can let them choose or or it will be just on the basis the first one who arrived, he will be the first to start. Okay, so here we're requested to describe how the user plays. So for example, now we have two users and it is displayed "You start the game" and you start a game. So we will have in the server, um, the server start game and it, and it records two users that now in the game, okay. And so first user sent, um, for example, he, he's making a move and the second server needs to know that he is pending now because he's waiting for user 1 to make a move. So how, how does user 2 know not to make a move? So we're gonna use— so what, what can we use for, for this type of game? We have a number of options. We can use long polling, short polling, and WebSocket, and we also have push events. So it is good for you to describe all the options and then to say, um, what is the best options that you think for this application. Again, you can implement it with all the options, it just depends on how her performance, uh, it will depend on how performant this app will be with what you choose. Okay, so, so you can say short polling, it's when the client asks the server, so can I play, can I play, can I play, and this is obviously not that good. We have long polling, when the client sends request to the server and until the server has update, if for example user 2 can play, then he will, he will hold this connection until he has update. Okay, I received move from user 1, now you can play. And the trade-off here is that he holds connection and the connection can be hold for a long time. Another option is push notification, but this option is only, only the server sends updates. So when server has update on the game, for example, he can send to the user. So for example, user want, want send a move, and then when when server receives it, he sends update to user too. You can also use it, but the main issue with this is that if sent from the server failed to the client, now the server doesn't know that it failed. So you can also combine one of the polling and push notification But you can also use WebSocket, which is connection for every user, and for, for games it's the best because we can know chats or games. But, but again, if you also implement push events with long polling, you can, you can also do that. But for this For this game we would choose WebSocket, so every time the user 1 makes move, the user 2 also needs to— will know to receive what move was made. His board will be updated and he will know that now he his turn to make a move and the user 1 will be pending. So what we also do, so when user 1 makes a move, so when he makes a move on the client, we making a validation that the user 1— this is important to, to mention that we will have on the client So validation, validation of the move on the client, but also we're gonna do validation of the move on the server. On the server, why? To, to prevent cheating, because someone can for example, bypass, bypass the client and send directly to the server, and/or modify a request, and then the server can receive a different move. So we making validation. This is important to mention that we creating validation on the client and we're creating validation on the server of every move. And also we are calculating, so the validation if move is valid, and we send it to the server. And also we are calculating on the server if, if the game is ended. If the game is ended, it sends to user1 and user2 the game is ended and who is the winner. In this case, the move was of user 1, so it could be that user 1 won the game. Otherwise, if it's not ended, then it just sends to user 1 through WebSocket, okay, now user 1 is waiting and user 2 requests to, to make a move. So this part was important. To, to, to add the validation to the server, to say that you're gonna— we're gonna be using WebSocket to, to implement it. And, and yes, all the non-functional requirements like performance, high responsiveness, optimization, security, because we, um, we We're holding users and their emails and their games, so we also want the game of the user not to be visible if he doesn't want it to be visible. So it should be easy to use, it should have accessibility, mobile-friendly. Also, we want people to use this game on their mobile. We want to make it scalable if the game is very popular and everybody wants to play this game on this app. There are many chess games, but maybe this app will be very user-friendly, so everybody wants to play with it. So we want to be able to scale it, to backup, to see— also we can have a history, but it's also part of the requirements. Do we want to store the history? So again, you need to remember that there is a lot of different ways to build the chess game, and there is a lot of different features. You can add history if you, if you want to hold the history, the history of the move, You can have it, or you can decide that you don't want it. You just want for users to play and forget and just to know win or lose, and you don't want history. So there is a lot of different things that you need to verify, and even if you forgot to ask this question, for example, about, um, about the history, so you can also ask it during the— in the middle of the interview, it is completely fine. It just— you can say, okay, I didn't ask that, but do we want to implement history for the move? History for moves. And the question, for example, in this design system interview is no. But you can add obviously a lot of features to the game. Game can be very simple, as simple as it is, and it can become to have a lot of different features and a lot of different ways to implement it. In, in this case, what was important is to show your let me move it like this— to show your understanding that you need a bidirectional connection, your knowledge of all the possible variations of connection between client and server, and your choice, what you choosing for this game. It also was important to, to notice that you want to have validation on the move on the client and on the server. And was important to, to know that you want to store your users in the queue first come first paired because this is was These were our pairing mechanisms that were required. And, and also, um, remember that all the non-functional requirements should be the same for every app, um, because you want to create a high-performance app no matter what application it is. And again, it can be less in every, in every requirement, more in every requirement, dependent of the app, but nothing is set in stone and you can, you can, you can play with it. Okay, so about authentication, important thing was, okay, do we want authentication? If we want, how would you do authentication? And there was a question, what would you request by authentication? And I said email. So why? Because email is unique. That was also one of the questions. So sometimes it feels very trivial for us because all authentication are the same and you don't feel like you need to to go deeper, and sometimes you don't understand the question, but you can, you can ask. And, and yes, the standard is with email, and email is unique, but also you can assign a username and attach it to, to the email, or let the user to choose some username, but you still need to If you want verification by email or by phone, you will need some identification. In this case, email is just standard. Okay, so, um, these were, um, the main points on this design system interview. Um, so again, was two questions. One, design email application. Mainly high-level design chess games, more deep dive into how would you go about implementing it, client-server communication, database, and pairing mechanism. Okay, let me know what you think about it, and thank you for watching.