How to Ace Coding Interviews - Advice from a Former Amazon Dev

I must have been in almost a hundred coding interviews. Sometimes as an interviewee and sometimes as an interviewer. I have struggled in front of the whiteboard and I have seen many candidates struggle. Getting a job at a FAANG company (Facebook, Amazon, Apple, Netflix, Google) can provide you, among other things, the following benefits: Great compensation Fantastic working environment Challenging work Smart colleagues An impressive CV I did it and I can tell you it is absolutely worth it. This will not be another 'How to crack the Google interview' guide, rehashing the same generic tips: study hard, practice, relax, and sleep well the day before the interview. This is based on years of experience, both as a candidate and as an interviewer. You are not alone if you feel that coding interviews are far from perfect - I am there with you - but it is the game you have to play if you want the job. I have been rejected several times and I also have cracked the Amazon interview in just two months of study, while I had a full-time job. I have learned a lot in this process. I do not have a degree in computer science. I had to start from scratch. This is the guide I wish I have had when I started my journey as a developer. Not being at a FAANG (Facebook, Amazon, Apple, Netflix, Google) company does not mean you are not a great developer. It only means you haven't cracked the interviews yet. Keep reading if you want to get a step by step guide on how to prepare to get that job. Outline This is what I will cover in this article: The right mindset before, during and after the interview How to practice solving coding challenges Technical knowledge required Books and websites I used Mistakes to avoid before and during the interview Examples How to prepare Mindset Developers at FAANG companies are not gods. They are regular human beings who went through the same process as you, with their own problems and insecurities. They also suffered from impostor syndrome - probably still do it. Do not put them on a pedestal. Keep this in mind at all times, especially when you get the job. I have met interviewers who enjoyed torturing candidates. Some interviewers who would not hire some of their teammates. Luckily, they are a minority, but you might encounter one of them during your set of interviews. The only smart thing to do is to focus on what you can control: your preparation. Focus on the process. If you prepare well and are persistent, it will be a matter of time before you get the job you want. Once there, it will be easy to move to a different company if you feel like it. You’ll have 4, 5, or 6 rounds of problems to help you, in case you fail in one - or find one of the psycho interviewers I talked about earlier. You can underperform in one of the rounds and still get the job. Self-reflection is a great teacher. After every problem you solve and any interview to attend to, ask yourself: What went well? Where do I need to improve? This will range from computer science and programming language related topics to how well you communicate with your interviewer. Also, I do recommend applying to multiples companies at the same time, in reverse order of preference. This translates to having more options, which will put you in a better position to negotiate, reduce the pressure you put on yourself and give you more opportunities to practice. People eventually leave these companies, be it after 1, 2, 3, or 5 years. It is not paradise, just another job, but this is something that I cannot teach you. You have to see it yourself. How to practice Emulate the interview set-up Try to make your practice sessions as similar to the actual interview as possible. This includes: Time yourself Depending on the company, you will have around up to one hour to solve a problem. At Amazon, for instance, that hour includes Leadership Principle related questions, which brings the time for the technical question down to around 40 to 45 minutes. Once you start getting the grip of solving the challenges, train yourself to go much faster - 30 minutes tops. This way, the day of the interview, even if you get nervous you will be really well trained. Time flies in an interview. No distractions Mute your phone. No music. No internet. You want your practice sessions to be as realistic as possible. If you get stuck, keep trying. Do not give up. During an interview, you cannot just look at the solution. Some platforms and books provide hints. Having a look at these after a few minutes of being blocked is fine as you advance in your preparation since interviewers will likely give you some hints if you get stuck. Think out loud Interviewers need to know what you are thinking. Your problem-solving skills are being assessed, but your communication skills are under evaluation too. Furthermore, interviewers can steer you in the right direction and save you precious minutes if they see your approach will lead nowhere. If you can, find a friend (virtually buddies work too), practice, and give each other constructive feedback. Expand your toolbox Write down anything new that you didn’t know. Functions you had never seen, cool tricks, new concepts, etc. Go through this list often until they become part of your arsenal and come naturally when you're solving problems on your own. For instance, here is a trick to go through all the neighbours (horizontally and vertically) of a cell in a matrix with coordinates (row, col): > dirs = {{ , }, { , }, { , }, { , }}; ( & d:dirs) { nextRow = row + d[ ]; nextCol = col + d[ ]; const vector vector int 1 0 -1 0 0 1 0 -1 for const auto const 0 const 1 Even if C++ is not your main language, just understand the idea and try to translate it into your favourite language. If you want to use C++ in your interviews, make sure you understand every line in that short snippet of code. Keep a log of common mistakes you make This is one of the things that made a huge difference in my performance. You need to know where you usually underperform so that you can fix it. It can be anything: Big (O), dynamic programming problems, recursive functions, tree-related problems, etc. Go through this list often. Review them and practice to make sure you do not make them during your interview. Iterations As I see it, there are two stages during your preparation. You need to understand all the theoretical concepts and know: First stage. When, how, and why to apply them. When, and why not to apply them How to connect them to solve a problem. . You need to be able to implement them and . This is what you get paid for. Second stage turn your ideas into code First Stage Focus on quantity. You need to go through many problems until you start developing an intuition that gives you ideas to solve new problems you have never seen. For every new problem, ask yourself: What algorithm and/or data structure is good for this type of problem? Why? Why this other approach is worse or wrong? What are the time and space complexity of this approach? Can I trade time for space? This is not about memorizing solutions. I repeat. . It is useless and worse than a waste of time. Relying on it is buying a ticket to give the perfect solution to the wrong problem. The idea here is to learn to apply all the data structures and algorithms that you have studied. Putting the theory to practice. Do not memorize the solutions At this stage, I do not write any code. : I just do everything I would do before I start writing code Ask clarifying questions Make sure I understand what the input and expected output are Come up with a step by step plan to solve the problem combining (there are examples at the end of this guide) Big(O) analysis And then compare my approach to the solution in the book. If it is different (or worse), understand why and try to see why I couldn't come up with it: maybe I did not know the data structure, I never thought of applying it that way, etc. The idea is to change the way you think to a more elevated one where you can see the different pieces individually and how to combine them to get to a solution. During your interviews, if you cannot pass this stage, it does not matter how good you are at Python. You are out. Second Stage Now, you can focus on writing the code for the problems you've "already solved". Some tips: . During the interviews, you will not have it. It will be either a whiteboard or an online shared document. Make sure you understand the format of the interview so that you can focus Do not use your IDE If you need to write code on a whiteboard, I'd recommend solving some problems in paper . . It is a skill you will want to practice. as you get close to the interview Writing on a whiteboard is different from typing on a keyboard If a problem is too hard, save it for later. . This will create positive momentum that will help you tackle harder problems later. Focus on making progress You can't afford to spend 5 minutes to write a while loop. . Be very comfortable in your preferred programming language (you can usually choose it). The better you know the language and the more fluent you are, the more time you will have during the interview to focus on the actual problem that you need to solve and to communicate your thoughts to the interviewer. You need to be in good coding shape Tech knowledge What you should know I'll enumerate the main topics you should be familiar with. You must know them cold if you target at FAANG companies. Data structures Theoretically and how to use them in code Arrays Strings Lists Stacks and queues Trees (and tries) Binary search trees (balanced) Hash tables Sets (disjoint sets too if you can) Graphs Algorithms Binary search Sorting Recursion Divide and conquer Dynamic programming Greedy Algorithms on strings On graphs (very important) DFS BFS Minimum spanning trees: Kruskal and Prim Shortest path: Dijkstra and Floyd-Warshall Some discrete math can help too. Programming languages I've always used C++, but the following good for interviews too: Python JavaScript Java Since most interviewers know them. Most candidates tend to go for Python. Whichever you choose, make sure you know it well. More resources MIT courses on algorithms is a great introduction to most of the concepts you will need in an interview. This course I would start here and only go to the next book for more in-depth explanations. Introduction to algorithms You do not need to go through the whole book, but it's a good complement to the previous course. It has everything you may need - and much more. Focus on the topics I have listed before. Everything else is but the chances of it coming up in an interview are slim. nice to know Cracking the coding interview. I did not start here though. I only completed the problems in the last 2 sections (medium and hard), after I finished the next book. Elements of programming interviews This is an excellent book. I keep coming back to it before every interview. The questions are hard, so you will be very well prepared. There are C++, Python, and Java versions. For more problems, I only used . You'll have more than enough with the free problems. https://www.leetcode.com Mistakes to avoid Let me help you avoid the most common mistakes I have seen so that you can nail your coding interview. 1. Not preparing Yes. People go unprepared. I’ve seen many people blank during an interview. I’ve had to cut interviews after 20 minutes. It happens more than you may think. Just as a reminder, you need to be good at the following: Algorithms Data Structures Language(s) of your choice CS Fundamentals I’ve previously covered resources for algorithms, data structures, and programming languages (through solving problems, a better way of learning than reading or watching tutorials). You should be able to assess what areas of computer sciences you need to brush up. 2. Not communicating what you think We interviewers cannot read your mind. Make sure you think out loud. We can stir you in the right direction before you waste too much time on the wrong approach. We assess your problem-solving skills, but to do that we need to know what you are thinking. Make your interviewer’s life easier and you’ll have a higher chance of landing that job. 3. Not asking clarifying questions The questions will be vague, on purpose. Make sure you state all your assumptions you start solving the problem. For instance: before Is the input sorted? Are there repeated elements? If no solution, what should I return? Do I need to check for invalid inputs? How many users do we expect? Trade-offs: increase space to be faster? 4. Solving the wrong problem Gather all requirements before starting. One small change can make the problem completely different. Repeat the problem using your own words, to buy some time to think about the solution, and to ensure you’re solving the right problem. 5. Wasting time If you don’t remember the API, just say: “Let’s assume the function is like this” and move on. You can assume you have the function you need and then come back to it and write it down in detail. An “imperfect” solution is better than nothing. 6. Not testing your code This is a huge red flag, so make sure you don’t fail here. Come up with a few test cases (there is no need to write the actual code): “Happy path” Edge cases Empty/null input Repeated elements 7. Not debugging it Take one or several of your previous test cases and run them through your code, line by line. Make sure you get the values you expect. Even if you miss something, the fact that you are doing this already gives a very good impression. 8. Poor time and space analysis Learn how to analyze the time and space complexity of your solutions. It’s just a chapter in any of the books I have listed before. 9. Going for the optimal solution First, come up with the brute force solution. No matter how slow or obvious it may sound. Having that is already a positive point. You don’t need to write code at this stage, but explain your solution in detail. If you cannot figure out a more optimized way of solving the problem, then you can start coding this solution. From there, try to find bottlenecks and come up with an efficient solution (usually using a different data structure or after sorting the input). It’s better than having nothing at the end of the interview because you tried to find the O(1) solution. 10. Not being fluent enough in your language of choice Usually, you can pick up the programming language you want for the interview. If you say you can code in Python, JavaScript or Java, make sure you don’t need 3 minutes to write a for loop (I’ve seen this many times). It is is not the end of the world if you forget API details or a semicolon. 11. Edge cases Do not forget to test for edge cases. I cannot stress this enough. Most problems you will be given will be vague and have edge cases just to see if you think of them when you face a new problem. 12. Low-quality code Write clean code. Not just for the interviews. Good naming, short functions that do one thing, etc. Read "Code complete" by Steve McConnell. This will increase the quality of your code. 13. "Hacking" mistakes away If you find a bug in your code (an off-by-one mistake, for instance) do not try to hack your way into the correct code. Take a minute to read what you have written, not what you believe you have written. Jot down some small examples and try to come up with a solution from them. Be systematic. We assess this too, not just the end result. 14. Jumping straight into code Do jump straight into writing code. NOT Solve the problem "by hand" Explain your solution Analyze it (in Big O) Find bottlenecks and try to come up with something more efficient After all this, you can start coding. 15. Not managing space well enough The whiteboard is limited. Leave some space between lines so that you can erase and modify your code easily if you need to. You can draw lines indicating where the new code would fit if you are running out of space. 16. Asking for feedback at the end Do ask for feedback at the end of your interview. Interviewers cannot give you the feedback (usually there are company policies to prevent this) and it gives a very bad impression: insecurity and inability to assess your performance. not Examples Try to solve the following problems on your own. Here, I will not write a complete solution but I will show you my thought process. With a little practice, turning your ideas into code will be relatively easy. Example 1 Given an array of integers, return indices of the two numbers such that they add up to a specific target. You may assume that each input would have exactly one solution, and you may not use the same element twice. This is a very easy problem, but enough to focus on the process. Things that come to mind: The input is an array of integers Is it sorted? What if it contains repeated elements? What if it contains negative elements? What if all the elements are negative/positive? What if the array is empty? How big is it? Return indices What if there is no solution? What if there are multiple solutions? You would need to ask some questions to the interviewer to clarify the most relevant points here. The questions about the array are pretty generic, created to make you think. In some cases, you may want to ask about the sign of the elements, if they are unique or repeated and if it is sorted. In other cases, ask what happens if the input is invalid - you may want to throw an exception or at least mention it even if you don't write the code for it. Regarding the output, you need to clarify what happens if there is no solution and if there is more than one. There are different approaches to this problem, with different time complexities. If you get stuck, try to mentally go through algorithms and data structures and see if they could help. Usually sorting and hash tables can simplify many problems. This is one of them. You can find the solution . here Example 2 Given a 2d grid map of '1's (land) and '0's (water), count the number of islands. An island is surrounded by water and is formed by connecting adjacent lands horizontally or vertically. You may assume all four edges of the grid are all surrounded by water. Thoughts: the number of islands. I need a counter (obvious) Count 2d grid map: Can I model this as a graph? I know and BFS DFS Islands are connected horizontally (same row) or vertically (same column), not diagonally I can only visit an island once, so I need some mechanism to avoid counting the same island twice. For instance, change the '1's to '0's (be it in the matrix we receive or in a copy we create if we can't modify the input) or a hash set where you store a pair of indices that define visited cells. I would go for the first option, but the second one is good to know since it can be used in other problems. After having these two pieces of information, it is just a matter of turning that into code. Choosing between DFS or BFS is something you want to discuss with your interviewer, depending on the constraints of the problem. If you can choose, DFS is shorter. Make sure you consider the case of an empty matrix, a matrix full of ‘0’ - zero islands-, full of ‘1’ - just 1 island- and other test cases. What happens If you see a ‘2’ when you’re scanning the matrix? This is also something to discuss with your interviewer, like any other assumption. In case of doubt, it is better to overcommunicate your thoughts. You can find the solution . here Conclusion As you have seen, there is little code here. This is because writing the code only comes after thinking and analyzing the problem. Turning it into code is (it obviously varies from problem to problem). Also, you can see how I’ve followed the process described in the last section: clarify the problem, come up with solutions, communicated with the imaginary interviewer, thought of edge cases, etc. This is what you should do until it becomes second nature. kind of the easy part Prepare, be systematic, and patient. It is a lot of work to prepare for these interviews, but in life anything worth having requires effort. PS: I hope you found this useful. If so, like and share this article, visit my blog , and let's connect on . www.yourdevopsguy.com Twitter Previously published at https://www.yourdevopsguy.com/how-to-ace-coding-interviews-the-ultimate-guide/