It is all about trade-offs. Just always remember that it is not about perfection. It is about trade-offs and your ability to understand the pros and cons of any approach that you choose, to be able to discuss many possible approaches, to be creative and to be conscious of the current and possible of future requirements. Yeah, I I think this is about what it is really. And being able to communicate them clearly and concisely.
Hey everyone, my name is Henry Surya Virawan and you're listening to the Technically Journal podcast, the show where I'll be bringing you the greatest technical leaders, practitioners and thought leaders in the industry to discuss about their journey, ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work.
So let's dive into our journal. Hello everyone, welcome back to another new episode of the Techie Journal podcast. Today I have Zhiyung here with me, the author of asing system design interview. Hearing this title, I'm sure you know that we are going to be drilled by Zhiyung about how we can do system design better. If you are a more maybe like software engineer, right, you would have maybe experienced
this in your interviews before. And it's always stressful, at least for me, because sometimes you don't know what to expect. And in the end, you also don't know whether you are doing great or not, right? So hopefully Seayoung can give us some pointers today. So welcome to the show, Seayoung. Thank you for having me, Henry.
Right Seayoung, I always love to start in the beginning by asking my guest to share a little bit about maybe your highlights or turning points that we can learn from you well. I suppose if this was advice for the general software engineering community, yeah, I would say one point is that you should work with your manager. Well, when you enter a new team, one of the first conversations you should have with your manager is to develop a career road map.
This might include the projects that you would be working on as well as training opportunities, whether it's a formal training from the company, training that the company sponsors for you all, training with other software engineers within your team or within the company in general. They're more of an informal pipe was training. So yeah, following through with discussing the progress of the road map that and any changes that you will make along the way. It can be pretty dynamic.
It should be one of the main discussion points in your one on ones. Personally for me, I'm from a non traditional CS background. So I suppose one of the turning points was during the time when I was trying to break into the field. And yeah, I was interviewing while learning simultaneously. And I would say it takes a lot of resilience. And this is something that you, you should, yeah, I guess all of us should continue to develop and continue to remind ourselves that we will.
And we should continue to face and seek out challenges because it is these challenges that help us to grow, to develop technical skills, to develop project management skills, develop communication skills, develop conflict resolution skills, and understand about system designs as we seek out like new challenges, like new types of projects and unfamiliar domains.
And as I mentioned at the beginning when I talked about breaking into the view and coming from a non traditional CS background and having to interview and learn at the same time, yeah, this taught me the value of resilience. And they also gave me the attitude that I kept to this day to always keep learning and always to keep seeking out new challenges. And I think, I hope that the spirit of this is embodied in the book that I've written.
I hope that it would help. It would make things a little easier to give people a sense of direction, which I myself lack. So yeah, I would say this is one of the. I'm not quite sure if I describe it as a turning point exactly, but this is some advice that I would give to everyone. Hey, thank you for being part of the technological community. This show wouldn't be the same without your ears, and you are
the reason this show exists. If you're loving TLJ and want to see it keep on growing, consider becoming a patron at Techledeional dot Dev Patron or buying me a coffee at Techledeional dot Dev Coffee. Every little bit helps field the research, editing, and sleepless nights that go into making this show the best it can be. Thanks for being the best listeners any podcast could ask for. And now let's get back to our episode. Wow, it's very inspiring about your story, right?
Starting from a non CS background, actually trying to, you know, go to the industry. Software engineering can be really daunting at this time where so many things to learn. And not only that, now you have successfully written a book as well about a topic that some software engineers probably like afraid to do when they go to interviews, right? So system design, it's one of the rounds in any major big companies, tech companies, right, that people have to go
through. But in the 1st place, maybe because the definition kind of like not so well defined, what is actually system design interview? And I know that some companies define it differently or maybe do the kind of test differently. But maybe in your view to level set our understanding, right? What is System Design Interview?
Well, it it is an interview. It is not about coding obviously, but it is where you are asked to design A scalable and efficient software systems to solve real world problems. These interviews, they are commonly conducted for engineer roles, especially for the more senior roles where you are expected to have a strong understanding of architecture
and design principles. You are typically be given a problem statement or scenario and you're asked to design a high level architecture to address requirements. And then you would have to deep dive into topics like scalability, reliability, performance with the non functional characteristics that is mentioned in I believe chapter three of the book and the goals really of a system
design interview. Yeah. It's about assessing your problem solving skills, how you analyze a complex problem, how you identify requirements and how you design an appropriate solution. It might be about evaluating your design skills, your architecture and design principles, scalability, modality, flexibility, maintainability.
To a lesser extent is about testing your technical knowledge in terms of such as in distributed systems, databases, networking, caching, low balancing, cloud infrastructure. Yes, this knowledge is good to have and in fact more important as to become more senior. But really it is about and it's about your communication skills, how effectively you communicate your ideas, how you explain your design decision, how you justify your choices to the interviewer, how you evaluate possibilities
and discuss trade-offs. This really is about your your ability to think through various possibilities and discuss them effectively. It is really what the interview was looking for here. Just by listening to what you said, right, it seems there are plenty of things that we all need to take care of preparing before we even go to the interview, right? So I think a few key takeaways from me is that, yeah, the first one is like, we will be asked to
solve real world problem. Sometimes it's a bit imaginary from time to time, right, depending on the interviewers, but it's mostly solving real world problems, right? Second thing is about, you know, understanding the problem, right? The problem solving skills, some system design probably asks you like a generic, high level abstract kind of question. Then you have to deep dive from there, right? And I think the third thing which I want to go much deeper is actually about the
trade-offs. So I think you mentioned in your book that system design interview is all about trade-offs. Tell us how can we actually think about this trade off? Why is it important in system design? Well regarding trade-offs, there are many, sometimes endless possibilities in designing a particular system. Well, firstly, yeah, you have to understand what the customer is asking for, both the functional requirements and the non functional requirements.
And then from there why the discussion about trade-offs comes in. Well you don't want to over engineer, you don't want to build something that the customer does not actually require. And another consideration is that everything you build that there are always a cost involved.
If you were to make a system more real time, for example, it would be more complex, it would be more expensive and you are assuming that this real time performance is something which is actually needed by the customer. So for instance, if you could make the system eventually consistent or you can make it asynchronous, that the system does not have to immediately return an updated value in
response to users input. There are certain technologies and certain techniques that you can use that would considerably reduce the cost, the complexity, it might improve availability. But as I mentioned, when we talk about trade-offs, really it is about talking about various approaches that can all software well address the requirements to a larger or lesser extent.
And then talking about what you would prioritize and what you were deliberately payless attention to so as to ensure that the cost and complexity is kept and maintainability is kept under control. For instance, while you are satisfying the other non functional requirements like scalability, availability, security, privacy for instance to the desired extent. So I think very important in the beginning you mentioned understanding about the
requirements first, right? The either the functional and the non functional requirements. So without that, probably it's very difficult to actually come up with the trade-offs, right? So solving the first problem is about the requirements and then we have to be able to explain. So this is probably the tough part because first the time is kind of like limited. Some people may be only have like 40 minutes, right? Or some have one hours, full one hour, but most likely it's going
to be limited, right? Especially the nature of open-ended discussions. And the third thing is actually about communicating it. So maybe some tips here how to manage time and how can actually you communicate the trade-offs of your decision and priority better in the interview? OK, with regards to time management, the interviewer would deliberately give you a vague question and yeah, you have to agree on the scope of the discussion and that is how it is kept contained within an hour.
Yeah, it is impossible to discuss a complex system in one hour. You got to narrow down the scope and the interviewer is looking for how you discuss what the requirements are, the functional requirements and the non functional requirements. Yeah. So you would spend a few minutes on that discussion and then after that, only then you will start discussing various possible approaches. And there are trade-offs.
And then most likely what's going to happen is that you would do a deep dive into one or two of those choices. And this would involve sketching high level diagrams onto the whiteboard. Well, when you sketch down like the high level diagrams into the whiteboard, yeah, it is definitely possible to keep things really high level and sketch it out really quickly and gloss over many of the details.
And then the rest of the interview would be about discussing this design at the desired level of abstraction that the interviewer is interested in, or which you, the interviewer might also ask for your opinion into which are the critical pieces that that you believe are the most interesting pieces of the design that you can do a deep dive into. And then from there, you would be drawing more detailed diagrams of specific components of your system.
So this is how you would have such a discussion within 40 minutes or one hour. Near the end of the interview the interviewer might start asking for additional requirements or he he might push a certain non functional requirements to the extreme. For instance, pushing how do you serve up 1 billion users or how do you handle millions of
requests per second. Or you might start discussing about how your system would tolerate, how your system is resilient and how it would what are the graceful degradation characteristics if the certain dependencies fail or a certain parts of your system fail, how that will be handled. So yeah, there is definitely endless topics to discuss.
But within the 40 minutes to one hour, if you are able to clarify the scope, clarify the requirements and design and architecture, well, discuss several approaches. They design an architecture that can satisfy the discuss requirements and weigh the trade-offs of your approach. That would be generally sufficient for the purposes of the interview. Right. I like in the beginning that you mentioned that the interviewer intentionally gives you a vague question, right?
I think we all have experienced this like they they give just one, two sentences, design me, I don't know like Uber, OK or design me like Google Maps or something like that. I think the key here is to ask clarifying questions, right? Don't just assume you know what they are asking, always ask in the beginning probably right? Have a back and forth what to prioritize because the scope can be super big and you have to agree on a level set of understanding right?
Like what is the scope? What is the priority for the interview session? And I think just by listening to the question right some of us will feel anxious actually. Like OK I don't know the answer fully but I also don't want to give no answer. How do you actually manage this kind of stress and anxiety? And actually also sometimes you don't know the answer altogether. Maybe some tips from you how we can manage all this?
Well, the interviewer is generally not looking for domain knowledge unless the job description specifically states that this domain knowledge is required and you are unlikely to be building the system that is asked during the system design interview. So that's not the purpose of the system design interview. The purpose, as we went over, is to assess your communication skills. Assess your understanding of system design in general. And so yeah, you are not expected to know everything.
So when you come across like areas of a of a particular system where you do not possess a certain domain knowledge, right. You can start by assuming that there is a black box that accepts inputs and returns outputs. And you can state your assumptions about this box, both the functional and non functional characteristics of this box. And you can say that this is your staple point in how you
approach this question. And you can investigate further about like how these particular systems are designed and implemented. Yes. So that's typically one approach. Another approach is you will be asked to possibilities of how would you design and implement a particular domain which are unfamiliar with. You can start building from first principles. So for instance, like if you are asked to design A pathfinding for Google Maps or if I asked to
design A rate limiter. Yeah, you can start by designing an algorithm for a single user and then consider how to scale it to a large number of users, what data you would need and how you would handle the data. You could then discuss trade-offs of your approach. The interviewer might sometimes actually help with the domain knowledge.
And then the question, then the discussion then becomes like how you take that knowledge, how you critically evaluate the approaches that the interviewer presented to you, the pros and cons, and how will you build a system around it. And it's also about asking the right questions.
Then how about managing anxiety? Like, do you have some tips to like, I don't know, do the preparation, maybe a good rest or maybe, I don't know, like do you have some tips that we all can learn how to manage performance anxiety in the system design interview? Well, experience definitely
helps. One of my suggestions would be to practice with your friends, with fellow software engineers or sometimes perhaps even with people, non-technical people within your company, but maybe even with your friends or family who are not in the tech view at all, but however who are interested to help you succeed. This is how, in fact, a pretty valuable way for you to train your communication skills.
And this is something that is sometimes also assess your ability to explain complex technical concepts to non-technical people, which is actually a pretty relevant skill on the job, particularly as you become more senior. So yeah, I suppose, yeah, that would be one good way you can handle performance anxiety. Keep getting as much experience as you can. Well, another way would be to
increase your knowledge. So the system design interview book and other resources like it are a good starting point. They can present you with some templates and some mental models that you can use as a starting point for most system design questions. And if you were to follow the industry of topics that you find yourself to be more interested in, for example, in a database design or development or AI or LMS, that which is the hot topic right now.
If you were more interested in infrastructure side of things, in DevOps for instance, then I think continuing to learn and continuing to gain knowledge and continuing to discuss your learnings with other software engineers would give you the confidence that you need when you are entering a discussion where you are discussing a topic where you do not have like all of the understanding, all the details. So yeah, after a while, these discussions would become
natural, more natural to you. And yeah, you would become accustomed to handling unfamiliarity, which is in fact something that you should get used to progress in your career. And yeah, so these are some tips that I would give to handle a performance society. Yeah, familiarity and you know, getting used to being asked these kind of questions as I think it's very important especially for those senior who
have already day job, right. So you work on a particular systems most of the time, you know, from the front to the back, right. But system design is all about preparation, I think and resources like your book probably and maybe a few other online resources, you can also use them as a guide like templates and mental model.
I like how you say that. So I think it's very good to have preparation and also, yeah, don't forget to actually have a good rest, you know, like be humble because you may not know everything. So I think just accept that you probably won't be able to answer everything. So in your book you also cover a few principles which I find really, really useful and insightful that can give us like a guide how should we approach system design?
Maybe if you can mention, I know that we have covered some of them. Maybe is there any other principle that you think we all should bear in mind whenever we go to system interview? Well, I'm not sure if I would like to approach the topic or this way and insist on a certain dogma because that is the anti PCs of what a system design interviews or what system design is in general. I suppose that if I were to push like the most general principle,
it is all about trade-offs. Just always remember that it is not about perfection, it is about trade-offs. And yeah, your ability to understand this, the pros and cons of any approach that you choose, to be able to discuss many possible approaches, to be creative and to be conscious of the current and possible of future requirements. Yeah, I, I think this is about what it is really and being able to communicate them clearly and concisely.
So, OK, if I were to summarize what I just said, it, it is really about trade-offs and it is really about clear communication. As you mentioned, if after having one more thing you will not know everything and you will not expect others to know everything. Everyone is continuously learning in our industry, in the tech industry, yeah, new technologies emerge and they do so in a rather unpredictable pace, These trends and yeah, start-ups just suddenly pop up all around them.
Whether it is about machine learning and the Internet of Things or Metaverse not chain and now about AIRNLMS, these topics we all need to continuously keep learning them. And understand how they are applied to systems and the trade-offs and be able to communicate clearly about our thoughts. Right. So thanks for the very great tips, right? So it's all about trade-offs. Understand the current and future requirements, communicate it clearly.
I think communication for some of us can be very daunting, right? How to explain your technical thought process into something that other people can also understand? What I find sometimes useful as well, right? You probably can understand what the problem that the company or the team is solving and try to
relate back from there. Because I think in some interviews I experienced, at least they're trying to solve a problem or they have solved a particular problem and they just want to validate their approach with you, right? So maybe for some of you who can maybe do some research first what the company is doing, what the team is doing, and try to come up with some various different combinations of answers, potential answers that you can prepare. And also don't forget the ultimate tips.
Try to ask around from people who have done the interviews at that particular company. I think it's always useful. So maybe let's move a little bit to the non functional requirements. I think probably this is one of the difficult topic in the system design interview simply because again, there are many trade-offs. Maybe tell us a little bit more about non functional
requirements. Which non functional requirement we should be prepared a lot more and which one that you think is something that interviewers always ask? I believe the topic of scalability pretty much almost always comes up about how you were cost efficiently and how you design your system to easily and cost efficiently adjust its hardware utilization to serve the request load. That is one the first few dimension in the book. Scalability, availability, performance, latency,
throughput, yeah. So these are some of the most common topics that we discussed. But then you would also talk about that the trade-offs that you can make, the complexity, maintainability, debacability and testability of your system and how you were trade off like these certain non functional characteristics. For instance, can you make your system less available in order to reduce its cost? Would they satisfy the customer's requirements?
The customer often, both in the interview and in real life, they will not be fully aware of like these non functional requirements and what they can possibly sacrifice in order to optimize for certain other characteristics. I didn't mention consistency so well. Do you need a strong consistency or is eventual consistency good enough when a particular user arrives stayed out of the system? Must these updates be made available immediately at a high cost and high complexity?
Or can the system be designed to propagate these updates to be non blocking, to be asynchronous, to propagate these updates after some time so as to save on a hardware cost? Do you actually need to serve every request or can you apply or sampling or can you apply approximation techniques? Yeah, this can also save on a cost and well, to a lesser extent, you may need to talk about the security and privacy
characteristics. Most of the time, in my experience, this is not a strong focus point, but what is important is that you express your awareness of these requirements and you are able to discuss them for some time. Yeah, it will discuss them to the desired level that the interview desires should these topics come up. So yeah, I've spoken a lot about non functional requirements and in general it's hard to pin down exactly what will be considered important and what is considered unimportant.
I believe within the book and within many similar resources, they have already condensed the non functional requirements to this list. And this is the most, well this is the list of important requirements or characteristics that one must discuss about a system. And should there be other non functional requirements? Yeah, this can be something that might be discussed like near the end of the interview as a bonus topic, or probably not at all.
Yeah. So I think, yeah, just what you mentioned, right, the first few that we probably need to focus a lot more on is like scalability, availability, right, how to make your system maybe 24/7 up and oh, how performance, yeah, Oh yeah. And how not to, if it's allowed by the requirements and the performance, right? Your speed, latency, right? Also like throughput, how many requests per second? And sometimes it's always helpful to be able to know how you calculate number, like
requests per second, right? Because the interview might just give you like, OK, millions of users a day, but that doesn't mean like a million requests per second, right? So you always have to come up with some explanation how do you derive that request per second. So I think this is all very common topics, security, privacy.
Also, in my opinion, unless the company really deals a lot, I don't know, like with secure data, you know, like PII and things like that, probably they won't ask too much. But yeah, do prepare know about Oauth and things like that. So I think in your book you cover quite a number of various topics, right from the simplest to the most difficult one. And one of the probably difficult one to also answer is about the consistency. So CAP TRM probably is commonly
asked or ACID principle, right. So maybe in your view, how do we tackle consistency much better in the system interview? Well, the interview is not. Firstly, it's not about testing whether you know the dictionary definitions of cap, TRM or acid. There would not be any. Well, in my opinion, not too much value divides. So I'm being able to recite
these definitions. But you're not going to think that one candidate is better than another because the the first candidate was able to recite like this knowledge from wrote while the other candidate cannot. As I say, it is really about the awareness of these principles in general and how they are applied to system design and what trade-offs then are applicable with regards to these
principles. Yeah. So about as you mentioned ACID, so ACID is applicable to relational databases and you would talk about ACID or the requirements for ACID if this is something that this is in the list of nonfunctional requirements that you need strong consistency in particular. And then you will talk about the trade-offs of a having ACID or having a relational databases. For instance, in most cases, in most implementations, all of the data has to fit into a single
host, a single right replica. So their rights are typically pretty difficult to scale. But the reads are fairly easy to scale. But if you were to follow the approach where the reads are easy to scale, where you start implementing heat replicas, then the system is no longer, it gives up the strong consistency property. It becomes eventually consistent as the updates take some seconds
to propagate. So then just being able to talk about these trade-offs, this is something that is part of, well system design discussions in general. And if a system did not have ACID properties, well, we start talking about no sequel. And the idea of a no sequel is the general idea is that you are making some trade-offs against ACID to optimize for other properties of the system. In particular, being able to design or distributed database
more easily. If you were to try designing a distributed database with relational databases, yeah, that has been done multiple times. However, it typically comes with pretty heavy trade-offs. In summary, yes, certainly it is essential to understand the overall idea and purpose of various common paradigms like catheorum or acid, but the main importance is not in knowing their exact definitions, but in knowing how they are applied in system design.
I think that's a very important thing, right? So be aware about all these, right? You don't say like, I don't know about all those, but be aware, try to be able to understand at the high level. But yeah, hopefully the interviewer won't dig you deeper into definitions, right? I know that in your book you also explain that this book is not particularly just for the people who want to do system interview, but also for the interviewer to get some tips how we can do system design better,
right? Because there are variations of how interviewer does the system design. Some focus a lot more on theory, some focus a lot more on practicality, some focus on imaginary problem. So hopefully by reading this book interview also get a good idea how we can do a system design better. So you just mentioned a few things about database. In my experience, database is always challenging, right?
It's probably the first bottleneck that you will see whenever you build a more like scalable performance system. So from your point of view, how should we start thinking about solving database related topics in the system design? Because most likely that you will start with single database and then you because of some reasons for the requirements, right? You handle like lots of requests. Is there a thought process how we can tackle this database scaling problem?
Well, the system design interview for the purposes of our discussion, well, it's not about designing databases themselves. To clarify that would be a totally different discussion. But it is about, yeah, selecting the correct database for your non functional requirements. Again, it is about trade-offs. Database choice is all about trade-offs. And yeah, you would typically start with way. If you were to say you're gonna start with sequel, it is typically because of the
simplicity. So you were consider making your system less complex. It would be for a system that they're starting out with a few users and you're trying to bring it to market quickly, prove the product market fit. And as you scale up as the request, the number of users or the request load increases, then you're going to have to start making some trade-offs against the asset properties of the relational DB to optimize for certain use cases, the most
common use cases of your system. And then this is where you start talking about the various types of databases of no SQL databases and yeah, their various properties and trade-offs. Are you going to go for in memory a key value database like Redis? Are you going to go for a database with colonial storage like Cassandra or are you going to go with for a database that is unstructured? That's key value by unstructured like Mongo DB.
And this would typically depend on your specific nonfunctional requirements. Is your system more read heavy or is it more like heavy for instance that you will select the appropriate database to suit that requirement? What is the latency requirements? The P99 requirements must every user request be responded to immediately. Then you will start looking into in memory databases such as Redis or can it be eventually consistent? Can it be asynchronous?
That is actually one of the main questions that you were asked you were trying to ask. You will try to discuss like which parts of the system need to be real time and which parts do not need to be real time. They can eventually become virtually consistent and then you can start introducing event streaming approaches like Kafka and then Kafka feeding to a
HDFS. And this would considerably reduce the cost and complexity as compared to trying to build a real time high performance, low latency system. And for approaches that when if you're not able to do this, then you you have no choice but to increase the cost and complexity overall. And there's one more thing I
wanted to mention. Lastly, we talked about sampling an approximation earlier, and this is certainly something you should try to bring up, even if it might seem obvious to you that the sometimes you should not make assumptions. As we say, don't make assumptions in the requirements.
Always clarify. If you can do sampling and approximations, then this dramatically reduces the scalability issues and you will most likely in the purpose of the interview, you will probably discuss the possible scenarios where you can apply what happens if you can apply sampling and approximation? How will your design change versus what happens if you cannot go with this approach? Yeah. What will be your design choices
then? So yeah, in the end it all comes down to discussing various possible requirements, especially non functional requirements and how your data voice choice would be different and how the overall system architecture will be different with regards like to different sets of non functional requirements and the different trade-offs that you're trying to make. Right. So I think you cover a lot of things that are very, very important and useful.
I think about database, right? Because I think not many people have the luxury of experiencing, you know, working on systems with complicated database scaling kind of a challenge. So I think in your book you have cover a number of topics, which I'm sure some of us, if you read the book, you will get some good ideas how you can tackle these questions much better in your
next interview. So always check out database problem because I think that's one of the key criteria on how you can actually make your system more scalable, more available and more performant. So I think another important thing these days is about designing your services right and also handling distributed transactions, so to speak. So many people these days talk about monolith versus micro
service, right? When you have a lot of services, how do you ensure transactions are kept as atomic as possible? Probably if it is possible. So how do you tackle this kind of distributed transaction questions? Well, it helps to know a few of the general approaches that you would take regarding distributed transactions. And yeah, that is covered in the book.
So if you were to know these few high level approaches, you can bring them up. But before you do that again, you should clarify whether you need distributed transactions at all. You should explain what the purpose of a distributed transaction is and why you believe it will be needed for your system. And then you will explain without the possible approaches to implementing it within your system design.
In my experience, you do not necessarily have to go into the specifics of anything more complex than throwing in an event streaming such as Kafka and then you are feeding that to a database. Well, a distributed database for further data processing, downstream processing. That is the clear as far as you would go, but it would definitely be valuable to learn about orchestration versus choreography approach of distributed transactions.
It shows the depth of your understanding and it shows the awareness that you can bring up these couple of approaches and talk about their pros and cons and how that would solve the issue of like having to ensure consistency between multiple services in your overall service oriented architecture. Yeah. And can we, as you mentioned, the trade-offs between monoliths and micro services? Well, in today's world this comes with a very big asterisks
or carrier. Almost all systems are micro service architecture and it is unlikely you will come across monoliths, but you should be aware of their trade-offs. And in fact, there are certain systems where a monolith will make sense. For example, Amazon's, they are video streaming where they refactored some micro service architecture to monoliths and that resulted in a considerable performance improvement and improvements in cost.
But the decrease in cost, however, yeah, it came with all of the trade-offs of a monolith, such as possibly having to scale the entire system when you develop any part and the speed of deployment and the speed of the overall, the flexibility of the system to changing requirements. These are some of the trade-offs of monoliths. Yeah. So really it all comes down in the end to again, improving your general understanding of these high level cultures, be able to discuss their trade-offs.
And it would definitely help to have a passion in some of these topics and to follow the industry developments to read about these and discuss about these blog posts. Having a passion for your job as a software engineer, it is certainly something that would bring you very far. Yeah. I find that these topics probably is research and well published online, right. So don't forget, always read up about all these distributed transactions, event driven architecture, synchronous versus
asynchronous, right? And also maybe like orchestration versus choreography like what you mentioned, right. So some of these topics are well covered. So please do prepare as well. And I think one particular thing that I probably missed in the beginning is asking about the functional requirements aspect, right? How should you explain your understanding about functional requirements? Because like you mentioned, maybe domain knowledge is not necessarily interviewer asked from us, right?
To understand, for example, how do you create like a banking application? But how do you actually satisfy functional requirements understanding? Is it about API design? Is it about design patterns? So tell us more about it. Typically it is about understanding the specific set of use cases that you will be covering in designing this system. So an API design is one way that you can approach that.
You can scribble down an API, a REST API spec, really quickly, but it does not have to be perfect. Yeah, you definitely don't need to get every detail. You're not there to test like how well and how fast you can define a REST API, but rather you're there for the interviewer to understand that you can take a vague requirement, you can discuss the set of specific use cases that the customer actually wants, and those are the functional requirements that you
are going for. And yeah, based on the functional requirements, then you would discuss the non functional requirements that the customer actually needs. And from then on, you would design a system that would fulfill all of these requirements. And the discussion then is typically about your design choices and possible alternatives and yeah, the trade-offs that come with them. So that is how you would approach it. Yeah. So be able to design the API at least, right?
So what are the requests that the system will ask, right? And what are the outputs? I think is very important if you do understand high level business workflow, I think that's also important. In my view. It's always a bonus, right? If you can always understand about the high level business workflow and think about all the different cases that particular system would need to handle.
Things like for example, I don't know, reconciliation reporting and you know, handling pic search of the request and things like that. I think it's always very, very important. So, so young, we talk a lot about all these topics. So sometimes we do fail system design interview. Maybe from your tips, how should we handle, you know, being sucked in the system design interview and how can we actually make it better the next time? So any tips on handling failure
here? Well, firstly, we talked about resilience at the beginning and definitely you will definitely go through many failures. You will definitely sell more interviews than you were past. But perhaps there are few of us for which this rule is not true. But yeah, I'm making an assumption on the behalf of the overwhelming majority of us, and I can think of like some generic advice. Certainly, as I said, be resilient, don't be discouraged. And yeah, you have endless chances.
You can keep trying. There are many companies that you can interview for and you have like the rest of your career to keep getting better at what you do. And really, it helps to be passionate as a software engineer. It will help if your thoughts about it isn't really just in terms of how well you can do in it as a career. Well, these are definitely considerations that one should have.
But if you are driven solely by this, then you're going to have a much harder time in dealing with failure than otherwise. If you do have a passion for this industry, for this line of work, and in coding, in system design, in building systems in general, and in collaborating with others to realize like large projects, to bring large projects to reality. So remember that this is your passion.
This is your purpose. And along the way, there would definitely be setbacks, not just in system design interviews, but in the job as well. There are many things that go right, there are many things that go wrong, but the important thing is that you try your best to collect feedback, to learn from your successes and your failures, and yeah, to really keep challenging yourself and really keep learning.
And if you were to have this attitude that they bring to interviews that you bring to your work, you will definitely go pretty far and your career path will be paved with accomplishments. So in summary, how you would deal with failures in system design interviews? You were analyzed like what you believe you could have done
better. Any places, any particular parts of the interview where there were specific topics where you lack certain knowledge or where you failed to discuss possible approaches And there are trade-offs. Generally, you were practice like you would take this question, you were practice it, you were examining it thoroughly. You would note down what you did right, what you believe you did right, what you believe you did
wrong. And then you you can discuss it with your peers and read up about the relevant topics. Maintain a good attitude about it. And yeah, this is how you'll keep pushing forward and how you will succeed. Thanks for highlighting about resilience one more time. Right, So I think system design interview majority of people would experience some kind of failure. I failed in the past as well.
I think I've many times right? I think system design interview, sometimes you prepare something but then suddenly you are expected to design something else. So exposure I think is really important, right? Not necessarily exposure as in like hands on experience, but also exposure by reading understanding, you know, real world challenges. You know, every time tech company publish a certain blog about solving a particular problem, I think do read up, check that out.
Sometimes it can give you some kind of insights how you would think certain problems differently. So Jay Young, it's been a great mentoring about system design. So thank you so much for sharing your insights for people. Do check out Jay Young's book as well. There are so many real world problems questions that are being covered in different chapters in the book. So it's highly dense, like so many, many topics in one book.
So I think you will get a lot of things like insights like how you can prepare system design interview better. So I have one last question that I would like to ask you. This is something that I call tree technical leadership wisdom. So if you can think of it just like advice you want to give to the listeners, maybe can you share what is your version of three technical leadership
wisdom? Well, if the question is about technical leadership in particular, firstly I would say the three things, continuous learning, firstly, continuous learning, secondly, your communication and your collaboration. And lastly, leading by example. So yeah, regarding continuous learning, yeah, what you know today might become outdated tomorrow. So you have to stay curious, you have to stay committed to
learning. You encourage your team to engage in ongoing education through courses, workshops, conferences. Keep staying updated with industry news and trends. So your team will remain agile and adaptable to new challenges, to new opportunities. And you should be kind, you should be humble. And this is a culture that should be pushed into the team that as we said, not everybody knows everything.
People have different strengths and weaknesses as well at different particular domains that one is passionate in. And in order to succeed as a team, everyone, every team member should complement each other. And then you can bring your combined knowledge, your combined expertise and experience to really realize like something which no team member can accomplish alone. So yeah, continuous learning I would say is the top thing that
you have to keep emphasizing. Another thing, communication and collaboration. Embrace open dialogue within your team and show everyone feels hurt, everyone feels valued. Ideas should be freely exchanged. Constructive feedback must be welcomed. Conflict should be addressed promptly and respectfully. And this is particularly important in the tech industry, right? We are innovators, we are building we, we are creators.
And in order to realize like something which the world has never seen before, we got the harness the collective intelligence of our team to drive this innovation. And lastly, yeah, leading by example. As a tech leader, your actions are louder than your words. So some examples of what you might want to happen within your team is technical excellence or to have strong ethics and integrity. You should show your team what it means to be passionate, what it means to be dedicated, what
it means to be hard working. You should be transparent in your decision making process and you should take ownership of a success and failures. And by setting this positive example, this is how you would inspire your team to really bring out their excellence and to cultivate our culture of accountability and trust. So yeah, these are the three technical leadership principles which I like to follow and which I believe are essential for a high performing team and
company. Thanks for sharing such a great tips right. I like the continuous learning part right. So technology these days, very rapid change, right? So AILLM, like you mentioned is the hot topics. It can be overwhelming, but yeah, don't forget to always learn. Maybe keep up by reading, but also don't forget you don't have
to know everything. Again, this is a very important thing in technology, probably you won't be able to know everything, so just be humble, be kind and always support each other. So TE young, if people would like to learn more, maybe is there a place where they can find your resources or you yourself online?
Well, I am currently working on a couple of personal projects and I hope that everything that I have done well when it comes to my professional work or within like this book, the book Acing the System Design Interview, all the personal projects that I've released, the general public that would really convey my passion, the spirit of my passion and my love for what I do. That really comes up in that,
yes. But if you would like to keep track of what I'm currently doing lately, you can take a look at an app called Team See. It is an app that I've written for my daughter and it's for learning or preparing for Chinese as a second language exams.
I am trying to apply a new technology which we did not have when we were kids, with in particular, yeah, new developments in smartphones, in touch screens, in text to speech, these innovative technologies that were not available before, into the experience of learning Chinese as a second language. And yeah, I hope that this work also brings out like one can sense the passion and love for what I do in the product. Another project that I'm working on is something called jointgoals.com.
Yeah, I am helping out technically with a team to build a financial advisor for scaling family finance advisory to the general public beyond the 0.01%. Yes. So tech is, after all about improving accessibility. It is about improving quality of life and it is about making what was previously luxuries or was previously exclusive like available and more accessible to everyone. And yeah, I hope that this is something which I will continue to believe in. I'll continue to be passionate
about. And lastly, if you wish to discuss the contents of my book, and you can always go on the Manning forum. And yeah, I generally respond usually within a few days. But yeah, it a topic particularly piques my interest. Then yeah, we can have a pretty lively debate there. OK. Thanks for those useful apps. Right? I'll make sure to put it in the show notes so that people can also benefit from it. So thanks again for this
conversation so young. So I hope the listeners here can learn a lot of tips about how to do system design interview better. Thanks again. OK. Thank you, Henry.