Thumbnail for How to Prepare for Technical Interviews, Part 1 - Coding by Engineering with Utsav

How to Prepare for Technical Interviews, Part 1 - Coding

Engineering with Utsav

28m 50s4,403 words~23 min read
Auto-Generated

[0:00]Prepping for technical interviews at big tech companies is a daunting task, whether you're a beginner or an experienced engineer. It can get quite overwhelming because there is a tremendous amount of technical information to cover in a relatively short amount of time. To make matters worse, tech interview prep has become such a lucrative industry that not only are interview prep boot camps popping up everywhere like mushrooms, they can cost as much if not more than engineering boot camps. The free ones out there either make you eventually buy their full guide, or if they're truly free simply aren't detailed or coherent enough. These were the factors that motivated me to create my own system when I prepared for my tech technical interviews earlier this year. This isn't rocket science, I've basically taken a collection of cognitive training methods and combined them with interview knowledge I've acquired over the years, interviewing engineering candidates to put together an integrated system to help you maximize your learning potential in a limited amount of time. And I'm fairly confident it works because I went from being able to barely solve five easy problems a day to over a dozen medium and hard problems. And as a result, I ended up landing multiple offers from top tech companies. I know this is the part where you may expect me to say it's only three installments of $99. But no, it's completely free, no strings attached, no cost to you. There is already so much confusion and misinformation around interview prep these days that this is the least I can do to help out. Hi guys, my name is Utsav, I'm a software engineer based in Seattle, Washington and this channel is all about helping you excel in your software engineering careers. So if you are into that, please consider subscribing. As usual, all the reference material from this video will be in the description below and I've timestamp, so please feel free to jump to the sections that interest you more. So this is a series of three videos on how to effectively prepare for your technical interviews. This is part one and covers coding, part two will be on system design and part three will be on the behavioral or leadership aspect of technical interviews. While this guide can be used for most technical interviews, it is mainly geared towards big tech and top tech companies like Microsoft, Facebook, Google, Amazon, Uber, so on and so forth. And finally, each of these videos are long and very dense, not only do they contain a lot of resource recommendations, but also methods for creating scoring rubrics, selecting the right set of practice problems and specific techniques for pattern recognition and spaced repetition. You'll likely have to either take notes as you watch them or use them as a reference and revisit sections as you need them. All three videos in this series are divided into three main sections. First, I'll explain the purpose of that type of interview and how much time you should spend preparing for them. Second, I'll recommend resources that you should get before starting your prep, and third, I'll explain the strategy to use when prepping for that specific type of interview. All right, so let's get started with the coding interview. So what's the purpose of coding interviews and how much time should you spend preparing for them? The purpose of coding interviews really depends on how much experience you have as a candidate. If you are a beginner with zero to two years of experience, coding interviews test for your basic competency and your potential. Basically your ability to take what you've learned in school and utilize that to solve problems effectively. For beginners, coding interviews are the bulk of the whole interview process. So I'd suggest dedicating around 70% of your prep time to coding. If you are a mid-level engineer with around three to five years of experience, coding interviews test how accomplished you are as a software engineer. This involves coding speed, communication, fluency on the language of your choice, coding style and modularity, test driven nature of your code and your ability to solve complex problems with optimal solutions. Coding interviews are probably the hardest for this group and the evaluation most likely the strictest. Think of it this way, you don't have enough experience to be in engineering leadership, but you have been an individual contributor in the industry for almost five years. Your coding aptitude should be at its peak at this stage, right? But that being said, because you've already gained so much experience, preparation will also likely be easier for you and you also have to prepare for other areas like system design and leadership. So for that reason, I recommend dedicating around 50% of your prep time to coding. And finally, if you have more than five years of experience or you are in engineering leadership, then coding interviews act as minimum requirement filters. They are there to check if your problem solving competence is roughly on par with the other engineers in the company. The focus will be more on your approach and thought process as opposed to your raw problem solving horsepower. As senior engineers, there are other interviews which I will discuss in part two and part three of these videos that are much more important. Therefore, I suggest dedicating around 30% of your total prep time to coding. As far as total prep time goes, this really varies by the individual, but you should plan for around three to six months in general. Some of you may take three months, others may take up to a year, it's really important to understand your own learning pace and not rush through the process. All right, so let's move on to some of the resources you need. During your prep, you'll be brushing up on a lot of material as well as practicing a ton of problem solving. There are a few things that you'll need, books, courses, and an online coding platform. Everything I recommend are resources I've personally used for my own prep and can fully endorse. That being said, if you're tight on budget, you don't have to get all of them or any of them for that matter. But at the very least, I recommend that you get yourself a book to refresh data structures and algorithms, a course for structured learning, whether that is free or paid, and a subscription to an online coding platform where you can practice coding questions. I will quickly list out my recommendations here, but if you are interested in detailed recommendations, I've dedicated videos for that, so check them out if you'd like. Okay, so here are the two books I recommend. These are my favorites when it comes to data structures and algorithms, but I will also list out some more alternatives in the description below. The first one is called Grokking algorithms. This one is illustrative and has a sense of humor. It's an easy to read option if you're a visual learner. The second book I recommend is Introduction to algorithms. This is much more dense and mathematical, but has very thorough explanations. If you are the kind who loves reading white papers, you'll probably enjoy this one more. If books aren't enough and you need some more structure, consider taking some online courses. Here are some world-class computer science courses that are available for free on YouTube. I recommend watching them in order. The first one is Introduction to Computer Science by Annabelle of MIT. The second one is Programming abstractions by Julie Zelensky of Stanford and the third one and the gold standard is Introduction to algorithms by Eric Demain of MIT. If you are severely limited on time, definitely watch the third one at the very least. Considering that these are free courses, you'll get access to all the lectures, but they don't really come with any interactive coding playgrounds or quizzes, or in general there isn't any kind of feedback. Evaluating your progress and practicing appropriately will be entirely up to you. So if you are the kind that needs more structure or you find these courses too advanced, you may consider paid courses. Okay, so now let's look at an effective strategy for tackling the coding interviews. Grinding out problem after problem without meaningfully tracking progress will not yield good results. You will eventually get frustrated, burn out and give up. Quantity does not guarantee results when it comes to coding interviews. So how do we ensure that we can maximize our results by practicing with the limited set of questions? Here's the seven-step process that I recommend. So the first step is to assess where you are. You can do this in a number of ways. First, you can try out a few typical interview questions and see if you can solve them optimally in under 30 to 45 minutes. If you get close to this, you are in a good spot and probably can wrap up your preparation fairly quickly. If you get completely stuck, then you may need longer. Second, and even better, set up an interview with a company that you don't mind getting rejected by. You can assess your entire interview performance this way and based on that you can allocate prep time accordingly. And the third option is to do a couple of mock interviews and see how you do on those. Make sure that the interviewer is conducting the mock interview, knows how to evaluate candidates and can provide actionable feedback. interviewing.io and pramp.com are good resources for this. One or more of these should give you a rough idea on where you're at and how much time you need to allocate. Step two is to refresh your data structures and algorithms knowledge. It does not matter whether you're a beginner or a seasoned engineer. You will need some form of brushing up when it comes to data structures and algorithms. How long it takes you to brush up and what resources you use depends on how much data structures and algorithms you use on your day job, how recently you graduated, or if you have interviewed elsewhere, how you prefer to learn and what is your budget to acquire the preparation resources? Just pick the ones that fit your needs from the recommendations I made earlier about this. As you learn and brush up on your data structures and algorithms, find a few easy questions related to those topics and try to solve them. Just do one to two questions per topic and don't worry about whether you can solve them or not, the actual practicing part comes later. This is just to get an understanding of how interview questions relate to the topics you're learning about. All right, step three is to create a consistent system for tracking your progress. This is one of the most important steps. Without a consistent system to evaluate your progress, you will end up grinding out problems after problems without any success. The idea is to have three buckets or lists if you will. Let's call them the To Do list, the Repeat list and the Done list. The to-do list will contain a set of problems that you have not worked on yet. The repeat list will contain a set of problems that you have already worked on but aren't confident about. And finally the done list will contain a set of problems that you have already worked on one or more times and are fairly confident on. So you start off by adding a carefully selected list of problems into the to-do list, and as you practice, those problems make their way through the repeat list and eventually to the done list. You can manage these lists in any app you prefer, Excel, Trello, Notion, or anything else that allows you to manage lists. I personally use Notion and I'll be showing you some clips from my Notion setup. Okay, so let's talk about how to go about selecting the problems to practice. I've found that 100 to 200 questions provide the best value in terms of time. Doing more than 200 starts yielding diminishing returns. So you can either go with something like Algo Experts where someone else has done the curating for you, or for lead code, I'd recommend selecting the top questions from common data structures. To do that, visit Lead code and navigate to the problem section.

