Google Coding Interview (questions and prep)

To help you ace your Google coding interview, we’ve put together this guide. We give you an overview of what to expect, plus the topics you’re most likely to encounter and example questions from real candidates. We also recommend an effective answer framework and a simple prep plan.

Whether you’re applying for software engineer, engineering manager, machine learning engineer, site reliability engineer, data engineer, or other technical roles at Google, you’ll find this guide a great place to start with your prep.

Here’s what we’ll cover:

• What to expect
  • When will you face a coding interview?
  • How coding interviews work at Google
• Google coding interview question examples
  • Arrays & strings
  • Graphs & trees
  • Dynamic programming
  • Recursion
  • Math
• How to answer Google coding interview questions
  • Answer framework
  • Example answer
• Google coding interview preparation plan

Let’s get started!

1. What to expect

Let’s first look into a couple of details about Google coding interviews: when you’ll face them, and how they work at Google, specifically.

1.1 When will you face a coding interview?↑

If you’re applying for an engineering role at Google, you can expect to face coding questions at different stages of the interview process: 

If you’re applying for the engineering manager role, you may get asked to do a code review instead of a coding challenge during your onsite interview.

1.2 How coding interviews work at Google↑

The success of Google as an organization is driven by its strong engineering culture, and the standard of coding is second to none.

As a result, it's essential for all of the company's new engineers to have strong foundational coding skills.

That doesn’t mean you’re expected to get perfect marks during your coding interviews.

Here are the four main attributes that Google is on the lookout for during your coding rounds and the rest of your interviews:

• General cognitive ability. This is often referred to as "GCA" by Googlers. The company wants to hire smart engineers who can learn and adapt to new situations, including unfamiliar coding problems. Here your interviewer will try to understand how you solve hard problems and how you learn. For more information, take a look at our guide to the GCA interview.
• Role-related knowledge and experience. This is often referred to as "RRK" or "RRKE" internally. The company wants to make sure that you have the right experience, domain expertise and technical competencies for the position you're applying for. For more information, take a look at our guide to the RRK interview.
• Leadership. Google looks for a particular type of leadership called “emergent leadership.” You'll typically be working in cross-functional teams at Google, and different team members are expected to step up and lead at different times in the lifecycle of a project when their skills are needed. During your coding interviews, you’ll be assessed not just on your thought process but your ability to communicate it clearly. More information on this topic is in our guide to Google leadership questions.
• Googleyness (i.e. culture fit). During your coding interview, interviewers want to see if you exhibit the following values: being comfortable with ambiguity, having a bias to action, and having a collaborative nature. More information on this topic is in our guide to Googleyness questions.

A few more reminders during your coding interviews:

• You won’t have access to a compiler or IDE during your interview. So during practice, it’s best to get used to writing code on Google docs or a whiteboard.
• Time yourself during your coding practice. You’ll be given only a few minutes to solve a coding problem during your interview. Incorporate a timer when practicing so you get used to solving coding problems as fast as you can.
• For code reviews, take note of your language. If you’re an EM candidate and get a code review round, be sure to demonstrate Googleyness when you write your comments on the code. Provide positive feedback for a good line of code. Address problems and issues in a clear, concise, and respectful manner.

Now that you have an idea about how coding interviews work at Google, let’s take a look at the problems you may encounter.

2. Google coding interview question examples↑

According to Google SWE candidates on Glassdoor, Google typically gives Leetcode-style coding problems. They tend to level up in difficulty as you progress through the interview process. 

This means you could expect easy LC questions during your online assessment and then move on to medium to difficult coding problems in your phone screens and onsite interviews.

The general advice is to practice with the top 50 latest Google-tagged problems on Leetcode. 

Google also sends review materials and has a whole page dedicated to practice coding questions.

Based on our analysis of the 100 most recent SWE coding questions reported on Glassdoor, here are the most commonly asked coding topics at Google. We’ve also included the frequency they’re asked. 

• Arrays & Strings: 42.9%
• Graphs & Trees: 33.7%
• Dynamic Programming: 11.2%
• Recursion: 6.1%
• Math: 6.1%

Let’s take a look at each DSA topic, plus some coding question examples from real candidate reports.

