In this article, I’ll detail a comprehensive plan to help you ace the coding interview. 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:
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.
Since 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.
This is what I will cover in this article:
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:
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.
Try to make your practice sessions as similar to the actual interview as possible. This includes:
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.
Mute your phone. No music. No internet. You want your practice sessions to be as realistic as possible.
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.
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.
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):
const vector<vector<int>> dirs = {{1,0}, {-1,0}, {0, 1}, {0, -1}};
for (const auto& d:dirs) {
const nextRow = row + d[0];
const nextCol = col + d[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.
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.
As I see it, there are two stages during your preparation.
First stage. You need to understand all the theoretical concepts and know:
Second stage. You need to be able to implement them and turn your ideas into code. This is what you get paid for.
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:
This is not about memorizing solutions. I repeat. Do not memorize the solutions. 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.
At this stage, I do not write any code. I just do everything I would do before I start writing code:
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.
Now, you can focus on writing the code for the problems you’ve “already solved”. Some tips:
I’ll enumerate the main topics you should be familiar with. You must know them cold if you target at FAANG companies.
Theoretically and how to use them in code
On graphs (very important)
Some discrete math can help too.
I’ve always used C++, but the following good for interviews too:
Since most interviewers know them. Most candidates tend to go for Python. Whichever you choose, make sure you know it well.
This course is a great introduction to most of the concepts you will need in an interview.
I would start here and only go to the next book for more in-depth explanations.
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 nice to know but the chances of it coming up in an interview are slim.
However, I didn’t want to fail my interview because I didn’t spend a couple of hours studying some sections of this book in detail. If you are serious about finding a better job and want to maximize your chance to ace coding interviews, you will want to check out this book.
This is a fun book by Steven Skiena. Very practical. It contains plenty of exercises and “war stories” where he shares experiences implementing the algorithms. There is also a catalog of the common problems that arise in practice and how to tackle them.
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.
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. Most of the questions I have seen in interviews were similar or at the same level of difficulty of the questions you will find in this book.
For more problems, I only used Leetcode. You’ll have more than enough with the free problems.
Note: I will write a separate article on systems design interviews, but if you want some good resources I strongly recommend reading Designing Data-Intensive Applications. It dives deep and compares different technologies: databases, distributed systems, how to process data, etc. I also suggest you read my guide to Google Cloud Platform to see how they have implemented some of these technologies and their pros and cons.
Let me help you avoid the most common mistakes I have seen so that you can ace the coding interviews.
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:
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.
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.
The questions will be vague, on purpose. Make sure you state all your assumptions before you start solving the problem. For instance:
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.
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.
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):
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.
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.
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.
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.
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.
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.
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.
Do NOT jump straight into writing code.
After all this, you can start coding.
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.
Do not 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.
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.
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
Return indices
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.
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:
Count the number of islands. I need a counter (obvious)
2d grid map:
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.
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 kind of the easy part (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.
Prepare, be systematic, and patient. It is a lot of work to ace the coding interview, but in life anything worth having requires effort.
You have probably heard lately the terms tokens, crypto tokens, and cryptocurrencies. In this article,…
Here you are going to see how to approach coding challenges like a pro and…
UTXO vs Account-Based Blockchains Introduction Bitcoin and Ethereum differ in many ways. In this article,…
This guide is a summary of my study notes for the Certified Kubernetes Application Developer…
Bloom filters are a data structure developed by Burton Howard Bloom in 1970. You can…
Merkle trees, also known as binary hash trees, are a type of binary tree. They…