Senior Engineer’s Guide to Google Interviews + Questions (2024)

Google’s interview process and questions

Google’s interview process consists of the following steps:

• Recruiter call
• Technical phone screen (and possibly a second technical phone screen)
• Onsite
• Team matching

Before we get into the details of each of these steps, here are a few general notes about Google’s job interview process, evaluation criteria, and interviewers.

All human organizations behave like a metaphor; Google isn’t a sports team, or a family, or an army. It’s a cool grad school. Larry and Sergey set up their offices based on the model of a Stanford campus on purpose. They wanted to create an environment and company culture where people can feel chill enough to talk about anything. In general, Google interviewers tend to be more collaborative than other FAANG interviewers. At Google, the slower you go, the faster you get there.

Google has one big, centralized interview process that’s completely divorced from which team you might end up on, which means that you will NOT, however, be interviewing with your future team members – Google has a horde of interchangeable technical interviewers who have all been trained on the same process. If you do well, there will be a team matching component at the end.

At Google, because the process is centralized, you cannot interview with multiple teams concurrently, which means you don’t get multiple shots on goal. Not only that, but Google has a limit for how many chances they’ll give you before you’re blocked from interviewing again.

Note that recently, there have been rumblings of Google changing their process to something more decentralized, where a hiring manager chooses you for a team before you interview, nullifying the need for post-onsite team matching. As far as we know, this new model is being tried out right now, but the change hasn’t been adopted company-wide.

Google also has rules for candidates who pass their interviews:

Google is not results-oriented. They’re process oriented. In other words, they care more about the “How” than the “What”. You’ve heard it before, and it’s true – they don’t need you to get to the optimal solution, but they do need to be impressed by your thought process. Because of this, Google is more attracted to comfort with ambiguity than speed.

Oddly, in spite of using a centralized interview process, Google doesn’t have in-depth training for its interviewers; it may surprise some candidates that there’s a larger-than-expected number of bad interviewers at Google.

Step 1: Recruiter call

Please see the section above called “A note about recruiter calls”

Step 2: Technical phone screen

Google’s technical phone screen is a coding interview that focuses exclusively on data structures and algorithms questions. Your interviewer will ask you to write code to solve a specific problem.

One idiosyncratic aspect of Google’s process is their insistence on using Google docs for writing code (versus other companies which tend to use tools like CoderPad). This can be a bit jarring for those of us who are used to writing code in an IDE that does things like auto-indentation, auto-complete, syntax highlighting, adding missing parentheses or brackets etc. Despite not using an IDE, your interviewer will expect you to produce syntactically correct code. This is really hard.

That said, more recently, Google has started interviewing using an internal tool with syntax highlighting, indentation and brackets completion. Whether you get to use it or not depends on your geography.

Step 2.5: (In some cases) Another technical phone screen

The second phone screen happens only if the first one did not produce enough signal to move forward. Perhaps you didn’t communicate your thought process well enough, your code wasn’t of good enough quality, or you weren’t fast enough – but it’ll be only one of these – if you struggled with two or all three, most likely you aren’t moving forward.

If you get a second phone screen it will be very similar to the first in terms of structure and content.

Step 3: Onsite

The Google onsite usually includes 4-6 rounds. Recently, there have been some internal experiments with the format, but generally the rounds are primarily coding, and secondarily system design. Some candidates get a single behavioral round, and others get to skip it.

The more experience you have, the higher proportion of system design and domain-specific questions you can expect to be asked.

Google’s interview types in detail

As we mentioned above, Google is process-oriented rather than results-oriented. As such, communication during coding and system design rounds is more important at Google than the end result.

Coding

The most important rounds at Google are coding. In fact, Google is the only FAANG company that considers coding to be more important than system design. Google’s coding rounds are about complexity more than speed. Their interviewers are allowed to ask anything they want, so it's more likely you might get a question you’ve never practiced before.

Google interviewers are more likely than any other FAANG company to purposefully design a question so it tricks candidates. For example, they’ll disguise a question to look like it’s Three Sum, but that’s a red herring – it’s not a Three Sum problem. It just looks like one.