2.1 Arrays & Strings↑

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. 

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.

Arrays and strings are two of the most fundamental data structures used in coding. Google asks questions related to these two topics to discern if you’ve got strong foundational skills.

Here are some example questions reported by SWE candidates on Glassdoor:

Check out our guides on array interview questions and string interview questions to learn more about the topics.

2.2 Graphs & Trees↑

Graphs and trees are both abstract data structures fundamental to computer science. Both are represented by nodes (also known as vertices) connected by edges. 

The main difference between the two is that trees represent a hierarchical relationship between nodes, while the relationship of nodes in graphs is arbitrary. 

Similar to arrays and strings interview questions, Google coding interviewers asked graphs and trees questions to assess your foundational skills.

Here are some example questions reported by SWE candidates on Glassdoor:

Check out our guides on graph interview questions and tree interview questions to learn more about the topics.

2.3 Dynamic Programming↑

Dynamic programming (DP) 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 methods are applicable to problems that have the following two properties:

• Optimal substructure: the optimal solution builds on the optimal solutions of smaller pieces.
• Overlapping sub-problems: the broken-down versions of the problem are repeated.

Some candidates on Glassdoor explicitly say that they were not asked DP questions, though there are quite a few who reported getting them. 

DP questions do take longer to set up and solve, so most companies might not ask them. But since real Google candidates have reported getting them, it’s best to still include them in your prep.

2.4 Recursion↑

Recursion is a process wherein you make a function call itself directly or indirectly. It is one of the most fundamental ways to solve a coding problem, and requires that you break down a complex problem into subproblems.

Aside from recursion, you should practice using other algorithmic techniques like greediness, divide-and-conquer, backtracking, sliding window, and iteration. In some cases, the most important step in your problem-solving could be deciding on an algorithmic technique.

2.5 Math↑

Google asks basic discrete math and math problems in a coding context from time to time. So if you’re not confident with your math, you may want to refresh your memory. 

Let’s take a look at some example questions.

3. How to answer Google coding interview questions↑

In this section, we’ll give you an answer framework for Google coding interviews and an example answer using the framework. 

We’ll also give you a rundown of what we think differentiates a good vs. great Google candidate during coding interviews.

Let’s begin.

3.1 Google coding interview framework↑

To learn how to answer Google coding interview questions, you must first be able to approach them systematically. 

You might solve a coding question in different ways, but at the end of the day, you need an approach that will consistently:

• Show your interviewer that you have the knowledge they need
• Break the problem down into manageable steps

Here’s a step-by-step approach that we highly recommend:

• Clarify
• Plan
• Implement
• Test & optimize

Below we’ll go into each step in detail. Let’s get started.

3.1.1 Clarify 

Don’t jump straight into the question without consulting your interviewer. Instead, start by asking questions to remove any ambiguity and to explore the edges of the problem. 

This is a good time to set up a dialogue with your interviewer. They are not just looking for a candidate who can solve a problem, but one who can work effectively in a team of other engineers. 

Let’s jump into how this will look during the interview.

Understand the question

If the question has been written down for you, take the time to read it thoroughly at least twice, to be sure that you’ve picked up on all the details. 

Repeat the question back to the interviewer in your own words, so that they can flag anything that you may have initially misunderstood.

Ask clarifying questions

Once you’re sure that you understand the basic question, clarify the unwritten details. For example, ask for constraints (e.g. 0<= N < 1000), consider edge cases, identify corner cases, specify what language you’ll be coding in, etc.

Specify assumptions

Finally, before starting work on the solution, consider any assumptions you’re making (e.g. input format, range, sorted or unsorted list, etc). Specify those to the interviewer, so that they can tell you if that is a correct assumption to make, given the problem.

3.1.2 Plan 

Now that you have a complete understanding of the coding question, it’s time to start making your plan. Here is where you can discuss potential approaches with the interviewer, pick the one that is the most appropriate, and lay out the high-level steps to get there.

Let’s take a look at how this will play out in the interview:

Find a solution

Take a few minutes to think through a solution to the problem. It does not need to be optimal at this stage. Map out your solution on the whiteboard or its virtual equivalent, making sure that what you add is comprehensible to both you and the interviewer. 

