Coding interview prep (relax, start here)

We've helped hundreds of software engineers get their dream jobs, and we can confirm that preparation is everything. In fact, depending on your experience, you may well need 100+ hours of prep time to ace a FAANG coding interview.

That’s why you should start now, using this article as the basis for effective and efficient coding interview preparation. Follow the below steps, use the resources we link to, and give yourself the best possible chance of getting an offer at Facebook, Google, Amazon, or elsewhere.

Here’s exactly how you should prepare for your coding interview:

1. Own the process
2. Learn a consistent method
3. Refresh on data structures and algorithms
4. Practice solving example questions
5. Up your coding interview skills
6. Use books and courses
7. Practice with mock interviews

The sooner you get started, the more confident you’ll be when the time comes. Let’s go!

1. Own the process

Before you get down to the nitty gritty of coding practice, it’s worth doing some quick reading to understand what kind of hoops you’re going to be jumping through.

1.1 What is a coding interview like?

Coding interviews at top tech companies tend to last around 45 minutes.

You'll probably be asked to code in a specific app that the company uses for coding interviews. If you're in person, you'll be given a laptop to do this on. It's now quite rare for candidates to have to write code on a whiteboard, as used to be common at Google, Facebook, etc.

However, don't be fooled into thinking that your interview will be similar to solving problems on platforms like Leetcode. One of the most important aspects of a coding interview is collaboration, and so ideally it should feel like a conversation. You’ll be expected to talk through your solution with your interviewer and include them in your thought process.

You can also expect “trivia” type questions that test your knowledge about an area of coding, rather than asking you to solve a problem. These are most common in the early rounds, as the recruiter or hiring manager tries to get a sense of your level of expertise.

As well as coding problems and questions, you may face behavioral or cultural fit questions at the beginning or end of a coding interview.

1.2 How many interviews will I face?

That depends on the role and company you’re interviewing for. Software engineers usually face one or two technical screens involving coding questions as part of the early rounds, before 3 coding interviews at the onsite stage. Engineering managers and data scientists will usually face just one coding interview at the onsite stage.

Refer to our specific guides for each role and company to get the exact breakdown of what you can expect from the interview process, including the exact number of interviews and what type of questions you can expect in each.

1.3 When should I start preparing?

This obviously depends on many factors, such as how good at coding you are already and how quickly you learn things. However, using engineers we helped get offers at FAANG companies as a benchmark, we estimate that the median preparation time for a FAANG interview is around 100 hours.

If you don’t have a full-time job, you may be able to fit your preparation into a few weeks. However, most of the candidates we work with already work full-time, and so spread their workload over a couple of months or more.

They also told us that studying at least an hour or two every day was much more efficient than irregular bursts.

1.4 Which language is best to use in coding interviews?

The top tech companies all say that in the interview, you should code in whichever language you feel most comfortable using. More than anything, they want to see your clarity of thought and your problem-solving abilities, and it doesn’t matter what coding language you do this in, as long as it’s a language that’s known to a wide audience.

However, if you’re comfortable writing code in various  languages, you’ll have to weigh up various factors when you’re choosing which to use.

Java, Python and C++ all have the advantage of being widely used at FAANG companies, which make them a common choice for candidates.

Python has the advantage of being very efficient to write compared to Java and C++, and many candidates say this saves time in interviews. However, Java has the advantage of being a “real” (compiled) language rather than an interpreted language and some people say this may impress your interviewer.

Whichever one you choose to use, just make sure you’re comfortable in it and have been using it for a good few months before the interview.

2. Learn a consistent method

The problems you can expect to face in your coding interview are highly ambiguous and can usually be solved many different ways.

To guide and structure your thinking, you’ll therefore want to use a consistent answer framework that you can apply to each question.

One of our favorite approaches is summarized in the following video from Amazon:

Here is a summary of the approach:

Five step approach to coding interview problems

  • Step 1: Clarify
    • Ask clarification questions to remove ambiguity about the problem
    • Explore the edges of the problem
  • Step 2: Plan
    • Discuss potential approaches you could take
    • Pick an approach and lay out the high level steps
  • Step 3: Implement
    • Write clean code, not pseudocode
    • Comment on your code as you go
  • Step 4: Test
    • Start by testing with a simple example
    • Try breaking your code with edge and corner cases
  • Step 5: Optimize
    • Calculate time complexity
    • Discuss how you can optimize your solution

