1 00:00:00,040 --> 00:00:02,680 It is all about trade-offs. Just always remember that it is 2 00:00:02,680 --> 00:00:06,400 not about perfection. It is about trade-offs and your 3 00:00:06,400 --> 00:00:10,520 ability to understand the pros and cons of any approach that 4 00:00:10,520 --> 00:00:14,280 you choose, to be able to discuss many possible 5 00:00:14,280 --> 00:00:19,160 approaches, to be creative and to be conscious of the current 6 00:00:19,160 --> 00:00:21,320 and possible of future requirements. 7 00:00:21,680 --> 00:00:24,320 Yeah, I I think this is about what it is really. 8 00:00:24,480 --> 00:00:28,440 And being able to communicate them clearly and concisely. 9 00:00:33,600 --> 00:00:38,800 Hey everyone, my name is Henry Surya Virawan and you're 10 00:00:38,800 --> 00:00:42,360 listening to the Technically Journal podcast, the show where 11 00:00:42,360 --> 00:00:44,600 I'll be bringing you the greatest technical leaders, 12 00:00:44,880 --> 00:00:48,440 practitioners and thought leaders in the industry to 13 00:00:48,440 --> 00:00:52,680 discuss about their journey, ideas and practices that we all 14 00:00:52,680 --> 00:00:56,200 can learn and apply to build a highly performing technical team 15 00:00:56,720 --> 00:00:58,920 and to make an impact in your personal work. 16 00:00:59,560 --> 00:01:07,480 So let's dive into our journal. Hello everyone, welcome back to 17 00:01:07,480 --> 00:01:09,880 another new episode of the Techie Journal podcast. 18 00:01:09,880 --> 00:01:14,200 Today I have Zhiyung here with me, the author of asing system 19 00:01:14,200 --> 00:01:17,000 design interview. Hearing this title, I'm sure you 20 00:01:17,000 --> 00:01:20,760 know that we are going to be drilled by Zhiyung about how we 21 00:01:20,760 --> 00:01:24,520 can do system design better. If you are a more maybe like 22 00:01:24,520 --> 00:01:27,320 software engineer, right, you would have maybe experienced 23 00:01:27,320 --> 00:01:30,880 this in your interviews before. And it's always stressful, at 24 00:01:30,880 --> 00:01:33,720 least for me, because sometimes you don't know what to expect. 25 00:01:34,120 --> 00:01:36,800 And in the end, you also don't know whether you are doing great 26 00:01:36,800 --> 00:01:38,760 or not, right? So hopefully Seayoung can give 27 00:01:38,760 --> 00:01:41,040 us some pointers today. So welcome to the show, 28 00:01:41,040 --> 00:01:43,360 Seayoung. Thank you for having me, Henry. 29 00:01:43,840 --> 00:01:46,960 Right Seayoung, I always love to start in the beginning by asking 30 00:01:46,960 --> 00:01:49,760 my guest to share a little bit about maybe your highlights or 31 00:01:49,760 --> 00:01:53,080 turning points that we can learn from you well. 32 00:01:53,400 --> 00:01:56,120 I suppose if this was advice for the general software engineering 33 00:01:56,120 --> 00:01:59,240 community, yeah, I would say one point is that you should work 34 00:01:59,240 --> 00:02:02,280 with your manager. Well, when you enter a new team, 35 00:02:02,600 --> 00:02:04,520 one of the first conversations you should have with your 36 00:02:04,520 --> 00:02:06,680 manager is to develop a career road map. 37 00:02:06,920 --> 00:02:10,960 This might include the projects that you would be working on as 38 00:02:10,960 --> 00:02:14,440 well as training opportunities, whether it's a formal training 39 00:02:14,760 --> 00:02:18,120 from the company, training that the company sponsors for you 40 00:02:18,600 --> 00:02:21,400 all, training with other software engineers within your 41 00:02:21,400 --> 00:02:23,080 team or within the company in general. 42 00:02:23,200 --> 00:02:25,600 They're more of an informal pipe was training. 43 00:02:25,920 --> 00:02:30,440 So yeah, following through with discussing the progress of the 44 00:02:30,440 --> 00:02:33,440 road map that and any changes that you will make along the 45 00:02:33,440 --> 00:02:35,080 way. It can be pretty dynamic. 46 00:02:35,120 --> 00:02:37,320 It should be one of the main discussion points in your one on 47 00:02:37,320 --> 00:02:39,600 ones. Personally for me, I'm from a 48 00:02:39,600 --> 00:02:43,520 non traditional CS background. So I suppose one of the turning 49 00:02:43,520 --> 00:02:45,840 points was during the time when I was trying to break into the 50 00:02:45,840 --> 00:02:48,800 field. And yeah, I was interviewing 51 00:02:49,080 --> 00:02:52,920 while learning simultaneously. And I would say it takes a lot 52 00:02:52,920 --> 00:02:55,800 of resilience. And this is something that you, 53 00:02:55,800 --> 00:02:59,520 you should, yeah, I guess all of us should continue to develop 54 00:02:59,560 --> 00:03:02,400 and continue to remind ourselves that we will. 55 00:03:02,640 --> 00:03:07,600 And we should continue to face and seek out challenges because 56 00:03:07,600 --> 00:03:11,280 it is these challenges that help us to grow, to develop technical 57 00:03:11,280 --> 00:03:14,680 skills, to develop project management skills, develop 58 00:03:14,680 --> 00:03:18,880 communication skills, develop conflict resolution skills, and 59 00:03:18,880 --> 00:03:22,400 understand about system designs as we seek out like new 60 00:03:22,400 --> 00:03:26,200 challenges, like new types of projects and unfamiliar domains. 61 00:03:26,600 --> 00:03:30,080 And as I mentioned at the beginning when I talked about 62 00:03:30,080 --> 00:03:32,800 breaking into the view and coming from a non traditional CS 63 00:03:32,800 --> 00:03:35,320 background and having to interview and learn at the same 64 00:03:35,320 --> 00:03:37,440 time, yeah, this taught me the value of resilience. 65 00:03:37,440 --> 00:03:40,040 And they also gave me the attitude that I kept to this day 66 00:03:40,280 --> 00:03:42,920 to always keep learning and always to keep seeking out new 67 00:03:42,920 --> 00:03:45,360 challenges. And I think, I hope that the 68 00:03:45,360 --> 00:03:48,960 spirit of this is embodied in the book that I've written. 69 00:03:49,160 --> 00:03:51,720 I hope that it would help. It would make things a little 70 00:03:51,720 --> 00:03:56,200 easier to give people a sense of direction, which I myself lack. 71 00:03:56,560 --> 00:03:58,360 So yeah, I would say this is one of the. 72 00:03:59,000 --> 00:04:02,120 I'm not quite sure if I describe it as a turning point exactly, 73 00:04:02,120 --> 00:04:04,520 but this is some advice that I would give to everyone. 74 00:04:05,280 --> 00:04:08,640 Hey, thank you for being part of the technological community. 75 00:04:09,080 --> 00:04:12,280 This show wouldn't be the same without your ears, and you are 76 00:04:12,280 --> 00:04:16,560 the reason this show exists. If you're loving TLJ and want to 77 00:04:16,560 --> 00:04:19,839 see it keep on growing, consider becoming a patron at 78 00:04:19,839 --> 00:04:23,760 Techledeional dot Dev Patron or buying me a coffee at 79 00:04:23,760 --> 00:04:28,600 Techledeional dot Dev Coffee. Every little bit helps field the 80 00:04:28,600 --> 00:04:32,160 research, editing, and sleepless nights that go into making this 81 00:04:32,160 --> 00:04:35,400 show the best it can be. Thanks for being the best 82 00:04:35,400 --> 00:04:37,600 listeners any podcast could ask for. 83 00:04:38,000 --> 00:04:39,920 And now let's get back to our episode. 84 00:04:40,240 --> 00:04:42,960 Wow, it's very inspiring about your story, right? 85 00:04:42,960 --> 00:04:46,240 Starting from a non CS background, actually trying to, 86 00:04:46,360 --> 00:04:49,680 you know, go to the industry. Software engineering can be 87 00:04:49,680 --> 00:04:52,840 really daunting at this time where so many things to learn. 88 00:04:53,200 --> 00:04:56,200 And not only that, now you have successfully written a book as 89 00:04:56,200 --> 00:04:59,960 well about a topic that some software engineers probably like 90 00:04:59,960 --> 00:05:02,760 afraid to do when they go to interviews, right? 91 00:05:03,040 --> 00:05:07,160 So system design, it's one of the rounds in any major big 92 00:05:07,160 --> 00:05:09,840 companies, tech companies, right, that people have to go 93 00:05:09,880 --> 00:05:12,200 through. But in the 1st place, maybe 94 00:05:12,280 --> 00:05:15,960 because the definition kind of like not so well defined, what 95 00:05:15,960 --> 00:05:18,040 is actually system design interview? 96 00:05:18,040 --> 00:05:21,560 And I know that some companies define it differently or maybe 97 00:05:21,800 --> 00:05:25,080 do the kind of test differently. But maybe in your view to level 98 00:05:25,080 --> 00:05:27,600 set our understanding, right? What is System Design Interview? 99 00:05:28,280 --> 00:05:31,320 Well, it it is an interview. It is not about coding 100 00:05:31,400 --> 00:05:34,360 obviously, but it is where you are asked to design A scalable 101 00:05:34,360 --> 00:05:37,400 and efficient software systems to solve real world problems. 102 00:05:37,760 --> 00:05:40,480 These interviews, they are commonly conducted for engineer 103 00:05:40,480 --> 00:05:42,840 roles, especially for the more senior roles where you are 104 00:05:42,840 --> 00:05:45,200 expected to have a strong understanding of architecture 105 00:05:45,200 --> 00:05:48,120 and design principles. You are typically be given a 106 00:05:48,120 --> 00:05:50,360 problem statement or scenario and you're asked to design a 107 00:05:50,360 --> 00:05:52,520 high level architecture to address requirements. 108 00:05:52,960 --> 00:05:56,560 And then you would have to deep dive into topics like 109 00:05:56,560 --> 00:05:59,280 scalability, reliability, performance with the non 110 00:05:59,280 --> 00:06:02,040 functional characteristics that is mentioned in I believe 111 00:06:02,040 --> 00:06:05,480 chapter three of the book and the goals really of a system 112 00:06:05,480 --> 00:06:06,560 design interview. Yeah. 113 00:06:06,560 --> 00:06:09,320 It's about assessing your problem solving skills, how you 114 00:06:09,360 --> 00:06:13,160 analyze a complex problem, how you identify requirements and 115 00:06:13,160 --> 00:06:14,800 how you design an appropriate solution. 116 00:06:15,200 --> 00:06:18,640 It might be about evaluating your design skills, your 117 00:06:18,640 --> 00:06:21,200 architecture and design principles, scalability, 118 00:06:21,200 --> 00:06:23,760 modality, flexibility, maintainability. 119 00:06:24,200 --> 00:06:27,400 To a lesser extent is about testing your technical knowledge 120 00:06:27,760 --> 00:06:30,560 in terms of such as in distributed systems, databases, 121 00:06:30,560 --> 00:06:33,440 networking, caching, low balancing, cloud infrastructure. 122 00:06:33,440 --> 00:06:36,400 Yes, this knowledge is good to have and in fact more important 123 00:06:36,400 --> 00:06:40,120 as to become more senior. But really it is about and it's 124 00:06:40,120 --> 00:06:42,840 about your communication skills, how effectively you communicate 125 00:06:42,840 --> 00:06:46,720 your ideas, how you explain your design decision, how you justify 126 00:06:46,720 --> 00:06:50,920 your choices to the interviewer, how you evaluate possibilities 127 00:06:50,920 --> 00:06:54,640 and discuss trade-offs. This really is about your your 128 00:06:54,640 --> 00:06:58,440 ability to think through various possibilities and discuss them 129 00:06:58,640 --> 00:07:01,240 effectively. It is really what the interview 130 00:07:01,240 --> 00:07:04,440 was looking for here. Just by listening to what you 131 00:07:04,440 --> 00:07:07,240 said, right, it seems there are plenty of things that we all 132 00:07:07,240 --> 00:07:10,680 need to take care of preparing before we even go to the 133 00:07:10,680 --> 00:07:13,040 interview, right? So I think a few key takeaways 134 00:07:13,040 --> 00:07:16,320 from me is that, yeah, the first one is like, we will be asked to 135 00:07:16,320 --> 00:07:19,400 solve real world problem. Sometimes it's a bit imaginary 136 00:07:19,400 --> 00:07:21,720 from time to time, right, depending on the interviewers, 137 00:07:22,040 --> 00:07:24,800 but it's mostly solving real world problems, right? 138 00:07:25,040 --> 00:07:28,000 Second thing is about, you know, understanding the problem, 139 00:07:28,000 --> 00:07:29,920 right? The problem solving skills, some 140 00:07:29,920 --> 00:07:33,080 system design probably asks you like a generic, high level 141 00:07:33,080 --> 00:07:35,960 abstract kind of question. Then you have to deep dive from 142 00:07:35,960 --> 00:07:37,680 there, right? And I think the third thing 143 00:07:37,680 --> 00:07:40,200 which I want to go much deeper is actually about the 144 00:07:40,200 --> 00:07:42,680 trade-offs. So I think you mentioned in your 145 00:07:42,680 --> 00:07:45,360 book that system design interview is all about 146 00:07:45,480 --> 00:07:48,720 trade-offs. Tell us how can we actually 147 00:07:48,720 --> 00:07:51,520 think about this trade off? Why is it important in system 148 00:07:51,520 --> 00:07:55,960 design? Well regarding trade-offs, there 149 00:07:55,960 --> 00:08:00,280 are many, sometimes endless possibilities in designing a 150 00:08:00,280 --> 00:08:02,680 particular system. Well, firstly, yeah, you have to 151 00:08:02,680 --> 00:08:07,040 understand what the customer is asking for, both the functional 152 00:08:07,040 --> 00:08:09,040 requirements and the non functional requirements. 153 00:08:09,440 --> 00:08:12,320 And then from there why the discussion about trade-offs 154 00:08:12,640 --> 00:08:15,240 comes in. Well you don't want to over 155 00:08:15,240 --> 00:08:17,400 engineer, you don't want to build something that the 156 00:08:17,400 --> 00:08:19,280 customer does not actually require. 157 00:08:19,600 --> 00:08:22,680 And another consideration is that everything you build that 158 00:08:22,680 --> 00:08:24,200 there are always a cost involved. 159 00:08:24,520 --> 00:08:27,640 If you were to make a system more real time, for example, it 160 00:08:27,640 --> 00:08:31,160 would be more complex, it would be more expensive and you are 161 00:08:31,160 --> 00:08:34,000 assuming that this real time performance is something which 162 00:08:34,000 --> 00:08:35,679 is actually needed by the customer. 163 00:08:36,080 --> 00:08:38,960 So for instance, if you could make the system eventually 164 00:08:38,960 --> 00:08:42,360 consistent or you can make it asynchronous, that the system 165 00:08:42,360 --> 00:08:46,720 does not have to immediately return an updated value in 166 00:08:46,720 --> 00:08:50,120 response to users input. There are certain technologies 167 00:08:50,120 --> 00:08:53,080 and certain techniques that you can use that would considerably 168 00:08:53,080 --> 00:08:57,400 reduce the cost, the complexity, it might improve availability. 169 00:08:57,760 --> 00:09:00,880 But as I mentioned, when we talk about trade-offs, really it is 170 00:09:00,880 --> 00:09:04,760 about talking about various approaches that can all software 171 00:09:05,000 --> 00:09:09,120 well address the requirements to a larger or lesser extent. 172 00:09:09,560 --> 00:09:14,040 And then talking about what you would prioritize and what you 173 00:09:14,040 --> 00:09:17,680 were deliberately payless attention to so as to ensure 174 00:09:17,680 --> 00:09:21,800 that the cost and complexity is kept and maintainability is kept 175 00:09:21,800 --> 00:09:24,640 under control. For instance, while you are 176 00:09:24,640 --> 00:09:27,400 satisfying the other non functional requirements like 177 00:09:27,400 --> 00:09:30,840 scalability, availability, security, privacy for instance 178 00:09:30,840 --> 00:09:34,480 to the desired extent. So I think very important in the 179 00:09:34,480 --> 00:09:36,200 beginning you mentioned understanding about the 180 00:09:36,200 --> 00:09:39,080 requirements first, right? The either the functional and 181 00:09:39,080 --> 00:09:42,280 the non functional requirements. So without that, probably it's 182 00:09:42,280 --> 00:09:45,080 very difficult to actually come up with the trade-offs, right? 183 00:09:45,400 --> 00:09:49,160 So solving the first problem is about the requirements and then 184 00:09:49,160 --> 00:09:52,240 we have to be able to explain. So this is probably the tough 185 00:09:52,520 --> 00:09:55,600 part because first the time is kind of like limited. 186 00:09:55,840 --> 00:09:59,160 Some people may be only have like 40 minutes, right? 187 00:09:59,200 --> 00:10:03,120 Or some have one hours, full one hour, but most likely it's going 188 00:10:03,120 --> 00:10:05,200 to be limited, right? Especially the nature of 189 00:10:05,200 --> 00:10:08,120 open-ended discussions. And the third thing is actually 190 00:10:08,120 --> 00:10:11,160 about communicating it. So maybe some tips here how to 191 00:10:11,160 --> 00:10:14,920 manage time and how can actually you communicate the trade-offs 192 00:10:14,920 --> 00:10:17,760 of your decision and priority better in the interview? 193 00:10:18,440 --> 00:10:22,120 OK, with regards to time management, the interviewer 194 00:10:22,120 --> 00:10:26,640 would deliberately give you a vague question and yeah, you 195 00:10:26,640 --> 00:10:31,360 have to agree on the scope of the discussion and that is how 196 00:10:31,360 --> 00:10:33,360 it is kept contained within an hour. 197 00:10:33,360 --> 00:10:36,600 Yeah, it is impossible to discuss a complex system in one 198 00:10:36,600 --> 00:10:38,760 hour. You got to narrow down the scope 199 00:10:39,120 --> 00:10:42,840 and the interviewer is looking for how you discuss what the 200 00:10:42,840 --> 00:10:45,120 requirements are, the functional requirements and the non 201 00:10:45,120 --> 00:10:46,720 functional requirements. Yeah. 202 00:10:46,720 --> 00:10:50,320 So you would spend a few minutes on that discussion and then 203 00:10:50,320 --> 00:10:53,680 after that, only then you will start discussing various 204 00:10:53,680 --> 00:10:56,680 possible approaches. And there are trade-offs. 205 00:10:57,160 --> 00:11:00,080 And then most likely what's going to happen is that you 206 00:11:00,080 --> 00:11:04,080 would do a deep dive into one or two of those choices. 207 00:11:04,240 --> 00:11:08,560 And this would involve sketching high level diagrams onto the 208 00:11:08,600 --> 00:11:10,840 whiteboard. Well, when you sketch down like 209 00:11:10,880 --> 00:11:13,360 the high level diagrams into the whiteboard, yeah, it is 210 00:11:13,360 --> 00:11:16,400 definitely possible to keep things really high level and 211 00:11:16,400 --> 00:11:20,240 sketch it out really quickly and gloss over many of the details. 212 00:11:20,640 --> 00:11:24,320 And then the rest of the interview would be about 213 00:11:24,400 --> 00:11:28,760 discussing this design at the desired level of abstraction 214 00:11:29,000 --> 00:11:32,040 that the interviewer is interested in, or which you, the 215 00:11:32,040 --> 00:11:34,400 interviewer might also ask for your opinion into which are the 216 00:11:34,400 --> 00:11:37,200 critical pieces that that you believe are the most interesting 217 00:11:37,200 --> 00:11:39,520 pieces of the design that you can do a deep dive into. 218 00:11:40,000 --> 00:11:43,040 And then from there, you would be drawing more detailed 219 00:11:43,040 --> 00:11:45,640 diagrams of specific components of your system. 220 00:11:46,200 --> 00:11:49,560 So this is how you would have such a discussion within 40 221 00:11:49,560 --> 00:11:52,480 minutes or one hour. Near the end of the interview 222 00:11:52,760 --> 00:11:55,520 the interviewer might start asking for additional 223 00:11:55,520 --> 00:11:59,040 requirements or he he might push a certain non functional 224 00:11:59,040 --> 00:12:02,400 requirements to the extreme. For instance, pushing how do you 225 00:12:02,400 --> 00:12:06,440 serve up 1 billion users or how do you handle millions of 226 00:12:06,440 --> 00:12:09,720 requests per second. Or you might start discussing 227 00:12:09,720 --> 00:12:12,720 about how your system would tolerate, how your system is 228 00:12:13,040 --> 00:12:16,800 resilient and how it would what are the graceful degradation 229 00:12:16,800 --> 00:12:20,280 characteristics if the certain dependencies fail or a certain 230 00:12:20,280 --> 00:12:23,280 parts of your system fail, how that will be handled. 231 00:12:23,880 --> 00:12:26,960 So yeah, there is definitely endless topics to discuss. 232 00:12:27,120 --> 00:12:31,560 But within the 40 minutes to one hour, if you are able to clarify 233 00:12:31,680 --> 00:12:35,520 the scope, clarify the requirements and design and 234 00:12:35,520 --> 00:12:38,560 architecture, well, discuss several approaches. 235 00:12:39,000 --> 00:12:42,320 They design an architecture that can satisfy the discuss 236 00:12:42,440 --> 00:12:46,560 requirements and weigh the trade-offs of your approach. 237 00:12:46,880 --> 00:12:49,760 That would be generally sufficient for the purposes of 238 00:12:49,760 --> 00:12:51,160 the interview. Right. 239 00:12:51,160 --> 00:12:54,400 I like in the beginning that you mentioned that the interviewer 240 00:12:54,400 --> 00:12:58,040 intentionally gives you a vague question, right? 241 00:12:58,320 --> 00:13:01,520 I think we all have experienced this like they they give just 242 00:13:01,520 --> 00:13:04,960 one, two sentences, design me, I don't know like Uber, OK or 243 00:13:04,960 --> 00:13:07,320 design me like Google Maps or something like that. 244 00:13:07,600 --> 00:13:10,840 I think the key here is to ask clarifying questions, right? 245 00:13:10,840 --> 00:13:14,800 Don't just assume you know what they are asking, always ask in 246 00:13:14,800 --> 00:13:17,880 the beginning probably right? Have a back and forth what to 247 00:13:17,880 --> 00:13:20,960 prioritize because the scope can be super big and you have to 248 00:13:20,960 --> 00:13:23,360 agree on a level set of understanding right? 249 00:13:23,360 --> 00:13:25,840 Like what is the scope? What is the priority for the 250 00:13:25,840 --> 00:13:28,960 interview session? And I think just by listening to 251 00:13:28,960 --> 00:13:31,680 the question right some of us will feel anxious actually. 252 00:13:31,760 --> 00:13:35,400 Like OK I don't know the answer fully but I also don't want to 253 00:13:35,560 --> 00:13:38,520 give no answer. How do you actually manage this 254 00:13:38,520 --> 00:13:42,320 kind of stress and anxiety? And actually also sometimes you 255 00:13:42,320 --> 00:13:44,120 don't know the answer altogether. 256 00:13:44,360 --> 00:13:46,880 Maybe some tips from you how we can manage all this? 257 00:13:47,520 --> 00:13:50,920 Well, the interviewer is generally not looking for domain 258 00:13:50,920 --> 00:13:53,840 knowledge unless the job description specifically states 259 00:13:53,840 --> 00:13:57,360 that this domain knowledge is required and you are unlikely to 260 00:13:57,360 --> 00:14:01,120 be building the system that is asked during the system design 261 00:14:01,120 --> 00:14:03,120 interview. So that's not the purpose of the 262 00:14:03,120 --> 00:14:06,920 system design interview. The purpose, as we went over, is 263 00:14:06,920 --> 00:14:09,600 to assess your communication skills. 264 00:14:09,600 --> 00:14:13,080 Assess your understanding of system design in general. 265 00:14:13,560 --> 00:14:17,120 And so yeah, you are not expected to know everything. 266 00:14:17,160 --> 00:14:20,960 So when you come across like areas of a of a particular 267 00:14:20,960 --> 00:14:24,160 system where you do not possess a certain domain knowledge, 268 00:14:24,560 --> 00:14:27,040 right. You can start by assuming that 269 00:14:27,040 --> 00:14:29,720 there is a black box that accepts inputs and returns 270 00:14:29,720 --> 00:14:31,760 outputs. And you can state your 271 00:14:31,760 --> 00:14:34,680 assumptions about this box, both the functional and non 272 00:14:34,680 --> 00:14:36,480 functional characteristics of this box. 273 00:14:36,720 --> 00:14:39,800 And you can say that this is your staple point in how you 274 00:14:39,800 --> 00:14:43,280 approach this question. And you can investigate further 275 00:14:43,280 --> 00:14:46,440 about like how these particular systems are designed and 276 00:14:46,440 --> 00:14:47,880 implemented. Yes. 277 00:14:47,920 --> 00:14:49,960 So that's typically one approach. 278 00:14:50,240 --> 00:14:53,840 Another approach is you will be asked to possibilities of how 279 00:14:53,840 --> 00:14:56,760 would you design and implement a particular domain which are 280 00:14:56,760 --> 00:14:59,040 unfamiliar with. You can start building from 281 00:14:59,040 --> 00:15:01,880 first principles. So for instance, like if you are 282 00:15:01,880 --> 00:15:05,120 asked to design A pathfinding for Google Maps or if I asked to 283 00:15:05,120 --> 00:15:08,680 design A rate limiter. Yeah, you can start by designing 284 00:15:08,680 --> 00:15:13,120 an algorithm for a single user and then consider how to scale 285 00:15:13,120 --> 00:15:17,320 it to a large number of users, what data you would need and how 286 00:15:17,320 --> 00:15:20,120 you would handle the data. You could then discuss 287 00:15:20,120 --> 00:15:23,480 trade-offs of your approach. The interviewer might sometimes 288 00:15:23,480 --> 00:15:25,200 actually help with the domain knowledge. 289 00:15:25,360 --> 00:15:28,760 And then the question, then the discussion then becomes like how 290 00:15:28,760 --> 00:15:31,600 you take that knowledge, how you critically evaluate the 291 00:15:31,600 --> 00:15:34,800 approaches that the interviewer presented to you, the pros and 292 00:15:34,800 --> 00:15:37,120 cons, and how will you build a system around it. 293 00:15:37,400 --> 00:15:39,680 And it's also about asking the right questions. 294 00:15:40,240 --> 00:15:43,360 Then how about managing anxiety? Like, do you have some tips to 295 00:15:43,360 --> 00:15:46,760 like, I don't know, do the preparation, maybe a good rest 296 00:15:46,800 --> 00:15:49,800 or maybe, I don't know, like do you have some tips that we all 297 00:15:49,800 --> 00:15:52,600 can learn how to manage performance anxiety in the 298 00:15:52,720 --> 00:15:56,720 system design interview? Well, experience definitely 299 00:15:56,720 --> 00:15:59,080 helps. One of my suggestions would be 300 00:15:59,080 --> 00:16:02,360 to practice with your friends, with fellow software engineers 301 00:16:02,800 --> 00:16:06,720 or sometimes perhaps even with people, non-technical people 302 00:16:06,720 --> 00:16:10,200 within your company, but maybe even with your friends or family 303 00:16:10,200 --> 00:16:13,440 who are not in the tech view at all, but however who are 304 00:16:13,440 --> 00:16:17,000 interested to help you succeed. This is how, in fact, a pretty 305 00:16:17,000 --> 00:16:20,400 valuable way for you to train your communication skills. 306 00:16:20,520 --> 00:16:24,080 And this is something that is sometimes also assess your 307 00:16:24,080 --> 00:16:27,480 ability to explain complex technical concepts to 308 00:16:27,480 --> 00:16:30,840 non-technical people, which is actually a pretty relevant skill 309 00:16:30,840 --> 00:16:33,200 on the job, particularly as you become more senior. 310 00:16:33,640 --> 00:16:36,640 So yeah, I suppose, yeah, that would be one good way you can 311 00:16:36,640 --> 00:16:39,440 handle performance anxiety. Keep getting as much experience 312 00:16:39,440 --> 00:16:41,960 as you can. Well, another way would be to 313 00:16:41,960 --> 00:16:45,800 increase your knowledge. So the system design interview 314 00:16:45,800 --> 00:16:48,800 book and other resources like it are a good starting point. 315 00:16:49,200 --> 00:16:53,400 They can present you with some templates and some mental models 316 00:16:53,520 --> 00:16:56,800 that you can use as a starting point for most system design 317 00:16:56,800 --> 00:17:00,120 questions. And if you were to follow the 318 00:17:00,120 --> 00:17:04,920 industry of topics that you find yourself to be more interested 319 00:17:04,920 --> 00:17:09,480 in, for example, in a database design or development or AI or 320 00:17:09,480 --> 00:17:11,839 LMS, that which is the hot topic right now. 321 00:17:12,240 --> 00:17:15,280 If you were more interested in infrastructure side of things, 322 00:17:15,280 --> 00:17:19,400 in DevOps for instance, then I think continuing to learn and 323 00:17:19,400 --> 00:17:22,839 continuing to gain knowledge and continuing to discuss your 324 00:17:22,839 --> 00:17:26,560 learnings with other software engineers would give you the 325 00:17:26,560 --> 00:17:29,960 confidence that you need when you are entering a discussion 326 00:17:30,080 --> 00:17:33,000 where you are discussing a topic where you do not have like all 327 00:17:33,000 --> 00:17:34,920 of the understanding, all the details. 328 00:17:35,240 --> 00:17:38,200 So yeah, after a while, these discussions would become 329 00:17:38,200 --> 00:17:41,680 natural, more natural to you. And yeah, you would become 330 00:17:41,680 --> 00:17:45,520 accustomed to handling unfamiliarity, which is in fact 331 00:17:45,520 --> 00:17:48,680 something that you should get used to progress in your career. 332 00:17:48,920 --> 00:17:51,480 And yeah, so these are some tips that I would give to handle a 333 00:17:51,480 --> 00:17:54,760 performance society. Yeah, familiarity and you know, 334 00:17:54,760 --> 00:17:58,040 getting used to being asked these kind of questions as I 335 00:17:58,040 --> 00:18:00,760 think it's very important especially for those senior who 336 00:18:01,000 --> 00:18:03,760 have already day job, right. So you work on a particular 337 00:18:03,760 --> 00:18:06,120 systems most of the time, you know, from the front to the 338 00:18:06,120 --> 00:18:08,560 back, right. But system design is all about 339 00:18:08,560 --> 00:18:11,760 preparation, I think and resources like your book 340 00:18:11,760 --> 00:18:15,560 probably and maybe a few other online resources, you can also 341 00:18:15,560 --> 00:18:18,160 use them as a guide like templates and mental model. 342 00:18:18,160 --> 00:18:20,720 I like how you say that. So I think it's very good to 343 00:18:20,720 --> 00:18:24,160 have preparation and also, yeah, don't forget to actually have a 344 00:18:24,160 --> 00:18:27,520 good rest, you know, like be humble because you may not know 345 00:18:27,520 --> 00:18:30,120 everything. So I think just accept that you 346 00:18:30,120 --> 00:18:31,920 probably won't be able to answer everything. 347 00:18:32,480 --> 00:18:36,280 So in your book you also cover a few principles which I find 348 00:18:36,280 --> 00:18:39,280 really, really useful and insightful that can give us like 349 00:18:39,280 --> 00:18:41,640 a guide how should we approach system design? 350 00:18:41,960 --> 00:18:44,320 Maybe if you can mention, I know that we have covered some of 351 00:18:44,320 --> 00:18:46,040 them. Maybe is there any other 352 00:18:46,040 --> 00:18:49,560 principle that you think we all should bear in mind whenever we 353 00:18:49,560 --> 00:18:53,680 go to system interview? Well, I'm not sure if I would 354 00:18:53,680 --> 00:18:57,280 like to approach the topic or this way and insist on a certain 355 00:18:57,280 --> 00:19:01,480 dogma because that is the anti PCs of what a system design 356 00:19:01,480 --> 00:19:03,840 interviews or what system design is in general. 357 00:19:04,200 --> 00:19:07,520 I suppose that if I were to push like the most general principle, 358 00:19:07,520 --> 00:19:10,240 it is all about trade-offs. Just always remember that it is 359 00:19:10,240 --> 00:19:12,800 not about perfection, it is about trade-offs. 360 00:19:13,320 --> 00:19:17,200 And yeah, your ability to understand this, the pros and 361 00:19:17,200 --> 00:19:21,880 cons of any approach that you choose, to be able to discuss 362 00:19:22,000 --> 00:19:26,840 many possible approaches, to be creative and to be conscious of 363 00:19:27,160 --> 00:19:29,960 the current and possible of future requirements. 364 00:19:30,360 --> 00:19:34,040 Yeah, I, I think this is about what it is really and being able 365 00:19:34,040 --> 00:19:37,120 to communicate them clearly and concisely. 366 00:19:37,480 --> 00:19:40,520 So, OK, if I were to summarize what I just said, it, it is 367 00:19:40,520 --> 00:19:43,960 really about trade-offs and it is really about clear 368 00:19:43,960 --> 00:19:46,520 communication. As you mentioned, if after 369 00:19:46,520 --> 00:19:49,800 having one more thing you will not know everything and you will 370 00:19:49,800 --> 00:19:51,400 not expect others to know everything. 371 00:19:51,640 --> 00:19:55,200 Everyone is continuously learning in our industry, in the 372 00:19:55,200 --> 00:19:58,840 tech industry, yeah, new technologies emerge and they do 373 00:19:58,840 --> 00:20:02,360 so in a rather unpredictable pace, These trends and yeah, 374 00:20:02,360 --> 00:20:04,440 start-ups just suddenly pop up all around them. 375 00:20:04,680 --> 00:20:08,240 Whether it is about machine learning and the Internet of 376 00:20:08,240 --> 00:20:14,840 Things or Metaverse not chain and now about AIRNLMS, these 377 00:20:15,080 --> 00:20:17,800 topics we all need to continuously keep learning them. 378 00:20:18,080 --> 00:20:21,480 And understand how they are applied to systems and the 379 00:20:21,480 --> 00:20:25,320 trade-offs and be able to communicate clearly about our 380 00:20:25,320 --> 00:20:26,680 thoughts. Right. 381 00:20:26,680 --> 00:20:28,920 So thanks for the very great tips, right? 382 00:20:28,920 --> 00:20:31,560 So it's all about trade-offs. Understand the current and 383 00:20:31,560 --> 00:20:33,800 future requirements, communicate it clearly. 384 00:20:33,800 --> 00:20:36,960 I think communication for some of us can be very daunting, 385 00:20:36,960 --> 00:20:38,960 right? How to explain your technical 386 00:20:38,960 --> 00:20:41,560 thought process into something that other people can also 387 00:20:41,560 --> 00:20:44,400 understand? What I find sometimes useful as 388 00:20:44,400 --> 00:20:47,360 well, right? You probably can understand what 389 00:20:47,360 --> 00:20:50,480 the problem that the company or the team is solving and try to 390 00:20:50,480 --> 00:20:52,960 relate back from there. Because I think in some 391 00:20:52,960 --> 00:20:55,960 interviews I experienced, at least they're trying to solve a 392 00:20:55,960 --> 00:20:58,680 problem or they have solved a particular problem and they just 393 00:20:58,680 --> 00:21:01,080 want to validate their approach with you, right? 394 00:21:01,480 --> 00:21:05,080 So maybe for some of you who can maybe do some research first 395 00:21:05,080 --> 00:21:08,000 what the company is doing, what the team is doing, and try to 396 00:21:08,000 --> 00:21:10,520 come up with some various different combinations of 397 00:21:10,520 --> 00:21:13,400 answers, potential answers that you can prepare. 398 00:21:13,720 --> 00:21:15,600 And also don't forget the ultimate tips. 399 00:21:15,760 --> 00:21:19,360 Try to ask around from people who have done the interviews at 400 00:21:19,360 --> 00:21:21,800 that particular company. I think it's always useful. 401 00:21:22,240 --> 00:21:25,160 So maybe let's move a little bit to the non functional 402 00:21:25,160 --> 00:21:27,960 requirements. I think probably this is one of 403 00:21:27,960 --> 00:21:31,920 the difficult topic in the system design interview simply 404 00:21:31,920 --> 00:21:33,800 because again, there are many trade-offs. 405 00:21:34,040 --> 00:21:36,280 Maybe tell us a little bit more about non functional 406 00:21:36,400 --> 00:21:38,880 requirements. Which non functional requirement 407 00:21:38,880 --> 00:21:43,640 we should be prepared a lot more and which one that you think is 408 00:21:43,640 --> 00:21:45,920 something that interviewers always ask? 409 00:21:46,560 --> 00:21:50,200 I believe the topic of scalability pretty much almost 410 00:21:50,200 --> 00:21:54,680 always comes up about how you were cost efficiently and how 411 00:21:54,680 --> 00:21:58,120 you design your system to easily and cost efficiently adjust its 412 00:21:58,120 --> 00:22:01,960 hardware utilization to serve the request load. 413 00:22:02,200 --> 00:22:04,120 That is one the first few dimension in the book. 414 00:22:04,120 --> 00:22:06,760 Scalability, availability, performance, latency, 415 00:22:06,800 --> 00:22:10,040 throughput, yeah. So these are some of the most 416 00:22:10,160 --> 00:22:13,080 common topics that we discussed. But then you would also talk 417 00:22:13,080 --> 00:22:16,400 about that the trade-offs that you can make, the complexity, 418 00:22:16,400 --> 00:22:19,240 maintainability, debacability and testability of your system 419 00:22:19,600 --> 00:22:23,440 and how you were trade off like these certain non functional 420 00:22:23,440 --> 00:22:25,880 characteristics. For instance, can you make your 421 00:22:25,880 --> 00:22:29,040 system less available in order to reduce its cost? 422 00:22:29,280 --> 00:22:31,640 Would they satisfy the customer's requirements? 423 00:22:31,720 --> 00:22:35,360 The customer often, both in the interview and in real life, they 424 00:22:35,360 --> 00:22:37,960 will not be fully aware of like these non functional 425 00:22:37,960 --> 00:22:41,560 requirements and what they can possibly sacrifice in order to 426 00:22:41,560 --> 00:22:43,920 optimize for certain other characteristics. 427 00:22:44,360 --> 00:22:47,120 I didn't mention consistency so well. 428 00:22:47,120 --> 00:22:50,200 Do you need a strong consistency or is eventual consistency good 429 00:22:50,200 --> 00:22:53,480 enough when a particular user arrives stayed out of the 430 00:22:53,480 --> 00:22:55,640 system? Must these updates be made 431 00:22:55,640 --> 00:22:59,640 available immediately at a high cost and high complexity? 432 00:23:00,120 --> 00:23:04,880 Or can the system be designed to propagate these updates to be 433 00:23:04,880 --> 00:23:07,080 non blocking, to be asynchronous, to propagate these 434 00:23:07,080 --> 00:23:10,800 updates after some time so as to save on a hardware cost? 435 00:23:11,040 --> 00:23:14,040 Do you actually need to serve every request or can you apply 436 00:23:14,040 --> 00:23:17,240 or sampling or can you apply approximation techniques? 437 00:23:17,400 --> 00:23:21,400 Yeah, this can also save on a cost and well, to a lesser 438 00:23:21,400 --> 00:23:24,360 extent, you may need to talk about the security and privacy 439 00:23:24,360 --> 00:23:26,400 characteristics. Most of the time, in my 440 00:23:26,400 --> 00:23:29,520 experience, this is not a strong focus point, but what is 441 00:23:29,520 --> 00:23:32,800 important is that you express your awareness of these 442 00:23:32,800 --> 00:23:36,400 requirements and you are able to discuss them for some time. 443 00:23:36,400 --> 00:23:38,680 Yeah, it will discuss them to the desired level that the 444 00:23:38,680 --> 00:23:40,960 interview desires should these topics come up. 445 00:23:41,360 --> 00:23:44,120 So yeah, I've spoken a lot about non functional requirements and 446 00:23:44,120 --> 00:23:47,080 in general it's hard to pin down exactly what will be considered 447 00:23:47,080 --> 00:23:49,120 important and what is considered unimportant. 448 00:23:49,120 --> 00:23:52,480 I believe within the book and within many similar resources, 449 00:23:52,760 --> 00:23:56,320 they have already condensed the non functional requirements to 450 00:23:56,320 --> 00:23:59,480 this list. And this is the most, well this 451 00:23:59,480 --> 00:24:02,000 is the list of important requirements or characteristics 452 00:24:02,000 --> 00:24:03,680 that one must discuss about a system. 453 00:24:04,000 --> 00:24:06,800 And should there be other non functional requirements? 454 00:24:06,880 --> 00:24:09,640 Yeah, this can be something that might be discussed like near the 455 00:24:09,680 --> 00:24:13,080 end of the interview as a bonus topic, or probably not at all. 456 00:24:13,800 --> 00:24:15,360 Yeah. So I think, yeah, just what you 457 00:24:15,360 --> 00:24:19,200 mentioned, right, the first few that we probably need to focus a 458 00:24:19,200 --> 00:24:22,600 lot more on is like scalability, availability, right, how to make 459 00:24:22,600 --> 00:24:27,480 your system maybe 24/7 up and oh, how performance, yeah, Oh 460 00:24:27,480 --> 00:24:29,400 yeah. And how not to, if it's allowed 461 00:24:29,400 --> 00:24:31,600 by the requirements and the performance, right? 462 00:24:31,600 --> 00:24:34,520 Your speed, latency, right? Also like throughput, how many 463 00:24:34,520 --> 00:24:36,960 requests per second? And sometimes it's always 464 00:24:36,960 --> 00:24:41,480 helpful to be able to know how you calculate number, like 465 00:24:41,480 --> 00:24:43,920 requests per second, right? Because the interview might just 466 00:24:43,920 --> 00:24:47,960 give you like, OK, millions of users a day, but that doesn't 467 00:24:47,960 --> 00:24:50,120 mean like a million requests per second, right? 468 00:24:50,120 --> 00:24:53,720 So you always have to come up with some explanation how do you 469 00:24:53,720 --> 00:24:57,080 derive that request per second. So I think this is all very 470 00:24:57,240 --> 00:24:58,840 common topics, security, privacy. 471 00:24:58,880 --> 00:25:02,280 Also, in my opinion, unless the company really deals a lot, I 472 00:25:02,280 --> 00:25:05,320 don't know, like with secure data, you know, like PII and 473 00:25:05,320 --> 00:25:07,600 things like that, probably they won't ask too much. 474 00:25:07,880 --> 00:25:10,960 But yeah, do prepare know about Oauth and things like that. 475 00:25:11,320 --> 00:25:14,280 So I think in your book you cover quite a number of various 476 00:25:14,280 --> 00:25:17,960 topics, right from the simplest to the most difficult one. 477 00:25:18,200 --> 00:25:22,400 And one of the probably difficult one to also answer is 478 00:25:22,400 --> 00:25:26,560 about the consistency. So CAP TRM probably is commonly 479 00:25:26,800 --> 00:25:30,280 asked or ACID principle, right. So maybe in your view, how do we 480 00:25:30,280 --> 00:25:33,720 tackle consistency much better in the system interview? 481 00:25:34,600 --> 00:25:37,640 Well, the interview is not. Firstly, it's not about testing 482 00:25:37,640 --> 00:25:42,040 whether you know the dictionary definitions of cap, TRM or acid. 483 00:25:42,360 --> 00:25:45,120 There would not be any. Well, in my opinion, not too 484 00:25:45,120 --> 00:25:47,480 much value divides. So I'm being able to recite 485 00:25:47,480 --> 00:25:50,280 these definitions. But you're not going to think 486 00:25:50,280 --> 00:25:52,800 that one candidate is better than another because the the 487 00:25:52,800 --> 00:25:56,200 first candidate was able to recite like this knowledge from 488 00:25:56,200 --> 00:25:57,680 wrote while the other candidate cannot. 489 00:25:58,080 --> 00:26:02,840 As I say, it is really about the awareness of these principles in 490 00:26:02,840 --> 00:26:07,160 general and how they are applied to system design and what 491 00:26:07,160 --> 00:26:10,040 trade-offs then are applicable with regards to these 492 00:26:10,040 --> 00:26:11,200 principles. Yeah. 493 00:26:11,200 --> 00:26:15,800 So about as you mentioned ACID, so ACID is applicable to 494 00:26:15,880 --> 00:26:20,120 relational databases and you would talk about ACID or the 495 00:26:20,120 --> 00:26:23,800 requirements for ACID if this is something that this is in the 496 00:26:23,840 --> 00:26:26,040 list of nonfunctional requirements that you need 497 00:26:26,040 --> 00:26:28,200 strong consistency in particular. 498 00:26:28,560 --> 00:26:33,000 And then you will talk about the trade-offs of a having ACID or 499 00:26:33,000 --> 00:26:38,120 having a relational databases. For instance, in most cases, in 500 00:26:38,120 --> 00:26:41,800 most implementations, all of the data has to fit into a single 501 00:26:41,800 --> 00:26:45,800 host, a single right replica. So their rights are typically 502 00:26:45,800 --> 00:26:49,080 pretty difficult to scale. But the reads are fairly easy to 503 00:26:49,080 --> 00:26:51,200 scale. But if you were to follow the 504 00:26:51,200 --> 00:26:53,160 approach where the reads are easy to scale, where you start 505 00:26:53,160 --> 00:26:56,080 implementing heat replicas, then the system is no longer, it 506 00:26:56,080 --> 00:26:58,200 gives up the strong consistency property. 507 00:26:58,320 --> 00:27:01,760 It becomes eventually consistent as the updates take some seconds 508 00:27:01,760 --> 00:27:05,400 to propagate. So then just being able to talk 509 00:27:05,400 --> 00:27:08,760 about these trade-offs, this is something that is part of, well 510 00:27:08,760 --> 00:27:10,600 system design discussions in general. 511 00:27:10,840 --> 00:27:14,080 And if a system did not have ACID properties, well, we start 512 00:27:14,080 --> 00:27:18,200 talking about no sequel. And the idea of a no sequel is 513 00:27:18,200 --> 00:27:22,000 the general idea is that you are making some trade-offs against 514 00:27:22,000 --> 00:27:25,040 ACID to optimize for other properties of the system. 515 00:27:25,360 --> 00:27:29,600 In particular, being able to design or distributed database 516 00:27:29,680 --> 00:27:32,040 more easily. If you were to try designing a 517 00:27:32,040 --> 00:27:35,440 distributed database with relational databases, yeah, that 518 00:27:35,440 --> 00:27:39,040 has been done multiple times. However, it typically comes with 519 00:27:39,080 --> 00:27:43,120 pretty heavy trade-offs. In summary, yes, certainly it is 520 00:27:43,120 --> 00:27:47,920 essential to understand the overall idea and purpose of 521 00:27:48,080 --> 00:27:53,480 various common paradigms like catheorum or acid, but the main 522 00:27:53,480 --> 00:27:57,040 importance is not in knowing their exact definitions, but in 523 00:27:57,040 --> 00:27:59,800 knowing how they are applied in system design. 524 00:28:00,520 --> 00:28:02,320 I think that's a very important thing, right? 525 00:28:02,320 --> 00:28:04,840 So be aware about all these, right? 526 00:28:04,840 --> 00:28:07,400 You don't say like, I don't know about all those, but be aware, 527 00:28:07,400 --> 00:28:09,640 try to be able to understand at the high level. 528 00:28:10,040 --> 00:28:12,880 But yeah, hopefully the interviewer won't dig you deeper 529 00:28:12,880 --> 00:28:15,520 into definitions, right? I know that in your book you 530 00:28:15,520 --> 00:28:18,880 also explain that this book is not particularly just for the 531 00:28:18,880 --> 00:28:21,720 people who want to do system interview, but also for the 532 00:28:21,720 --> 00:28:25,600 interviewer to get some tips how we can do system design better, 533 00:28:25,600 --> 00:28:27,600 right? Because there are variations of 534 00:28:27,600 --> 00:28:29,440 how interviewer does the system design. 535 00:28:29,440 --> 00:28:32,280 Some focus a lot more on theory, some focus a lot more on 536 00:28:32,280 --> 00:28:35,040 practicality, some focus on imaginary problem. 537 00:28:35,320 --> 00:28:38,240 So hopefully by reading this book interview also get a good 538 00:28:38,240 --> 00:28:40,480 idea how we can do a system design better. 539 00:28:41,040 --> 00:28:43,680 So you just mentioned a few things about database. 540 00:28:43,680 --> 00:28:46,840 In my experience, database is always challenging, right? 541 00:28:46,840 --> 00:28:49,480 It's probably the first bottleneck that you will see 542 00:28:49,480 --> 00:28:52,360 whenever you build a more like scalable performance system. 543 00:28:52,760 --> 00:28:56,200 So from your point of view, how should we start thinking about 544 00:28:56,200 --> 00:28:59,440 solving database related topics in the system design? 545 00:28:59,760 --> 00:29:02,640 Because most likely that you will start with single database 546 00:29:02,640 --> 00:29:05,040 and then you because of some reasons for the requirements, 547 00:29:05,040 --> 00:29:06,240 right? You handle like lots of 548 00:29:06,240 --> 00:29:08,520 requests. Is there a thought process how 549 00:29:08,520 --> 00:29:10,920 we can tackle this database scaling problem? 550 00:29:11,520 --> 00:29:15,320 Well, the system design interview for the purposes of 551 00:29:15,320 --> 00:29:19,000 our discussion, well, it's not about designing databases 552 00:29:19,000 --> 00:29:21,160 themselves. To clarify that would be a 553 00:29:21,320 --> 00:29:23,960 totally different discussion. But it is about, yeah, selecting 554 00:29:23,960 --> 00:29:28,080 the correct database for your non functional requirements. 555 00:29:28,440 --> 00:29:31,640 Again, it is about trade-offs. Database choice is all about 556 00:29:31,640 --> 00:29:34,480 trade-offs. And yeah, you would typically 557 00:29:34,480 --> 00:29:36,480 start with way. If you were to say you're gonna 558 00:29:36,480 --> 00:29:38,800 start with sequel, it is typically because of the 559 00:29:38,800 --> 00:29:41,520 simplicity. So you were consider making your 560 00:29:41,520 --> 00:29:44,640 system less complex. It would be for a system that 561 00:29:44,640 --> 00:29:47,800 they're starting out with a few users and you're trying to bring 562 00:29:47,800 --> 00:29:50,960 it to market quickly, prove the product market fit. 563 00:29:51,120 --> 00:29:54,640 And as you scale up as the request, the number of users or 564 00:29:54,640 --> 00:29:57,760 the request load increases, then you're going to have to start 565 00:29:57,760 --> 00:30:00,840 making some trade-offs against the asset properties of the 566 00:30:00,840 --> 00:30:05,440 relational DB to optimize for certain use cases, the most 567 00:30:05,440 --> 00:30:08,720 common use cases of your system. And then this is where you start 568 00:30:08,720 --> 00:30:13,480 talking about the various types of databases of no SQL databases 569 00:30:13,760 --> 00:30:16,320 and yeah, their various properties and trade-offs. 570 00:30:16,320 --> 00:30:20,000 Are you going to go for in memory a key value database like 571 00:30:20,000 --> 00:30:21,880 Redis? Are you going to go for a 572 00:30:21,880 --> 00:30:26,520 database with colonial storage like Cassandra or are you going 573 00:30:26,520 --> 00:30:29,240 to go with for a database that is unstructured? 574 00:30:29,320 --> 00:30:32,040 That's key value by unstructured like Mongo DB. 575 00:30:32,400 --> 00:30:35,400 And this would typically depend on your specific nonfunctional 576 00:30:35,400 --> 00:30:37,400 requirements. Is your system more read heavy 577 00:30:37,600 --> 00:30:40,720 or is it more like heavy for instance that you will select 578 00:30:40,720 --> 00:30:42,880 the appropriate database to suit that requirement? 579 00:30:43,200 --> 00:30:44,720 What is the latency requirements? 580 00:30:44,720 --> 00:30:48,960 The P99 requirements must every user request be responded to 581 00:30:49,120 --> 00:30:51,920 immediately. Then you will start looking into 582 00:30:51,920 --> 00:30:56,160 in memory databases such as Redis or can it be eventually 583 00:30:56,160 --> 00:30:58,240 consistent? Can it be asynchronous? 584 00:30:58,520 --> 00:31:02,240 That is actually one of the main questions that you were asked 585 00:31:02,240 --> 00:31:04,880 you were trying to ask. You will try to discuss like 586 00:31:04,880 --> 00:31:08,160 which parts of the system need to be real time and which parts 587 00:31:08,360 --> 00:31:10,600 do not need to be real time. They can eventually become 588 00:31:10,600 --> 00:31:13,920 virtually consistent and then you can start introducing event 589 00:31:13,920 --> 00:31:19,120 streaming approaches like Kafka and then Kafka feeding to a 590 00:31:19,120 --> 00:31:21,840 HDFS. And this would considerably 591 00:31:21,840 --> 00:31:25,280 reduce the cost and complexity as compared to trying to build a 592 00:31:25,280 --> 00:31:28,440 real time high performance, low latency system. 593 00:31:28,840 --> 00:31:32,040 And for approaches that when if you're not able to do this, then 594 00:31:32,040 --> 00:31:34,920 you you have no choice but to increase the cost and complexity 595 00:31:34,920 --> 00:31:36,720 overall. And there's one more thing I 596 00:31:36,720 --> 00:31:40,440 wanted to mention. Lastly, we talked about sampling 597 00:31:40,440 --> 00:31:42,920 an approximation earlier, and this is certainly something you 598 00:31:42,920 --> 00:31:45,960 should try to bring up, even if it might seem obvious to you 599 00:31:45,960 --> 00:31:48,400 that the sometimes you should not make assumptions. 600 00:31:48,400 --> 00:31:50,840 As we say, don't make assumptions in the requirements. 601 00:31:51,040 --> 00:31:53,920 Always clarify. If you can do sampling and 602 00:31:53,920 --> 00:31:58,000 approximations, then this dramatically reduces the 603 00:31:58,000 --> 00:32:01,920 scalability issues and you will most likely in the purpose of 604 00:32:01,920 --> 00:32:05,280 the interview, you will probably discuss the possible scenarios 605 00:32:05,280 --> 00:32:08,480 where you can apply what happens if you can apply sampling and 606 00:32:08,480 --> 00:32:10,440 approximation? How will your design change 607 00:32:10,720 --> 00:32:13,640 versus what happens if you cannot go with this approach? 608 00:32:13,680 --> 00:32:15,720 Yeah. What will be your design choices 609 00:32:15,720 --> 00:32:18,000 then? So yeah, in the end it all comes 610 00:32:18,000 --> 00:32:20,760 down to discussing various possible requirements, 611 00:32:20,800 --> 00:32:24,320 especially non functional requirements and how your data 612 00:32:24,320 --> 00:32:27,600 voice choice would be different and how the overall system 613 00:32:27,600 --> 00:32:30,560 architecture will be different with regards like to different 614 00:32:30,560 --> 00:32:33,080 sets of non functional requirements and the different 615 00:32:33,080 --> 00:32:34,480 trade-offs that you're trying to make. 616 00:32:35,160 --> 00:32:37,200 Right. So I think you cover a lot of 617 00:32:37,200 --> 00:32:39,200 things that are very, very important and useful. 618 00:32:39,200 --> 00:32:42,240 I think about database, right? Because I think not many people 619 00:32:42,240 --> 00:32:45,560 have the luxury of experiencing, you know, working on systems 620 00:32:45,560 --> 00:32:48,840 with complicated database scaling kind of a challenge. 621 00:32:49,200 --> 00:32:52,240 So I think in your book you have cover a number of topics, which 622 00:32:52,280 --> 00:32:55,560 I'm sure some of us, if you read the book, you will get some good 623 00:32:55,560 --> 00:32:58,640 ideas how you can tackle these questions much better in your 624 00:32:58,640 --> 00:33:01,320 next interview. So always check out database 625 00:33:01,320 --> 00:33:04,600 problem because I think that's one of the key criteria on how 626 00:33:04,600 --> 00:33:07,680 you can actually make your system more scalable, more 627 00:33:07,680 --> 00:33:11,760 available and more performant. So I think another important 628 00:33:11,760 --> 00:33:14,920 thing these days is about designing your services right 629 00:33:15,080 --> 00:33:18,160 and also handling distributed transactions, so to speak. 630 00:33:18,400 --> 00:33:21,040 So many people these days talk about monolith versus micro 631 00:33:21,040 --> 00:33:23,120 service, right? When you have a lot of services, 632 00:33:23,360 --> 00:33:27,320 how do you ensure transactions are kept as atomic as possible? 633 00:33:27,400 --> 00:33:30,240 Probably if it is possible. So how do you tackle this kind 634 00:33:30,240 --> 00:33:32,120 of distributed transaction questions? 635 00:33:32,760 --> 00:33:37,680 Well, it helps to know a few of the general approaches that you 636 00:33:37,680 --> 00:33:39,960 would take regarding distributed transactions. 637 00:33:40,280 --> 00:33:42,480 And yeah, that is covered in the book. 638 00:33:42,840 --> 00:33:45,880 So if you were to know these few high level approaches, you can 639 00:33:45,880 --> 00:33:48,200 bring them up. But before you do that again, 640 00:33:48,200 --> 00:33:51,720 you should clarify whether you need distributed transactions at 641 00:33:51,720 --> 00:33:53,520 all. You should explain what the 642 00:33:53,520 --> 00:33:56,840 purpose of a distributed transaction is and why you 643 00:33:56,840 --> 00:33:58,840 believe it will be needed for your system. 644 00:33:59,280 --> 00:34:02,800 And then you will explain without the possible approaches 645 00:34:02,960 --> 00:34:05,200 to implementing it within your system design. 646 00:34:05,560 --> 00:34:08,520 In my experience, you do not necessarily have to go into the 647 00:34:08,520 --> 00:34:11,960 specifics of anything more complex than throwing in an 648 00:34:11,960 --> 00:34:16,239 event streaming such as Kafka and then you are feeding that to 649 00:34:16,400 --> 00:34:18,920 a database. Well, a distributed database for 650 00:34:18,920 --> 00:34:21,360 further data processing, downstream processing. 651 00:34:21,440 --> 00:34:24,320 That is the clear as far as you would go, but it would 652 00:34:24,320 --> 00:34:27,880 definitely be valuable to learn about orchestration versus 653 00:34:27,880 --> 00:34:30,400 choreography approach of distributed transactions. 654 00:34:30,400 --> 00:34:33,760 It shows the depth of your understanding and it shows the 655 00:34:33,760 --> 00:34:36,840 awareness that you can bring up these couple of approaches and 656 00:34:36,840 --> 00:34:40,840 talk about their pros and cons and how that would solve the 657 00:34:40,840 --> 00:34:45,400 issue of like having to ensure consistency between multiple 658 00:34:45,400 --> 00:34:48,840 services in your overall service oriented architecture. 659 00:34:49,120 --> 00:34:51,239 Yeah. And can we, as you mentioned, 660 00:34:51,400 --> 00:34:54,520 the trade-offs between monoliths and micro services? 661 00:34:54,760 --> 00:34:58,600 Well, in today's world this comes with a very big asterisks 662 00:34:58,600 --> 00:35:01,640 or carrier. Almost all systems are micro 663 00:35:01,640 --> 00:35:04,680 service architecture and it is unlikely you will come across 664 00:35:04,680 --> 00:35:09,040 monoliths, but you should be aware of their trade-offs. 665 00:35:09,040 --> 00:35:11,720 And in fact, there are certain systems where a monolith will 666 00:35:11,720 --> 00:35:14,960 make sense. For example, Amazon's, they are 667 00:35:14,960 --> 00:35:18,160 video streaming where they refactored some micro service 668 00:35:18,160 --> 00:35:22,160 architecture to monoliths and that resulted in a considerable 669 00:35:22,160 --> 00:35:25,240 performance improvement and improvements in cost. 670 00:35:25,520 --> 00:35:29,120 But the decrease in cost, however, yeah, it came with all 671 00:35:29,120 --> 00:35:33,920 of the trade-offs of a monolith, such as possibly having to scale 672 00:35:33,920 --> 00:35:38,840 the entire system when you develop any part and the speed 673 00:35:38,840 --> 00:35:42,480 of deployment and the speed of the overall, the flexibility of 674 00:35:42,480 --> 00:35:44,280 the system to changing requirements. 675 00:35:44,360 --> 00:35:46,240 These are some of the trade-offs of monoliths. 676 00:35:46,440 --> 00:35:48,200 Yeah. So really it all comes down in 677 00:35:48,200 --> 00:35:51,640 the end to again, improving your general understanding of these 678 00:35:51,640 --> 00:35:55,120 high level cultures, be able to discuss their trade-offs. 679 00:35:55,400 --> 00:35:58,320 And it would definitely help to have a passion in some of these 680 00:35:58,320 --> 00:36:02,560 topics and to follow the industry developments to read 681 00:36:02,640 --> 00:36:05,400 about these and discuss about these blog posts. 682 00:36:05,640 --> 00:36:08,600 Having a passion for your job as a software engineer, it is 683 00:36:08,600 --> 00:36:10,960 certainly something that would bring you very far. 684 00:36:11,680 --> 00:36:13,080 Yeah. I find that these topics 685 00:36:13,080 --> 00:36:16,120 probably is research and well published online, right. 686 00:36:16,120 --> 00:36:19,040 So don't forget, always read up about all these distributed 687 00:36:19,040 --> 00:36:22,360 transactions, event driven architecture, synchronous versus 688 00:36:22,360 --> 00:36:24,560 asynchronous, right? And also maybe like 689 00:36:24,600 --> 00:36:26,600 orchestration versus choreography like what you 690 00:36:26,600 --> 00:36:29,200 mentioned, right. So some of these topics are well 691 00:36:29,200 --> 00:36:31,560 covered. So please do prepare as well. 692 00:36:31,840 --> 00:36:34,600 And I think one particular thing that I probably missed in the 693 00:36:34,600 --> 00:36:37,920 beginning is asking about the functional requirements aspect, 694 00:36:37,920 --> 00:36:40,720 right? How should you explain your 695 00:36:40,720 --> 00:36:42,520 understanding about functional requirements? 696 00:36:42,520 --> 00:36:45,120 Because like you mentioned, maybe domain knowledge is not 697 00:36:45,120 --> 00:36:47,760 necessarily interviewer asked from us, right? 698 00:36:47,760 --> 00:36:51,120 To understand, for example, how do you create like a banking 699 00:36:51,120 --> 00:36:53,640 application? But how do you actually satisfy 700 00:36:53,640 --> 00:36:55,440 functional requirements understanding? 701 00:36:55,440 --> 00:36:59,360 Is it about API design? Is it about design patterns? 702 00:36:59,360 --> 00:37:02,520 So tell us more about it. Typically it is about 703 00:37:02,640 --> 00:37:06,640 understanding the specific set of use cases that you will be 704 00:37:06,640 --> 00:37:08,560 covering in designing this system. 705 00:37:08,960 --> 00:37:12,760 So an API design is one way that you can approach that. 706 00:37:13,040 --> 00:37:16,760 You can scribble down an API, a REST API spec, really quickly, 707 00:37:17,120 --> 00:37:18,800 but it does not have to be perfect. 708 00:37:19,000 --> 00:37:21,840 Yeah, you definitely don't need to get every detail. 709 00:37:21,840 --> 00:37:25,480 You're not there to test like how well and how fast you can 710 00:37:25,480 --> 00:37:29,000 define a REST API, but rather you're there for the interviewer 711 00:37:29,000 --> 00:37:32,800 to understand that you can take a vague requirement, you can 712 00:37:32,800 --> 00:37:37,280 discuss the set of specific use cases that the customer actually 713 00:37:37,280 --> 00:37:39,920 wants, and those are the functional requirements that you 714 00:37:39,920 --> 00:37:41,840 are going for. And yeah, based on the 715 00:37:41,840 --> 00:37:45,400 functional requirements, then you would discuss the non 716 00:37:45,400 --> 00:37:48,240 functional requirements that the customer actually needs. 717 00:37:48,600 --> 00:37:52,040 And from then on, you would design a system that would 718 00:37:52,040 --> 00:37:54,160 fulfill all of these requirements. 719 00:37:54,560 --> 00:37:57,880 And the discussion then is typically about your design 720 00:37:57,880 --> 00:38:01,680 choices and possible alternatives and yeah, the 721 00:38:01,680 --> 00:38:04,520 trade-offs that come with them. So that is how you would 722 00:38:04,520 --> 00:38:05,880 approach it. Yeah. 723 00:38:05,880 --> 00:38:08,600 So be able to design the API at least, right? 724 00:38:08,600 --> 00:38:12,640 So what are the requests that the system will ask, right? 725 00:38:12,640 --> 00:38:15,320 And what are the outputs? I think is very important if you 726 00:38:15,320 --> 00:38:17,640 do understand high level business workflow, I think 727 00:38:17,640 --> 00:38:19,720 that's also important. In my view. 728 00:38:19,720 --> 00:38:22,480 It's always a bonus, right? If you can always understand 729 00:38:22,480 --> 00:38:25,560 about the high level business workflow and think about all the 730 00:38:25,560 --> 00:38:29,440 different cases that particular system would need to handle. 731 00:38:29,520 --> 00:38:32,880 Things like for example, I don't know, reconciliation reporting 732 00:38:33,200 --> 00:38:35,560 and you know, handling pic search of the request and things 733 00:38:35,560 --> 00:38:37,400 like that. I think it's always very, very 734 00:38:37,400 --> 00:38:39,920 important. So, so young, we talk a lot 735 00:38:39,920 --> 00:38:43,560 about all these topics. So sometimes we do fail system 736 00:38:43,560 --> 00:38:46,920 design interview. Maybe from your tips, how should 737 00:38:46,920 --> 00:38:49,720 we handle, you know, being sucked in the system design 738 00:38:49,720 --> 00:38:54,000 interview and how can we actually make it better the next 739 00:38:54,000 --> 00:38:56,000 time? So any tips on handling failure 740 00:38:56,000 --> 00:38:59,800 here? Well, firstly, we talked about 741 00:38:59,800 --> 00:39:03,280 resilience at the beginning and definitely you will definitely 742 00:39:03,280 --> 00:39:06,240 go through many failures. You will definitely sell more 743 00:39:06,240 --> 00:39:09,400 interviews than you were past. But perhaps there are few of us 744 00:39:09,400 --> 00:39:12,560 for which this rule is not true. But yeah, I'm making an 745 00:39:12,560 --> 00:39:16,560 assumption on the behalf of the overwhelming majority of us, and 746 00:39:16,560 --> 00:39:19,600 I can think of like some generic advice. 747 00:39:19,840 --> 00:39:22,880 Certainly, as I said, be resilient, don't be discouraged. 748 00:39:23,320 --> 00:39:25,720 And yeah, you have endless chances. 749 00:39:25,720 --> 00:39:27,680 You can keep trying. There are many companies that 750 00:39:27,680 --> 00:39:30,680 you can interview for and you have like the rest of your 751 00:39:30,680 --> 00:39:33,600 career to keep getting better at what you do. 752 00:39:34,040 --> 00:39:36,800 And really, it helps to be passionate as a software 753 00:39:36,800 --> 00:39:38,640 engineer. It will help if your thoughts 754 00:39:38,640 --> 00:39:42,040 about it isn't really just in terms of how well you can do in 755 00:39:42,040 --> 00:39:44,120 it as a career. Well, these are definitely 756 00:39:44,120 --> 00:39:45,640 considerations that one should have. 757 00:39:45,680 --> 00:39:49,240 But if you are driven solely by this, then you're going to have 758 00:39:49,240 --> 00:39:52,680 a much harder time in dealing with failure than otherwise. 759 00:39:52,680 --> 00:39:56,120 If you do have a passion for this industry, for this line of 760 00:39:56,120 --> 00:39:59,800 work, and in coding, in system design, in building systems in 761 00:39:59,800 --> 00:40:03,120 general, and in collaborating with others to realize like 762 00:40:03,120 --> 00:40:05,680 large projects, to bring large projects to reality. 763 00:40:06,040 --> 00:40:08,400 So remember that this is your passion. 764 00:40:08,400 --> 00:40:11,440 This is your purpose. And along the way, there would 765 00:40:11,440 --> 00:40:15,320 definitely be setbacks, not just in system design interviews, but 766 00:40:15,360 --> 00:40:18,280 in the job as well. There are many things that go 767 00:40:18,280 --> 00:40:21,920 right, there are many things that go wrong, but the important 768 00:40:21,920 --> 00:40:26,840 thing is that you try your best to collect feedback, to learn 769 00:40:27,080 --> 00:40:31,600 from your successes and your failures, and yeah, to really 770 00:40:31,600 --> 00:40:34,000 keep challenging yourself and really keep learning. 771 00:40:34,320 --> 00:40:37,560 And if you were to have this attitude that they bring to 772 00:40:37,560 --> 00:40:40,520 interviews that you bring to your work, you will definitely 773 00:40:40,520 --> 00:40:43,040 go pretty far and your career path will be paved with 774 00:40:43,040 --> 00:40:45,800 accomplishments. So in summary, how you would 775 00:40:45,800 --> 00:40:47,840 deal with failures in system design interviews? 776 00:40:48,160 --> 00:40:50,640 You were analyzed like what you believe you could have done 777 00:40:50,640 --> 00:40:52,960 better. Any places, any particular parts 778 00:40:52,960 --> 00:40:55,960 of the interview where there were specific topics where you 779 00:40:55,960 --> 00:40:59,720 lack certain knowledge or where you failed to discuss possible 780 00:40:59,720 --> 00:41:01,840 approaches And there are trade-offs. 781 00:41:02,120 --> 00:41:05,240 Generally, you were practice like you would take this 782 00:41:05,240 --> 00:41:07,800 question, you were practice it, you were examining it 783 00:41:07,800 --> 00:41:09,520 thoroughly. You would note down what you did 784 00:41:09,520 --> 00:41:11,360 right, what you believe you did right, what you believe you did 785 00:41:11,360 --> 00:41:13,760 wrong. And then you you can discuss it 786 00:41:13,760 --> 00:41:17,480 with your peers and read up about the relevant topics. 787 00:41:17,920 --> 00:41:19,400 Maintain a good attitude about it. 788 00:41:19,480 --> 00:41:22,200 And yeah, this is how you'll keep pushing forward and how you 789 00:41:22,200 --> 00:41:24,680 will succeed. Thanks for highlighting about 790 00:41:24,680 --> 00:41:27,240 resilience one more time. Right, So I think system design 791 00:41:27,240 --> 00:41:30,480 interview majority of people would experience some kind of 792 00:41:30,480 --> 00:41:32,840 failure. I failed in the past as well. 793 00:41:32,840 --> 00:41:36,360 I think I've many times right? I think system design interview, 794 00:41:36,360 --> 00:41:39,360 sometimes you prepare something but then suddenly you are 795 00:41:39,520 --> 00:41:41,160 expected to design something else. 796 00:41:41,400 --> 00:41:43,800 So exposure I think is really important, right? 797 00:41:43,800 --> 00:41:46,760 Not necessarily exposure as in like hands on experience, but 798 00:41:46,760 --> 00:41:49,840 also exposure by reading understanding, you know, real 799 00:41:49,840 --> 00:41:52,480 world challenges. You know, every time tech 800 00:41:52,480 --> 00:41:55,280 company publish a certain blog about solving a particular 801 00:41:55,280 --> 00:41:57,760 problem, I think do read up, check that out. 802 00:41:57,960 --> 00:42:00,520 Sometimes it can give you some kind of insights how you would 803 00:42:00,520 --> 00:42:02,360 think certain problems differently. 804 00:42:02,880 --> 00:42:06,680 So Jay Young, it's been a great mentoring about system design. 805 00:42:06,680 --> 00:42:09,400 So thank you so much for sharing your insights for people. 806 00:42:09,400 --> 00:42:11,000 Do check out Jay Young's book as well. 807 00:42:11,000 --> 00:42:14,240 There are so many real world problems questions that are 808 00:42:14,240 --> 00:42:16,120 being covered in different chapters in the book. 809 00:42:16,360 --> 00:42:20,280 So it's highly dense, like so many, many topics in one book. 810 00:42:20,520 --> 00:42:24,080 So I think you will get a lot of things like insights like how 811 00:42:24,080 --> 00:42:26,040 you can prepare system design interview better. 812 00:42:26,520 --> 00:42:29,080 So I have one last question that I would like to ask you. 813 00:42:29,400 --> 00:42:31,760 This is something that I call tree technical leadership 814 00:42:31,760 --> 00:42:33,720 wisdom. So if you can think of it just 815 00:42:33,720 --> 00:42:36,760 like advice you want to give to the listeners, maybe can you 816 00:42:36,800 --> 00:42:39,720 share what is your version of three technical leadership 817 00:42:39,720 --> 00:42:42,240 wisdom? Well, if the question is about 818 00:42:42,240 --> 00:42:45,160 technical leadership in particular, firstly I would say 819 00:42:45,160 --> 00:42:47,520 the three things, continuous learning, firstly, continuous 820 00:42:47,520 --> 00:42:49,560 learning, secondly, your communication and your 821 00:42:49,560 --> 00:42:52,760 collaboration. And lastly, leading by example. 822 00:42:53,120 --> 00:42:56,160 So yeah, regarding continuous learning, yeah, what you know 823 00:42:56,160 --> 00:42:58,080 today might become outdated tomorrow. 824 00:42:58,080 --> 00:43:00,600 So you have to stay curious, you have to stay committed to 825 00:43:00,600 --> 00:43:02,880 learning. You encourage your team to 826 00:43:02,920 --> 00:43:06,600 engage in ongoing education through courses, workshops, 827 00:43:06,600 --> 00:43:08,680 conferences. Keep staying updated with 828 00:43:08,680 --> 00:43:12,200 industry news and trends. So your team will remain agile 829 00:43:12,200 --> 00:43:14,840 and adaptable to new challenges, to new opportunities. 830 00:43:15,120 --> 00:43:17,640 And you should be kind, you should be humble. 831 00:43:17,800 --> 00:43:20,800 And this is a culture that should be pushed into the team 832 00:43:20,800 --> 00:43:23,400 that as we said, not everybody knows everything. 833 00:43:23,800 --> 00:43:26,720 People have different strengths and weaknesses as well at 834 00:43:26,720 --> 00:43:29,960 different particular domains that one is passionate in. 835 00:43:30,400 --> 00:43:34,320 And in order to succeed as a team, everyone, every team 836 00:43:34,320 --> 00:43:36,480 member should complement each other. 837 00:43:36,840 --> 00:43:39,600 And then you can bring your combined knowledge, your 838 00:43:39,600 --> 00:43:42,640 combined expertise and experience to really realize 839 00:43:42,640 --> 00:43:45,520 like something which no team member can accomplish alone. 840 00:43:45,760 --> 00:43:48,640 So yeah, continuous learning I would say is the top thing that 841 00:43:48,640 --> 00:43:52,000 you have to keep emphasizing. Another thing, communication and 842 00:43:52,000 --> 00:43:54,680 collaboration. Embrace open dialogue within 843 00:43:54,680 --> 00:43:57,480 your team and show everyone feels hurt, everyone feels 844 00:43:57,480 --> 00:43:59,400 valued. Ideas should be freely 845 00:43:59,400 --> 00:44:01,240 exchanged. Constructive feedback must be 846 00:44:01,240 --> 00:44:03,320 welcomed. Conflict should be addressed 847 00:44:03,320 --> 00:44:06,560 promptly and respectfully. And this is particularly 848 00:44:06,560 --> 00:44:08,640 important in the tech industry, right? 849 00:44:08,800 --> 00:44:11,920 We are innovators, we are building we, we are creators. 850 00:44:12,240 --> 00:44:15,640 And in order to realize like something which the world has 851 00:44:15,640 --> 00:44:18,320 never seen before, we got the harness the collective 852 00:44:18,320 --> 00:44:21,200 intelligence of our team to drive this innovation. 853 00:44:21,720 --> 00:44:24,040 And lastly, yeah, leading by example. 854 00:44:24,080 --> 00:44:26,800 As a tech leader, your actions are louder than your words. 855 00:44:27,080 --> 00:44:30,640 So some examples of what you might want to happen within your 856 00:44:30,640 --> 00:44:33,680 team is technical excellence or to have strong ethics and 857 00:44:33,680 --> 00:44:35,840 integrity. You should show your team what 858 00:44:35,840 --> 00:44:38,600 it means to be passionate, what it means to be dedicated, what 859 00:44:38,600 --> 00:44:41,400 it means to be hard working. You should be transparent in 860 00:44:41,400 --> 00:44:44,600 your decision making process and you should take ownership of a 861 00:44:44,600 --> 00:44:47,080 success and failures. And by setting this positive 862 00:44:47,080 --> 00:44:50,680 example, this is how you would inspire your team to really 863 00:44:50,680 --> 00:44:53,960 bring out their excellence and to cultivate our culture of 864 00:44:53,960 --> 00:44:57,040 accountability and trust. So yeah, these are the three 865 00:44:57,080 --> 00:44:59,840 technical leadership principles which I like to follow and which 866 00:44:59,840 --> 00:45:02,080 I believe are essential for a high performing team and 867 00:45:02,080 --> 00:45:04,800 company. Thanks for sharing such a great 868 00:45:04,800 --> 00:45:06,920 tips right. I like the continuous learning 869 00:45:06,920 --> 00:45:09,720 part right. So technology these days, very 870 00:45:09,720 --> 00:45:13,000 rapid change, right? So AILLM, like you mentioned is 871 00:45:13,000 --> 00:45:15,760 the hot topics. It can be overwhelming, but 872 00:45:15,760 --> 00:45:17,520 yeah, don't forget to always learn. 873 00:45:17,520 --> 00:45:20,880 Maybe keep up by reading, but also don't forget you don't have 874 00:45:20,880 --> 00:45:23,920 to know everything. Again, this is a very important 875 00:45:23,920 --> 00:45:26,160 thing in technology, probably you won't be able to know 876 00:45:26,160 --> 00:45:29,440 everything, so just be humble, be kind and always support each 877 00:45:29,440 --> 00:45:31,600 other. So TE young, if people would 878 00:45:31,600 --> 00:45:34,240 like to learn more, maybe is there a place where they can 879 00:45:34,240 --> 00:45:37,000 find your resources or you yourself online? 880 00:45:37,760 --> 00:45:41,280 Well, I am currently working on a couple of personal projects 881 00:45:41,480 --> 00:45:45,040 and I hope that everything that I have done well when it comes 882 00:45:45,120 --> 00:45:48,440 to my professional work or within like this book, the book 883 00:45:48,520 --> 00:45:50,760 Acing the System Design Interview, all the personal 884 00:45:50,760 --> 00:45:52,920 projects that I've released, the general public that would really 885 00:45:52,920 --> 00:45:56,240 convey my passion, the spirit of my passion and my love for what 886 00:45:56,240 --> 00:45:58,160 I do. That really comes up in that, 887 00:45:58,520 --> 00:46:00,160 yes. But if you would like to keep 888 00:46:00,160 --> 00:46:03,680 track of what I'm currently doing lately, you can take a 889 00:46:03,680 --> 00:46:07,240 look at an app called Team See. It is an app that I've written 890 00:46:07,240 --> 00:46:11,000 for my daughter and it's for learning or preparing for 891 00:46:11,000 --> 00:46:13,040 Chinese as a second language exams. 892 00:46:13,320 --> 00:46:16,880 I am trying to apply a new technology which we did not have 893 00:46:16,960 --> 00:46:19,760 when we were kids, with in particular, yeah, new 894 00:46:19,760 --> 00:46:23,000 developments in smartphones, in touch screens, in text to 895 00:46:23,000 --> 00:46:26,000 speech, these innovative technologies that were not 896 00:46:26,000 --> 00:46:29,360 available before, into the experience of learning Chinese 897 00:46:29,360 --> 00:46:32,760 as a second language. And yeah, I hope that this work 898 00:46:32,760 --> 00:46:35,520 also brings out like one can sense the passion and love for 899 00:46:35,520 --> 00:46:38,880 what I do in the product. Another project that I'm working 900 00:46:38,880 --> 00:46:41,440 on is something called jointgoals.com. 901 00:46:41,680 --> 00:46:45,760 Yeah, I am helping out technically with a team to build 902 00:46:45,760 --> 00:46:51,560 a financial advisor for scaling family finance advisory to the 903 00:46:51,560 --> 00:46:55,200 general public beyond the 0.01%. Yes. 904 00:46:55,200 --> 00:46:58,680 So tech is, after all about improving accessibility. 905 00:46:58,960 --> 00:47:03,320 It is about improving quality of life and it is about making what 906 00:47:03,320 --> 00:47:06,320 was previously luxuries or was previously exclusive like 907 00:47:06,520 --> 00:47:08,760 available and more accessible to everyone. 908 00:47:09,160 --> 00:47:11,960 And yeah, I hope that this is something which I will continue 909 00:47:11,960 --> 00:47:13,720 to believe in. I'll continue to be passionate 910 00:47:13,720 --> 00:47:15,840 about. And lastly, if you wish to 911 00:47:16,040 --> 00:47:18,800 discuss the contents of my book, and you can always go on the 912 00:47:18,800 --> 00:47:22,160 Manning forum. And yeah, I generally respond 913 00:47:22,480 --> 00:47:25,400 usually within a few days. But yeah, it a topic 914 00:47:25,400 --> 00:47:28,400 particularly piques my interest. Then yeah, we can have a pretty 915 00:47:28,400 --> 00:47:30,240 lively debate there. OK. 916 00:47:30,240 --> 00:47:32,120 Thanks for those useful apps. Right? 917 00:47:32,120 --> 00:47:34,400 I'll make sure to put it in the show notes so that people can 918 00:47:34,400 --> 00:47:37,000 also benefit from it. So thanks again for this 919 00:47:37,000 --> 00:47:40,080 conversation so young. So I hope the listeners here can 920 00:47:40,080 --> 00:47:42,880 learn a lot of tips about how to do system design interview 921 00:47:42,880 --> 00:47:43,880 better. Thanks again. 922 00:47:44,400 --> 00:47:45,600 OK. Thank you, Henry.