The goal is to find any solution (at least brute-force) and then find improvements. Keep walking through your steps out loud so that the interviewer can guide you.

Explain your solution

Before you implement your plan, make sure that you’ve brought your interviewer up to speed. If you’ve identified multiple approaches to the problem, go over each and explain why you’ve chosen the one you decide to move forward with. 

Ensure that the interviewer is aligned with your solution before you start coding. This will help you save time down the road and allow your interviewer to capture the right data points during your coding.

3.1.3 Implement 

Now it’s time for the main event. Write legible, clean code rather than pseudocode, and comment out loud on what you’re doing. 

Alternatively, if you have a hard time talking and writing, you can spend a few minutes coding quietly, then stop periodically to explain what you’ve done.

Optimize the solution

Once you’ve talked through your solution with the interviewer, optimize it. Consider any points you may have missed when you first thought of the solution, and what you can do to make it better. 

Explain your reasoning thoroughly and keep an eye out for the cues of the interviewer, which will let you know whether or not you’re on the right track. You can prompt them by asking, “how does that sound?” before moving on to coding.

Write the code

Now, write that code! Explain what you’re doing, and make an effort to write clearly—don’t use shorthand variables. Include descriptive variable names, structure the code well, consider boundary conditions or empty inputs, etc. 

Make your code modular and eliminate duplicate code.  If you realize you’ve forgotten an important function, simply go back and insert it, while clarifying what you’re doing out loud.

3.1.4 Test and optimize 

Once you have your code on the board, you’ve got to take the time to run through and test it, then optimize it given what you’ve found in testing. Start by testing with a simple example, then try breaking your code with edge and corner cases. 

Don’t forget to calculate the time and space complexity of your code, and discuss how you can possibly improve it. If you find any better solutions while testing and evaluating your code’s complexity, ask the interviewer if they’d like you to implement it.

Here’s how that will play out:

Test run your code

When testing your code, run it through multiple cases, starting with the basic use case, moving into a more complex case, and finally test for failure and edge cases. 

Consider anything that might break your code, and what you can do to address it [e.g. test cases like assertEquals(findMax(10,20), 20)].

Optimize your code 

Finally, work out the time and space complexity of your code. Explain it in simple terms to your interviewer, and use it as a jump-off point to consider ways you can optimize your code. 

If time permits, write out the optimal code and discuss it.

Q & A

These last few minutes of the interview are a good time to ask any questions you might have about the company and what your experience would be like working there. 

The interviewer may have additional questions for you as well. If the interviewer has clearly moved on from the coding problem, consider it finished and do not try to rehash any of its finer points.

3.2 Example Google coding interview answer↑

To illustrate the framework discussed above, let’s look at a mock coding interview Google posted on its YouTube channel. It shows a high-quality answer to a typical Google coding question.

Below, we’ve provided a transcription of the mock interview for your reference.

To review: first, take a look at the question, and think about how you would approach it. Then carefully watch and read the transcript below and see where their approach differs from yours.

Google mock coding interview example

Step 1: Clarify

Understand the question

Candidate: May I take a moment to read it and then ask a few clarifications?

Interviewer: Of course.

Candidate: Thank you.

Ask clarifying questions 

Candidate: So my first question: must it be a square? The area they want to farm, or could it be a rectangle?

Interviewer: For this problem? We only want it to be returning a square.

Candidate: Awesome. Okay, thank you.

Specify assumptions 

Candidate: I can think of like, the naive solution, but probably I shouldn't do this, but I'll just run it by you. I can loop over every position. And for every position, I can basically start from that moment onwards, go left and right, and count however many ones I can find in like a rectangle, or a square, sorry. But that would be if, if let's say the dimensions of the square is like n by n, that would be at best n to the four, which is not ideal. And I assume by posing this question, you want me to find an efficient solution.

Interviewer: Yes.

Step 2: Plan

Find a solution

Interviewer: I'm wondering if you can just visualize what maybe this brute force approach would look like. Maybe using the example.

Explain your solution

Candidate: Sure. Okay, so the brute force if I want to visualize it, so I just pasted the example:

Candidate: ...and I'm going to go over every index, [i] [j] index. And how to— the first, this is the second, this is the third, etc. Let's say we get here in this iteration. So [I] is becoming, let's say two, and [j] is becoming one. In this position, the row and column. So from this point, as every point that we go to, we start another double for loop, going to the right and bottom. So here I go one step to the right. There is a one, so I continue. And then I go to the bottom, there is a one and I continue. And then I go to the right of it, there’s a one, I continue. I wonder if that makes sense. So first we start saying, okay, when we get to this point, we have, you know, that we can do a one by one. Then we ask, can we do a two by two? And if the answer— to answer that, we have to complete the two by two triangle. So we have to look in this vicinity so to speak. 

Interviewer: Yes.

Candidate: Then we say okay now yes, I know I can do a two by two starting from this position. Can we— can I do a three by three? And to answer that we have to go on this like, wrapper. Like I'm going to select them one by one because it’s harsh otherwise. So we extend the boundary by one comma, and one row to check that they're all ones there. And then we keep track of the maximum. So if we arrived at three here, then I memorized the three is the best so far, and then until I loop over all the indices possible, maybe I'll update my three to something else and then I’ll return whatever number has been kept. But as we already said, this is not optimal, but it will do the job.

Interviewer: I  think that even though this may be a brute force solution, it would be the right approach in checking the nearby values and having that inform how large the square could be.

Candidate: Awesome. And I guess, do you want me to program this brute force solution, or am I'm going to be penalized and should I just think about something better?

Step 3: Implement

Interviewer: We can just move on to maybe what you would consider a more optimal solution. 

Candidate: Sure. Awesome. Okay, so these kinds of problems, I feel like I can solve them in two other different ways. The first one would be recursive. So here the recursion can say, let's ignore the zeros because as soon as I find a zero, we can just return. From this point, you can't have a square. But let's say we get to this point it’s like, “oh yes, there's a one so I can make a one by one.” Then we can ask, the surroundings, can we make more than one by one? And then, if I can ask the square next to me… Actually, let me think about it, okay. If this is a one, the right of it is a one. The bottom of it is a one. We can ask this— that I'm highlighting: how big of a square can you make it? Actually...

Interviewer: No, I think you're on the right track, that you're checking the right, below, and diagonal values. But because there is a zero here, does that mean it could be a valid square?

Candidate: Zero is invalid, right?

Interviewer: Yes, yes. That— that would be the case. So based on that, what can you infer that...if you're at that one position at the—that index, yeah.

Candidate: If I'm at the index...

Interviewer: What can you infer is the maximum square?

Candidate: At this index, it’s— it is a one because we can see the diagonal is already a zero. 

Interviewer: Yes, yes that's correct. But you then know that the neighboring values are also ones, so there is a possibility that those could have valid squares that are greater than one.

Candidate: Correct. Yes. I mean, in this specific case, because the diagonal is zero, that means this next to this one below it is a zero. Unless we're coming from above.

Interviewer:  That’s true. I guess the one below it. Actually neither of those, but you could potentially have, as you're saying, a recursive algorithm. How would that look then?

Candidate: So the recursive algorithm— I'm trying to think out loud as I'm describing the solution. So, basically when we see a one here, we can ask, can this be part of a bigger rectangle? And recursively, how would that look like? We have to ask the neighbors how much—how many ones they have consecutively, contiguously.

Interviewer: Hmmm

Candidate: So that could be saying that, okay, there's a one here, then we can invoke a recursive call that says how many ones are starting at the right of me making a square? So if— I wish I can highlight, but let's imagine me — I'm going to bold this.

Interviewer: Okay.

Candidate: And this— the one that I'm highlighting...

Interviewer: Yes.

Candidate: I’m thinking. Right. Because you can do more than three by three. Okay. So, now we can think about the base cases of the recursion, so to speak.

Interviewer: Yes.

Candidate: So the base case—if we had a zero, then we can do— we return a zero.

Interviewer: Yes.

Candidate: If we had a one, then we ask the right and the bottom to do the recursion. We invoke them. 

Interviewer: Yeah.

Candidate: And we return their minimum.

Interviewer: Yes.