We strongly recommend you explore this framework, and our detailed version of it, by reading our article on how to answer coding interview questions. It's got a written example answer that will show you how to apply the framework, minute-by-minute, in your interview.

Using this framework will give you a structure which you can use to show your problem-solving skills and, of course, your coding knowledge, which we’ll move on to now.

3. Refresh on data structures and algorithms

Below we've provided a short overview of the most important data structures that are used in coding interviews. For each one, we've also included a link to a separate resource that provides a deep dive into that topic. You might want to skim this list, skipping the topics on which you're already clear and selecting the ones you want to refresh on.

3.1 Refresh on data structures

3.1.1 Arrays

An array is a list-like data structure that contains a collection of values, each associated with a specific index, usually with a fixed overall size. Arrays are one of the most fundamental data structures in programming and computer science, and many more complex data structures are built using arrays. The array itself is not always as simple as it might seem, and it forms the basis for many tricky interview questions.

Array basics.

3.1.2 Strings

A string is an ordered sequence, or string, of characters. It is usually considered a data type and is often included as part of language primitives. In most languages, strings are implemented using an array of bytes. The bytes are encoded using some character encoding. Earlier systems used ASCII encoding, with Unicode encoding used in later systems.

String basics.

3.1.3 Linked lists

A linked list is a data structure used to store a collection of data elements. In this way, it is similar to an array. However, unlike an array, the data elements in a linked list do not need to be stored contiguously in memory. Rather, each node in a linked list has a pointer or reference to the memory location of the next node in the list. This means that linked lists do not have a fixed size like arrays, and can easily grow and shrink as elements are added or removed.

Linked list basics.

3.1.4 Stacks and queues

Stacks and queues are similar and complementary in many ways. Both are a sequenced collection of elements that are generally accessed one element at time, and are implemented using similar data structures. 

Stacks are Last in First Out (LIFO) constructs. Queues are the opposite, being First In First Out (FIFO) constructs. These characteristics are what give these structures their name. A stack is analogous to a stack of physical objects, for example a stack of plates or chairs. The last plate or chair added to the stack is usually the first one removed when an item is needed. Similarly for a queue, the first person to enter a queue is usually the first person served.

Stacks and queues basics.

3.1.5 Graphs

A graph is an abstract data structure represented by vertices connected by edges. Vertices are also known as nodes. Vertices sharing an edge are known as adjacent.

In directed graphs, sometimes called digraphs, the edges between nodes have a direction attribute to show which way a relationship between two nodes goes. Non-directed graph edges have no direction, meaning the relationship goes in both directions.

Graphs basics.

3.1.6 Trees

A tree is an abstract hierarchical data structure. It is represented by a group of linked nodes, with a single root node. Each node can have zero or multiple children. A leaf is a node with no children.

Trees basics.

3.1.7 Maps

A map is a data structure that allows us to access a value by key. This is in contrast to an array that allows us to access a value by index. A common kind of map is a hash map (also called a hash table), which stores keys along with associated values (for example, a telephone directory, which associates phone numbers with names).

Map basics.

3.1.8 Heaps

A heap is a tree-based data structure that implements a priority queue. A priority queue functions much like a regular stack or queue, except that each element has a priority. It is this priority that determines which element is returned when dequeuing from the priority queue, rather than the order in which the element was added. This is useful for applications like a hospital queue where we want to serve the patient with the highest priority first.

Heap basics.

3.2 Refresh on algorithms

Of course, you'll also need to know your algorithms. Below, we've listed the most relevant ones for coding interview questions. As with above, you can skip the topics you're already confident on, and just click the link on the ones you want to study in more detail.

3.2.1 Depth-first search

We can categorize all data structures into two categories: Those with a simple option for visiting each item, and those with multiple, complex options for visiting each item. Data structures like arrays, list, stacks, and queues fall in the first category – we can easily visit each node in an array by traversing over the array indices; following each link for a list; popping from a stack; and dequeuing from a queue. But for a tree or graph data structure, it is not so simple.

A depth-first search (or traversal) is an option for visiting all the nodes in a tree or graph. In a depth-first search (DFS), we visit child nodes first before siblings.

Depth-first search basics.

3.2.2 Breadth-first search

Breadth-first search (BFS) is one traversal method for trees and graphs in which all vertices on one layer are visited before visiting their children on the next layer – i.e. every node on layer i is visited before the nodes on layer i+1.

Breadth-first search basics.

3.2.3 Binary search