[12:48]Click on tags and you will see all the common data structures listed there.

[13:00]Click on a data structure, then sort the list by the ones that have solutions. Then pick the top four easy, top four medium and top two hard questions from that sorted list. Add that to your to-do list, repeat this process for the following data structure. At the end, you should have about 100 questions, 40 easy, 40 medium and 20 hard. This is just a starting point where you have a good representation of all the common data structures. You will be adding and removing questions to this list later. Now we have a set of problems to work on, but to track your problems consistently, you must also work on them consistently. So let's talk about how you should practice each problem. First, always practice as if you are in the real interview, which means no watching TV, no lying on the couch, no lounging around. Since interviews are remote right now, practice on a computer, the same one you'll be using in the real interview. I'd even go as far as putting on headphones to mimic the real setting. Second, always time yourself, your goal is to be able to solve every problem in under 30 minutes. So when you work on a problem, if you are past the 30 to 45 minutes mark and still struggling, you're done. Look at the solution, learn the technique and move on to the next question. That being said, if you have no idea in the first five or 10 minutes and are completely stuck, you can take a very quick peak at the solution. Just enough to get you going in the right direction. Try to treat this as a hint to get you moving and avoid looking at the full solution until you're past the 30 to 45 minute time threshold. Third, in a real interview, you also get to ask clarifying questions, but when you're practicing, you don't have anyone. A good way to emulate that is with test cases. For example, a typical clarifying question that can come up when dealing with string manipulation could be will the string have white spaces or special characters? Emulate that question by trying out an example test case with white spaces on lead code. The output should give you the answer on whether the answer is yes or no. Fourth, try to do at least five questions back to back, because in a real interview, that is how it will be. So you will need to build up that endurance. Avoid getting distracted in between questions. However, after you finish the entire session of five or more questions, it is critical that you verify your solutions to see how well you did. If you did not do well, it is important to spend time and understand the approach and technique. Remember, the goal is to understand the mindset and not to memorize the solution. All right, now that you have some ground rules on how to practice, you need one more thing before you can start your first problem. You will need a scoring system so that you can assign a score to each problem after you work on it. There's really no rule of thumb when it comes to scoring yourself, but I recommend giving yourself a score based on the ground rules that we just set up. Give yourself a score in the range of one to five, one being poor and five being perfect for each of the following, then average that out to get the final score for each problem. The first thing, did you need hints, as in, did you have to peak at the solution to get more help? How many times did you do that? Second, did you finish the problem in less than 15 minutes or less than 20 minutes or less than 30 minutes or less than 45 minutes or maybe you just couldn't finish it? Third, was your solution optimal, sub optimal, almost worked, off track, got completely stuck? Fourth, did you have any bugs? How many? One, two, three, were they minor, were they major? Just give yourself a score from one to five based on all these questions, average that out and that's the score for each problem that you do. Okay, so now you have a good set of questions, a method to progress through them, a rule set for working on them and a consistent system for scoring them. You are now ready to work on the problems. Step four is to practice the problems using spaced repetition and pattern recognition. The idea is to use space repetition to build up your problem solving intuition and muscle memory, but at the same time, you also want to keep a keen eye on all the repeated patterns that come across while you're practicing these problems. Here's an example of how you can go about it. So let's say you have bandwidth to practice only five problems a day. Remember the three lists that we talked about earlier? All 100 problems that you picked should be on your to-do list on your first day and the other two lists should be empty. From there, you will pick five random questions from the to-do list instead of five and pick one problem from the top of the repeat list. It is important to pick them at random to avoid working on the same category. After you finish each problem, you'll give it a score based on the scoring rubric we just discussed earlier. If your score for a problem is close to five, put that problem at the bottom of the repeat list. If your score is close to one, add that problem to the top of the repeat list. And likewise, if your score is closer to the middle like three, insert that problem towards the middle of the repeat list. Obviously, your repeat list will be empty on day one, but as you progress through the problem, it will have the problems you struggled with the most towards the top and the problems that you struggled with the least towards the bottom. Now from the second day onwards, you will pick four random problems from the to-do list instead of five and pick one problem from the top of the repeat list. And just as day one, you work on the problems, score them and put them at the top, middle or bottom of the repeat list based on the scores. Do the same process every single day. You'll obviously repeat some problems way more than others and those are generally the problematic ones. The easy ones by virtue of being at the bottom of your repeat list will automatically be repeated less often. At any point of this process, if you feel that you're 100% confident on some problem, or have repeated it enough times where you're now confident that you can easily solve it, you move them to the third list that is our done list. Keep doing this until your to-do list is completely empty. At this point, all your problems should either be in the repeat list or the done list, or most likely they'll be split between the two list. Good job, you've made it through round one. Round two will be much easier, I promise. But before you proceed, though, you need to take a look at some common coding patterns and see if you notice any. This is probably the hardest step to master because pattern recognition is the step that enables you to know when to use certain data structure or algorithm to solve a problem. This is also where you pick up little tips and tricks that will help you solve those problems. I will list out some common techniques here. The idea is to recognize repeated steps that will help you solve many different problems. Some of them may be simple algorithms, others may actually be patterns that reoccur and some of them just may be variations and tweaks of other problems. And since you have gone through 100 or so problems by now, it's a great time to review some of these techniques and see if you recognize them. This step will help you create a better association with them, so that you'll not only be able to recognize them when you see them again, but also readily pull them out from your tool chest of problem-solving techniques. Feel free to study more about these techniques, if you just search it on Google, you should get more information about those. Or if you want me to make dedicated videos on some of them, let me know in the comments below and I can work on them. All right, now that you have quickly browsed through some of the common techniques, let's go back to our lists. Feel free to discard the problems on your done list or put them somewhere else because you're now confident on those. Now look at the problems on your repeat list and try to assign them to the techniques that we just discussed. Once you have done that, take a look at the ones that repeatedly got low scores and see if you see any repeat offender. You should notice that certain combinations are more problematic than others. For example, for me, I noticed that binary search on two dimensional arrays was always problematic. It could be recursion with memoization for you, graphs with connected components for others, regardless of what those are. Make a note of the most problematic ones, because in round two, you'll be filtering on those categories on lead code and adding another 50 or so problems specific to those categories. Move all the problems from repeat back to your to-do list and reset the scores. Now repeat the entire process exactly as you did for round one. You'll realize that this round will go much faster than the first time and you'll start recognizing patterns and techniques. As you solve more questions, your speed and endurance will also increase and as a result, you'll start doing way more questions than just five in the same amount of time. Some of you may need a third round, but generally at the end of two rounds of space repetition, most of you will have done close to 200 questions and will be confident enough to start interviewing. Step six is to evaluate your readiness. So when do you know when you're ready? Well, when you've gone through at least two rounds of space repetition and most of your scores are closer to five, which means most of your solutions are bug-free, completed within 30 minutes and are optimal. Don't worry about the oddball questions, there will always be some that will get you. You will not be perfect at this and almost perfect is good enough. And another good way to evaluate your readiness is to interview at a few companies where you don't care to work for, or just do a few mock interviews and see how you perform. And some of it is really just got feeling, something like really hard to quantify, but because no one has unlimited time, at some point you'll have to draw the line and start interviewing. And trust me, you will never be 100% ready. And that's okay, and you'll also never get accepted by all the companies that you apply to, and that's also normal. Speaking of not being accepted by all the companies, it is critical that you reflect on what went right and what went wrong after each interview. You want to continue doing things that went right and learn from mistakes you made. Try to investigate what got you stuck. Did they give you a hint that you didn't realize it? Maybe you forgot to ask clarifying questions, or just jump to conclusions too quickly? Maybe you forgot certain edge cases? Was it just the complexity of problem that needs more work? Understanding this will help you iterate and improve fast. Do keep in mind that on some days you just have a bad day where luck is just not in your favor. Don't be too hard on yourself and let those go. One final thing I wanted to add is that this whole process is generalized and should act as a template that you change according to your needs, or even the company you're interviewing at. If you have tighter deadlines, but higher bandwidth each day, do 10 problems and adjust accordingly. If you want to target specific companies, pick some problems from lead code that are specific to certain companies. Follow this process consistently every single day and you should see improvements very quickly. Even if you can aim for only three problems a day, it is important to stay consistent and do them every single day. I do recommend that you aim for at least five problems a day. And that's all for this video. Part two of this video will be on system design and part three will be on behavioral and leadership. If you're watching this after June 10th, 2021, both part two and part three should already be available and linked in the description below, so go check them out. If you are watching before June 10th, they will be uploaded in the following weeks. If you like this video, please like it, comment on it, share it with your friends who may find it useful as well. Helping others is the whole reason this video exists. And while you're here, please subscribe for more content like this. I'll see you in part two, cheers.

Need another transcript?

Paste any YouTube URL to get a clean transcript in seconds.

Get a Transcript