A lot of what you’ll see in the onsite coding mirrors what you saw in the technical phone screen. During the onsite, you may see your interviewer layer more complexity on top of questions – they’ll design a question where they plan for you to get to the solution, then when you do they’ll move the goalposts and say something like: “Remember that assumption we made earlier about [X thing]? Let’s remove that. How would that change your approach?”

Even though they can ask whatever they want, Google interviewers have a question bank too, but the bank is much much bigger than Facebook’s bank and, like Facebook’s bank, it’s community maintained. Some interviewers never deviate from the bank, and others don’t touch it, preferring instead to formulate their own unique questions..

This speaks to Google rewarding the “how” (aka “how a candidate got there”) or their thought processes. It also speaks to Google rewarding comfort with ambiguity. Other FAANGs have specific niche topics they love hearing and talking about (such as “performance” at Amazon), but Google is more abstract. Google might love speaking about and asking about ambiguity more than any other FAANG.

Finally, Google’s coding questions are never practical. They are always theoretical. They will never ask you to pull up your own environment and write a program. They will also never ask you to take a solution to a coding problem and apply it to a real world scenario. When prepping for Google, only practice theoretical questions.

For everything you need to prepare for Google’s coding interview, check out the section called "Google coding interview preparation resources" below.

System design

The second most important onsite interview type at Google is system design. Again, they are allowed to ask anything they want, so don’t be scared off if you get a question you’ve never practiced before.

High-level and low-level system design questions are both likely. Some examples include:

• Design a load balancer
• Design Facebook Messenger
• Design an auth platform

Google system design interviewers also tend to design problems that include linchpin questions. These are questions where if you don’t ask about a specific aspect of the problem, you can’t really solve it. For example, an older system design question at Google asked you to set up a service in some foreign country, and in the prompt, the interviewer mentioned that you have a dependency on some third party service.

The linchpin question to ask: “What’s the service level agreement for that 3rd party service?” If you didn’t ask that (or something like it), then you wouldn’t be able to effectively reason about availability, which you’d need to do in order to do well on the question.

Behavioral

The least important round at Google is the behavioral round. They have the easiest behavioral screen in FAANG. Plus, you might complete an onsite at Google without a behavioral round because they’re optional. It’s not clear which candidates get them and which don’t. This is another reason to not prep too hard for their behavioral round.

If you do get some behavioral questions, they might be one of the following:

• Tell me about a time when you had a colleague who was difficult to work with.
• Tell me about a time you received negative feedback.
• Tell me about a time you were mentoring a more junior engineer and your feedback wasn’t getting through to them.
• If you were going to plan an offsite for the team, how would you do it?

Google is also more likely to ask you reflective questions. Most other FAANGs stick to situational questions such as, “Tell me of a time when…”. Those situational questions ask you to describe a past circ*mstance or scenario you’ve actually experienced and are fairly straightforward to answer. Reflective questions, on the other hand, can be tricky because they’re asking you to reflect on, or speak to, something less concrete, e.g., “What do you think about setting goals?”

The smart way to answer a reflective question is to re-formulate it, and then answer as if it’s a situational question. So, “What do you think about setting goals” instead becomes,”Talk about a time you used goal-setting as a time management strategy”, which you can now more-easily answer by describing a real experience and outcome, “The last time I set goals…etc”, as opposed to wading into theories about personal agency. “I think goals are cool and important…” might not get high marks.

How Google makes hiring decisions

Most of the time, the post-interview feedback process at Google is completely asynchronous, and interviewers don’t meet live to discuss hiring decisions. That’s one reason why interviewing at Google isn’t like interviewing with humans: it’s more akin to interviewing with a machine.

Each interviewer rates candidates on the following seven-point scale: Strong No-Hire, No Hire, Leaning No-Hire, On The Fence, Leaning Hire, Hire, and Strong Hire.