Binary search is one of the fastest search algorithms because it halves the search space with each iteration. Binary search requires an ordered set that also has constant access times. This means that, of all the basic data structures, only sorted arrays are suitable for binary search.

Binary search basics

3.2.4 Sorting

Many algorithms require, or perform better on, a sorted dataset. Take searching as an example: to search an unsorted dataset of 1,000 items means looking at all 1,000 items in the worst case. In contrast, using binary search on a sorted dataset of 1,000 items means looking at 10 items in the worst case. For a bigger dataset of 1,000,000 items, searching it as unsorted is looking at 1,000,000 items at worst, but searching it as sorted is looking at 20 items at worst. Being able to sort data effectively can therefore yield returns later in an algorithm.

Sorting basics.

3.2.5 Dynamic programming

Dynamic programming is an algorithmic paradigm to create optimal solutions for complex problems by breaking them down into simpler sub-problems that can be solved recursively.

Dynamic programming basics.

3.2.6 Greedy algorithm

A greedy algorithm is an algorithmic paradigm that finds the optimal solution to a problem by breaking the problem down into smaller (local) parts and finding the best solution for each of these parts.

Greedy algorithm basics.

3.2.7 Backtracking

Backtracking is a form of brute-force problem solving, but with the ability to discard potential solutions early, before they are fully explored. It is an algorithmic paradigm for incrementally finding solutions to problems. As soon as a candidate route will not result in the final complete solution being valid, the algorithm will “backtrack.” Therefore, backtracking can be applied when it is possible to test the validity of partial solutions.

Backtracking basics.

3.2.8 Divide and conquer

Divide and conquer (DAC) is an algorithmic paradigm used to solve problems by continually dividing the problem into smaller parts until a part is easy enough to solve (conquer) on its own. The solutions to the solved parts are then combined to give the solution for the original problem. For optimization problems, being able to build an optimal solution based on the optimal solution of smaller parts is known as an optimal substructure.

Divide and conquer basics.

3.3 Refresh on Big O notation

To impress in a coding interview at a top tech company, you’ll need to show a good understanding of Big-O.

Big-O is a method of analysis used to measure an algorithm’s performance in terms of certain properties. When we design algorithms, we need to pick the algorithm that best meets our time and space constraints. Big-O provides us with a simple expression we can use to analyze and compare algorithms.

Big O basics.

4. Practice solving example questions

Once you’ve refreshed your knowledge on data structures and algorithms, you’ll want to start practicing solving coding problems. A lot of problems, in fact. Candidates that train with us have usually practiced hundreds of questions before their interview.

4.1 Data structure questions

So that you can see which data structures you most need to focus on, we recommend you start by going through the problems in our data structure questions article. You’ll find 9 example questions (with solutions) on each of the key data structures:

73 data structure interview questions (with solutions and cheat sheet)

When you want to practice more on a certain topic, just choose from the list below. We’ve arranged the questions by difficulty level (easy/ medium/ hard) so that you can quickly get a sense of what level you’re at:

  1. 50+ array questions with solutions
  2. 50+ string questions and solutions
  3. 40+ linked list questions with solutions
  4. 50+ stacks and queues questions with solutions
  5. 50+ graphs questions with solutions
  6. 50+ trees questions with solutions
  7. 50+ map questions with solutions
  8. 50+ heap questions with solutions

4.2 Algorithm questions

As with data structures, we recommend starting with our reduced list of algorithm questions, so that you can pinpoint which ones you need to improve on most:

71 algorithms interview questions (with solutions and cheat sheet)

