Technical interviews: how to prepare

This post describes the technical preparation for software engineering interviews. It is geared towards big companies, such as Google and Amazon, which require a deep knowledge of algorithms and data structures. The same tips hold true for companies with similar processes such as TopTal or, partially, Zalando.

In this post, I will devise a plan to prepare for such interviews. To read about my actual experiences interviewing for these companies, refer to the following posts: Google, Amazon,, TopTal.

Table of contents


Step 0: Make a plan

How to organize your time

First off, you need to break down your preparation in smaller units. This has many benefits such as being able to estimate when you’ll be ready, track your progress, and know in which area to focus next.

In general, I’d recommend splitting your time as follows:

  • Algorithms and data structures: 60% of your time
  • Mock interviews: 20% of your time
  • System design and company-specific questions: 10% of your time
  • Behavioral questions: 10% of your time

The most important topic is algorithms and data structures and it is covered in the section below.

Mock interviews are extremely important, yet often underestimated. You might train your algorithmic skills all day long but if they don’t come out during the interview, you are going to fail. With services that offer free peer-to-peer interviews such as Pramp and InterviewBit, I’d start as soon as possible and do as many as possible, even one per day. The goal is to feel no different when you solve a problem in front of your laptop or in front of an interviewer.

Next, system design questions are important but standards are lower. A discrete performance in system design with an excellent performance in algorithms likely means ‘hire at a lower level’. Instead, an excellent performance in system design with a so-and-so performance in algorithms means ‘no hire’. I spent about a week on system design, solving problems from Cracking the Code Interview, Elements of Programming Interviews and InterviewBit.

Finally, behavioral questions and company-specific questions vary from company to company. For example, Amazon is keen on candidates that show leadership traits and have OOD knowledge. Google puts almost no emphasis on behavioral questions. is after business sense and deep interest in A/B testing. Adjust your time accordingly. In my preparation, I spent about two days writing and rehearsing stories from my past work experience. That was all of my preparation for behavioral questions.

For more planning tips, write me a quick comment below.

How to break down algorithms and data structures

Algorithms and data structures is the most important topic. It is also a very broad topic. It is easy to get lost in it and forget some areas. Under-preparing in some areas reduces the probability of passing the interview.

I started my preparation from Cracking the Code Interview. I created a Google Doc and, for each chapter, I wrote down a list of the problems I’d done and a list of the problems I had to do. In this way, I could tell if my preparation was slowing down or going smoothly and I could estimate how long it would take to complete.

Half-way through, though, I felt it wasn’t enough.

The main issue is that, although Cracking the Code Interview is a terrific start, it doesn’t contain enough problems, especially it doesn’t contain enough hard problems (around 20 as far as I remember) and it doesn’t contain enough variations of problems requiring techniques you might find hard to internalize.

My suggestion is, therefore, to finish all the problems in Cracking the Code Interview first and then turn elsewhere for more practice. For example, Elements of Programming Interviews contains more and harder problems. Another terrific resource is InterviewBit, which not only breaks the topics down into specific techniques but also offers an easy way to track your progress with gamification for your own motivation.

I particularly enjoy the way InterviewBit approaches preparation and keep on using it to prepare for coding competitions. Breaking down the main topics in specific techniques is a clever way to spot gaps in your preparation. Their online judge lets you test your code for subtle bugs. This is good when your coding skills are sharp but don’t rely on multiple submissions to pass:  in a real interview, you get only one shot.

There are other platforms for coding challenges but they mostly focus on coding competitions. Examples include Topcoder, Hackerrank, Codechef, and Leetcode. They are amazing tools for improving your problem-solving skills but problems are harder than, and employ techniques outside the scope of, technical interviews. (e.g. segment trees, bipartite matching).


Step 1: Execute the plan

How to solve problems

Once you have your list of problems down, you have to start solving them. I spent about six months on problems, starting with Cracking the Code Interview and moving on to InterviewBit and Elements of Programming Interviews. My goal was one problem per day. This takes into account I work full-time, you can do way more if you are a student. Furthermore, just to give you an idea, I started scheduling interviews around the third month of my preparation.

When you drill on a problem, spend the first couple of minutes to understand it. Read it multiple times and make sure you understand all the constraints before attempting a solution. After this step, you should at least see a brute-force solution. It is important to vocalize this solution during your interview and tell your interviewer its time and space constraints.

After the brute-force solution, you might see the real solution right away or have no clues on how to proceed. If you are stuck, here are some approaches you can take to move on:

  • Solve an example by hand and extrapolate an algorithm
  • Simulate the brute-force solution by hand and start noticing inefficiencies you can optimize with a data structure or technique
  • Solve an easy version of the problem first, then lift your solution up
  • Explore the problem, especially its constraints, and write down assumption and simplifications

Sometimes this won’t be enough and you will be stuck. You need to decide whether to spend more time or read up on the solution. If you are starting out, I’d try to go deeper and analyze all your ideas before giving up. If you have even a hunch about an approach, go on and find out why it works or not. Spend even couple of days on each problem before giving up.

After some hundreds of problems, your intuition will tune up and you will know more quickly when you won’t be able to make any further progress. The deciding moment is when you blank out and, even after a long break, no idea comes up to mind.

For more detail on how to approach a particular problem, leave me a comment below.

How to learn new techniques

The best ways to learn new things is when you need them. This applies to algorithms as well. When you are stuck on a problem, you’ll read up the solution and find that it involves some new tricks. They are often only sketched and you’ll have to do some research to understand them more deeply.

In this case, I’d keep it simple and just search the technique on YouTube. I prefer watching a video demonstrating the execution of an algorithm than reading about it in a book or editorial. Seeing the algorithm in action makes your understanding much more rooted. If you only have a written version of the algorithm, you should still try to run it manually at least once.

If you can’t find a video or you need more depth, the next step is to look up resources on GeeksforGeeks or Topcoder editorials. They are both great, with the second being very deep and detailed. Finally, if you need the proof for an algorithm, you can look it up in Introduction to Algorithms, but keep in mind proofs are outside the scope of interviews.

After you understand the solution, always code it up and apply it to your problem. If you have test cases, make sure all of them pass. Look up the implementation only if you are completely stuck. This will make you internalize the technique much better than just reading about it somewhere sometime.

How to improve your coding skills

When you start practicing algorithms, you might find yourself making stupid mistakes all over the place. This is completely normal and just an indicator you need more practice. You should be able to go from idea to code with almost no effort.

This is actually very hard and there will be always problems where it is not easy to do. But for many problems, coding is easy and, if you get stuck in it, it means your solution wasn’t clear from the start. Common problems include what to do on edge conditions, off-by-one errors, and how to organize your code (e.g. how many loops you need, can you write this with loops or you need recursion,  what concrete data structures you are going to use, etc). Get into the habit to work out these details before jumping into coding and you will save a lot of time.

Another problem is to be very familiar with your programming language and its API. You might be an excellent Android developer but have no clue how to write files on disk using the standard Java API. And then your interviewer asks you to write merge sort from disk.

To avoid this problem, the only medicine is practice: keep solving problems and you will learn a lot of little details about your language and the most common patterns that come up in algorithmic problems. There are plenty of corner cases such as when numbers overflow, the quirks of floating-point arithmetic, tricks to parse input, collections APIs and more.

A side-note here: many interviewers don’t care about the exact API calls of your language. Still, memorizing them will show more expertise but it will make you faster when practicing against an online judge.

Let me know down in the comments what you think, or if you want more information on any particular topic. Any comment is greatly appreciated!


Here is a collection of resources, for ease of reference. They mostly appear in the post but there some additional ones as well.