How this affects candidates is simple: a Strong Hire can get you an offer, but it can also buy you a second chance. If you don’t get an offer, but you get a Strong Hire from one of your interviewers, you might be offered one bonus interview round to decide whether you get an offer or not.

That said, you don’t need to get a “Strong Hire” to get a second chance. Overall, if you showed enough signal to not-fail but not enough to pass, sometimes they will ask you to do an additional round.

A “Strong No-Hire” bars you from interviewing at Google for some time. Reports vary here, but one of our Google interviewers told us that if you get a Strong No-Hire, you might be frozen out for several years.

If you passed overall then you will move on to the hiring committee phase.

Hiring committee review & team matching

Google’s hiring committee consists of four to five engineers and engineering managers who have not interviewed you, with the intent of making hiring decisions as objective as possible.

Going into the hiring committee review, your recruiter will prepare a packet that consists of your resume, any notes from the person who referred you (if you were referred), your recruiter’s notes from their call with you, and all the feedback from your interviewers, from the technical phone screen to the onsite.

When the committee meets, they evaluate all the data on you holistically, and they need a consensus in order to decide to make a hire.

Other than hire/no-hire decisions, the hiring committee will also decide on leveling. Ever since COVID and the rise of remote interviewing, we’ve gotten more and more reports from users that they’re being down-leveled at Google. Apparently the rationale is that Google doesn’t feel like they get as much signal from remote interviews as they did from in-person ones, and as such, when they don’t get enough of a signal for a hire but too much good signal for a rejection: they downlevel – when you want to reduce the probability of a false positives for L5… offer L4!

Engineers who are downleveled at Google accept the lower level offer a lot of the time, especially in the current climate. In some extreme cases, we’ve seen engineering managers with 10+ YoE accept an L3 (basically a new grad) offer.

Once you get past the hiring committee, you will move on to team matching. The team matching process is a bit like speed dating. In the ideal case, your recruiter will propose a few teams that are actively looking for someone with your skills, and then you’ll meet with the hiring manager from each team to gauge cultural fit and chemistry. In order to move forward, both of you have to opt in.

That said, there are rare instances where a candidate will get past the hiring committee but then not find a team that they gel with.

Google coding interview preparation resources

Here are some tips for preparing for your Google coding interview:

• Practice in teams; have someone make up a question. Then have them disguise it or plant a red herring in it (for example, purposefully have it look like Three Sum, but it isn’t Three Sum).
• Practice with someone who can change the parameters after you’ve solved the main question by saying things like “Remember that assumption X we made earlier. What would happen if we removed that assumption?”
• If you see a question online that has been marked as “Asked in a Google interview”, then it is not going to be asked in your interview, period. Google is very good at retiring questions that have been leaked.
• Practice without the aid of an editor or IDE: in a Google doc, on a whiteboard, or with pen and paper.

In addition, we’ve aggregated a bunch of useful Google content for you! We have replays of candidates doing mock interviews with Google interviewers, long-form solutions to common Google questions, and deep dives into technical topics that tend to come up in Google interviews.

Google interview replays

Below are a series of mock interview replays, conducted by Google interviewers on our platform. Watch them so you can learn from others’ mistakes.

Solutions to common Google questions

Below are common questions that interviewers from Google ask on our platform. Since our data comes from mock interviews, questions may not be exactly the same as what you'd see in real interviews.

Technical topics

To figure out what technical topics will come up in your Google interviews, we did two things. First, we spoke to a bunch of Google interviewers in our community. Then we cross-referenced all the anecdotes we heard with Glassdoor data AND our own data-set of mock interviews in the style of Google. Based on all of the above, here are the technical topics you’re likely to encounter:

Other Google interview preparation resources

System design

• A Senior Engineer's Guide to the System Design Interview
• Practice low-level system design questions, such as “Design a load balancer”, as much if not more than high-level system design questions, such as “Design Facebook Messenger.”

Behavioral

• While brushing up via a practice interview or two never hurts, this shouldn’t be your focus with Google. As they joke internally, just don’t be a serial killer!