When you’re ready to focus on a specific algorithm, just click on one of the articles below. Again, to help you measure your progress, the questions are organized into easy/ medium / hard.

  1. 50 depth-first search interview questions
  2. 44 breadth-first search interview questions
  3. 50 binary search interview questions
  4. 54 sorting interview questions
  5. 53 dynamic programming interview questions
  6. 50 greedy algorithm interview questions
  7. 47 backtracking interview questions
  8. 50 divide and conquer interview questions

    5: Up your coding interview skills

    There are plenty of engineers who can solve most coding problems on their own but end up failing their FAANG interview. Why? This is usually because their interview skills are not up to scratch.

    With the help of two interview coaches (who have conducted 300+ real and mock interviews between them), we put together a list of 21 tips for coding interviews. We’ve included 5 of them here to give you a snapshot of the sorts of things you can do to up your coding game:

    5 coding interview tips

    #1 Don’t jump straight to coding

    If you start writing code immediately after you hear or read the question, this is a huge red flag to your interviewer. For many interviewers, a candidate’s collaboration and communication skills are just as important, if not more important, than a candidate’s technical capabilities.

    So, jumping into your answer without asking clarifying questions or discussing possible approaches with your interviewer signals that 1) you haven’t thought through the answer, and 2) you won’t collaborate with your interviewer. Both are bad signs for how you will work with the team that you are applying to join.

    #2 Break the problem into smaller tasks

    The types of coding questions that are asked in tech interviews can typically be broken down into 2-5 tasks that will each take a few minutes to complete. While you’re making your plan, list out these small steps and explain them to your interviewer.

    As you work, cross out each of these steps one by one, and tell your interviewer (e.g. “I have completed task X, and now I will work on Y, then Z.”). This will give you a confidence boost each time you finish a smaller task. It will also give the interviewer a sense of how you will be able to tackle long-term, difficult projects on the job.

    #3 Use pseudocode to explain your thinking

    Interviewers want to understand how you think. When you’re explaining how you’re going to approach a problem, writing pseudocode is an excellent way to outline your plan and show your work to the interviewer.

    #4 Proactively acknowledge tradeoffs

    Any decision you make will have a tradeoff. So call them out in real time. Use it as an opportunity to discuss different options with your interviewer and explain why your choice is the best one. If you don’t bring up tradeoffs, your interviewer will almost certainly ask about them. So it’s better to beat them to it.

    #5 Listen for subtle hints

    If your interviewer tries to steer you in a direction, follow them. 99% of interviewers have good intentions, and they're trying to help you. 

    For more detail on these tips, plus lots of other ones, read the full article: 21 coding interview tips. 

    6. Use books and courses

    With the links we’ve provided in this article, you’ve already got the bulk of the preparation resources you need. But sometimes you’re probably going to want to go deeper and really study something inside out. That’s where books and courses can come into their own.

    Here’s a brief list of some of our favorite books and courses:

    For coding, there’s obviously Cracking the Coding Interview by Gayle Laakman McDowell, the overwhelmingly popular choice and still as relevant as ever.

    We also recommend this video of Gayle going through a problem at Facebook, which is definitely worth a view as you hone your answer method.

    If you feel like you need to do a course, Educative does great courses on coding and system design. We’ve also had candidates tell us good things about AlgoExpert.

    For the system design part of your interview, we recommend starting with our guide to cracking system design interviews. When you want to go deeper, System Design Interview: An Insider’s Guide by Alex Xu, has been recommended to us by a lot of candidates.

    (For transparency, we don’t earn anything from these links, we just like to pass on good recommendations.)

    7. Practice with mock interviews

    As you near the end of your coding interview preparation, we highly recommend improving your interview skills by doing mock interviews. 

    One of the main challenges of coding interviews is that you have to communicate what you are doing as you are doing it. You need to get used to this kind of "thinking out loud," and mock interviews are the best way to do that. 

    This can make the difference between performing just fine in your interview versus doing great and getting the job.

    7.1 Peer mock interviews

    A great place to start is to practice with friends. If you don't have anyone in your network who can interview you, you can sign up to the waitlist on our mock interview platform.

    7.2 Expert mock interviews

    Practicing with peers can be a great help, and it's usually free. But at some point, you'll start noticing that the feedback you are getting from peers isn't helping you that much anymore. Once you reach that stage, we recommend practicing with ex-interviewers from top tech companies.

    If you know someone who has experience running coding interviews at a big tech company, then that's fantastic. But for most of us, it's tough to find the right connections to make this happen. And it might also be difficult to practice multiple hours with that person unless you know them really well. 

    Here's the good news. We've already made the connections for you. We’ve created a coaching service where you can practice 1-on-1 with ex-interviewers from leading tech companies like Google.

    cta_illustration arrow_leftBrowse FAANG ex-interviewers
    Doing mock coding interviews with ex-interviewers from your target company will really help you improve at explaining your thought process, engage in the right kind of dialogue with the interviewer, and perform under pressure. Mocks are also extremely useful for the other types of interview rounds you’ll be facing, such as system design and behavioral.

    Make sure that you write down the feedback you receive after each mock interview session. Use it to create action items for yourself, to know exactly what you should do to improve. The more mistakes you make and address in mock interviews, the fewer mistakes you’ll make when it counts!