Candidate: I'm trying to think, at which case do we—in which case do we grow? I’m thinking we can grow...Let me think. So if this— if the red one, hypothetically said, “I could do a three by three.” I'm just thinking. And the bottom one can say, “I can do a three by three.” I need to think that—there has to be a way that we can grow the one. You know, we have to return a five or something eventually. So if the right of me can say, “I can do a three by three,” which, you know, so maybe I can hack the numbers again, just for the sake of example...

def largest_square(bin_array)

def largest_square(bin_array: np.ndarray)->

def largest_square(bin_array: list[list[int]]) ->

def largest_square(bin_array: list[list[int]]) -> int:

def largest_square(bin_array: list[list[int]]) -> int:
 n = len(bin_array)
 dp = [[n]*0 for i in range(n)]

def largest_square(bin_array: list[list[int]]) -> int:
 n = len(bin_array)
 m = len(bin_array[0]) 
 dp = [[n]*0 for i in range(m)]

def largest_square(bin_array: list[list[int]]) -> int:
 n = len(bin_array)
 m = len(bin_array[0]) 
 dp = [[n]*0 for i in range(m)]
 for i in range(n):
  for j in range(m):

def largest_square(bin_array: list[list[int]]) -> int:
 n = len(bin_array)
 m = len(bin_array[0]) 
 dp = [[n]*0 for i in range(m)]
 for i in range(n):
  for j in range(m):
   if(bin_array)[i][j]==0:
    continue

def largest_square(bin_array: list[list[int]]) -> int:
 n = len(bin_array)
 m = len(bin_array[0]) 
 dp = [[n]*0 for i in range(m)]
 for i in range(n):
  for j in range(m):
   if(bin_array)[i][j]==0:
    continue
   left = right = diag = 0
   if i > 0: left = dp[i-1][j]
   if j > 0: right = dp[i-1][j]

def largest_square(bin_array: list[list[int]]) -> int:
 n = len(bin_array)
 m = len(bin_array[0]) 
 dp = [[n]*0 for i in range(m)]
 for i in range(n):
  for j in range(m):
   if(bin_array)[i][j]==0:
    continue
   left = right = diag = 0
   left = dp[i-1][j]*int(i > 0)
   if i > 0: left = dp[i-1][j]
   if j > 0: right = dp[i-1][j]

   left = right = diag = 0
   left = dp[i-1][j]*int(i > 0)
   if i > 0: left = dp[i-1][j]
   if j > 0: right = dp[i-1][j]
   if (i > 0 and j > 0): diag = dp[i-1][j-1]

 left = right = diag = 0
   left = dp[i-1][j]*int(i > 0)
   if i > 0: left = dp[i-1][j]
   if j > 0: right = dp[i-1][j]
   if (i > 0 and j > 0): diag = dp[i-1][j-1]
   if (left > 0) and (right > 0) and (diag > 0):
    dp [i][j] = min ([left, right, diag]) + 1

def largest_square(bin_array: list[list[int]]) -> int:
 n = len(bin_array)
 m = len(bin_array[0]) 
 dp = [[n]*0 for i in range(m)]
 for i in range(n):
  for j in range(m):
   if(bin_array)[i][j]==0:
    continue
   left = right = diag = 0
   if i > 0: left = dp[i-1][j]
   if j > 0: right = dp[i-1][j]
   if (i > 0 and j > 0): diag = dp[i-1][j-1]

   dp [i][j] = min ([left, right, diag]) + 1

rowwise_max = [max(row) for row in dp]
return max (rowwise_max)

def largest_square(bin_array: list[list[int]]) -> int:
 n = len(bin_array)
 m = len(bin_array[0]) 
 dp = [[n]*0 for i in range(m)]
 max_num = -1
 for i in range(n):
  for j in range(m):
   if(bin_array)[i][j]==0:
    continue
   left = right = diag = 0
   if i > 0: left = dp[i-1][j]
   if j > 0: right = dp[i-1][j]
   if (i > 0 and j > 0): diag = dp[i-1][j-1]

   dp [i][j] = min ([left, right, diag]) + 1
   max_num = max(max_num, dp[i][j])

return max_num