Key takeaways
Google's loop runs recruiter screen, one or two technical phone screens, a four to five interview onsite, then three stages you never see. Interviewers write up what they observed, a hiring committee that never met you decides from that packet, and team match pairs you with a group that's actually hiring. Every round scores some mix of four attributes, General Cognitive Ability, Role-Related Knowledge, Leadership, and Googleyness.
What are the stages of the Google hiring process?
Google's loop has more distinct stages than most companies, and the later ones are invisible to candidates. The full sequence usually runs:
- Recruiter screen
- One or two technical phone screens
- The onsite loop, now usually virtual, of four to five interviews
- Written feedback from each interviewer
- A hiring packet assembled by the recruiter
- Hiring committee review
- Team match, or host matching, depending on the org
- Senior leader and compensation committee review
- Offer
The part candidates obsess over, the onsite, is the middle of the process, not the end. Three of those stages happen after your last interview, with no further input from you. That structure is the single most important thing to internalize about Google's process.
Across the whole loop, Google scores candidates against a rubric it has used for years: General Cognitive Ability, Role-Related Knowledge, Leadership, and what the company long called Googleyness. Google's live re:Work guide to structured interviewing now summarizes the attributes as role-related knowledge, problem solving, and leadership, and Sundar Pichai narrowed the official definition of Googleyness at a company all-hands in December 2024. The four-attribute version is still how interviewers and candidates describe the loop in practice. Every interview in it is usually assigned one or two attributes to probe, and your interviewers know which one they own. When you can tell which attribute a given interview is testing, you can tell what kind of answer earns points.
Google has also studied how long the loop needs to be. Google People Analytics research, reported by CNBC from the company's re:Work blog, found that four interviews were enough to predict a hiring decision with 86% confidence, with diminishing returns on every interviewer after that; Google's 2016 interview data showed panels of four reached the same decision as larger panels 95% of the time. If your onsite is four or five rounds, that finding is why.
What does the Google recruiter screen for?
The recruiter screen feels like a formality. It is not. The recruiter is the person who will later assemble your hiring packet and, in many orgs, advocate for you in front of the committee. They are screening for two things on this call. First, the basic fit and level, meaning whether your background plausibly maps to the role and the seniority it's posted at. Second, and less obviously, whether you will be easy to represent on paper.
The most common failure here is a candidate who can do the work but can't describe it crisply. The recruiter is listening for whether you can summarize your own experience in a way that survives being written down. If you ramble for four minutes about your last project without landing on what you owned and what the outcome was, the recruiter now has to invent that summary for you later, and they will do it less well than you would.
An above-the-bar recruiter screen sounds like someone who already knows their own story. You can name your scope, name the level you're targeting, and connect your background to the role without being walked there. Treat this call as the first draft of your hiring packet, because functionally that's what it is. The same four dimensions show up in any recruiter screen, Google's version just carries further downstream.
What are Google's technical phone screens like?
The phone screen is usually one or two 45-minute coding interviews. Most of that time tests General Cognitive Ability through a problem you haven't seen, which is the point. Google's interviewers are explicitly trained to weight how you approach an unfamiliar problem over whether you produce a memorized optimal solution. GCA, in Google's own framing, is problem-solving on novel ground. Google learned this the hard way. Laszlo Bock, Google's former Senior Vice President of People Operations, told The New York Times in 2013 that "brainteasers are a complete waste of time. They don't predict anything. They serve primarily to make the interviewer feel smart." What replaced them is structured problem-solving on unfamiliar ground, scored against a rubric.
The reviewer is filling in a rubric, and the rubric has more rows than "did they solve it." They're scoring how you clarified the problem, how you reasoned about tradeoffs, whether your code was correct and clean, and whether you communicated while you worked. A candidate who silently writes a perfect solution scores worse on communication than one who talks through a slightly slower approach clearly. We cover the mechanics of that in the technical interview preparation guide, and the pattern holds doubly at Google because the interviewer has to reconstruct your thinking in writing afterward. If you didn't say it out loud, it didn't happen as far as the packet is concerned.
The most common trip here is jumping to code. The candidate hears the problem, recognizes a pattern, and starts typing. The interviewer's rubric has a row for problem clarification that the candidate just scored zero on. Spend the first few minutes restating the problem, naming the constraints, and confirming the inputs and edge cases. That is not stalling. That is points.
What happens in the Google onsite loop?
The onsite is usually four to five interviews. At least two will be coding, often one will lean toward systems design for mid-level and senior roles, and at least one is a behavioral and leadership interview. Each interviewer is assigned attributes to probe, and they score independently. They are deliberately kept from comparing notes before they write their feedback, so that the committee gets independent signals rather than a groupthink consensus.
For coding rounds, the bar rises from the phone screen. The reviewer wants to see not just a working solution but the judgment around it: which approach you chose and why, what you'd do differently at ten times the scale, how you'd test it.
For systems design, the strong answer has shifted in recent years. Reciting an architecture, "I'd use a queue here, a cache there," scores lower than it used to. The reviewer is checking whether you can define the problem before solving it. Strong candidates start by asking what the actual requirements are, what the read-to-write ratio looks like, who owns the service in two years. They hold the ambiguity long enough to find the one constraint that drives the design, then build from there.
The behavioral round is where Leadership and Googleyness get scored, and it's the round most candidates underprepare. Google looks for what it describes as emergent leadership, the willingness to step up and lead when your skills are needed and to step back when they're not, rather than formal authority. Googleyness covers comfort with ambiguity, a bias to action, and working well with others. These are not soft filler. At a company that runs cross-functional teams, they predict a large part of whether someone is effective, and the reviewer is scoring them as rigorously as the coding rounds. Structure these answers the way you'd structure any strong behavioral response, with a real situation, your specific actions, and a measurable result. Our behavioral interview guide and the STAR method guide both apply directly here.
How does the Google hiring packet work?
After your last interview, the loop goes quiet on your end and gets busy on Google's. Each interviewer submits written feedback with a score and a recommendation. The recruiter, sometimes with the hiring manager, assembles these into a hiring packet. The packet typically includes every interviewer's scores and written notes, your resume, the recruiter's summary, and sometimes references or work samples.
This packet is the only thing the hiring committee sees. The committee members did not interview you. They were not in the room. They are reading a document, and they are reading several of them in a sitting. Whatever didn't make it into your interviewers' written feedback effectively does not exist at this stage.
This is why communicating during your interviews matters more at Google than almost anywhere else. The interviewer can only write down what they observed and understood. If your reasoning was in your head, it's not in the packet. If you explained a tradeoff out loud, it likely is. A candidate who treats each interview as a chance to make the interviewer's note-taking easy, by stating their approach, their assumptions, and their conclusions clearly, ends up with a stronger packet than an equally skilled candidate who worked quietly.
How does the Google hiring committee work?
The hiring committee is a group of Googlers, usually senior, who review packets to make hire and no-hire recommendations. Their explicit job is calibration. Any single interviewer can be too generous or too harsh, can have a bad day, or can simply have an idiosyncratic bar. The committee exists to apply a consistent standard across thousands of candidates so that the bar at Google means the same thing regardless of which interviewers a candidate happened to draw. Dr. Melissa Harrell, a former hiring effectiveness expert on Google's People Analytics team, makes the case for the machinery on the live re:Work guide: "Structured interviews are one of the best tools we have to identify the strongest job candidates."
Two consequences follow from this, and both surprise candidates. The first is that a strong onsite can still result in a no-hire if the packet is mixed, because the committee weights the written evidence and a single weak interview with a specific concern can sink an otherwise good packet. The second is that the committee can request more information or send a candidate for an additional interview rather than reject outright, when the packet is promising but incomplete on some dimension.
There's nothing a candidate can do about the committee directly. What you can do is make every interview's feedback as strong and as clear as possible, because the committee can only act on what's written. The candidates who get held are often the ones who were strong in the room but left at least one interviewer unable to articulate why, which reads as a hesitant write-up, which reads as risk to a committee.
What is team match at Google?
Depending on the org and the role, getting a hire recommendation from the committee is not the same as having a job. Many candidates, particularly at the general software engineer level, are hired into the company and then matched to a specific team. This is team match, sometimes called host matching, and it's a stage candidates rarely prepare for because they don't know it exists.
In team match, hiring managers with open headcount review your packet and talk with you about their team's work. Both sides are deciding on fit. This is a real stage with real failure modes. A candidate who treats these conversations as a victory lap, having already cleared the committee, can stall in team match because no manager felt a strong pull. The managers are evaluating whether you're genuinely interested in their problem space and whether your background fits their needs now.
The way to influence this stage is to come in with a point of view about what you want to work on and why, while staying genuinely open. Managers respond to candidates who have done some thinking about where they'd add value, not candidates who will take anything. Team match conversations score much like a standard manager round, which Four-Leaf covers in what the hiring manager interview is really deciding. If you have a preference between, say, infrastructure and product work, having a real reason for it helps a manager see you on their team.
What's negotiable in a Google offer?
Once a team match lands, the offer goes through senior leader review and a compensation committee. Leveling at Google is consequential and somewhat sticky, because your level sets your compensation band and shapes your trajectory for years. Public leveling and compensation data, like the figures aggregated on Levels.fyi, can help you understand the bands, though treat any single data point as a sample, not a promise.
What's actually negotiable is mostly the components within your band, the equity refresh, the sign-on bonus, and sometimes the level itself if you have competing offers or evidence that the loop under-leveled you. The base salary tends to be the least flexible piece because it's tied tightly to level. The general principles of negotiating without overplaying your hand apply, and we go deep on the common errors in the salary negotiation mistakes guide. The Google-specific note is that leveling is the thing most worth getting right, because a level bump moves every component at once and compounds over time in a way a one-time bonus does not.
A stage-weighted prep plan
The mistake most candidates make is spreading prep evenly across the loop. Google's process rewards weighting your time toward the stages that carry the most evaluative weight and the most risk.
- Coding fundamentals, the largest block. Multiple rounds test this and it's where most rejections happen. Drill patterns rather than memorizing problems, and practice narrating your reasoning out loud, because at Google the spoken reasoning is what survives into the packet. The technical interview preparation guide lays out a timeline you can follow.
- Systems design, a meaningful block for mid-level and up. Committees over-index on it for senior roles. Practice defining the problem before designing, since that's the dimension that separates strong answers now.
- Behavioral and leadership, more than candidates give it. This is where Leadership and Googleyness are scored, and it's frequently the difference between a hire and a no-hire among technically strong candidates. Prepare specific stories that show emergent leadership, navigating ambiguity, and working across teams. Practicing these out loud, ideally in a realistic mock setting like Four-Leaf's AI mock interviews, builds the fluency that reads as confidence in the room and as clear signal in the write-up. We compared the best mock interview platforms by role and price if you want to weigh the options before committing to one.
- Your own narrative, an underrated block. The recruiter screen and team match both reward a candidate who can describe their scope, their growth, and what they want to work on. This costs little to prepare and pays off at the stages bookending the loop.
The one thing to remember
Google's process is designed to be resistant to any single interviewer's bias, which is good for fairness and demanding for candidates. It means you can't win the loop by impressing one person in one room. You have to generate clear, consistent, well-articulated evidence across every stage, because that evidence gets summarized, scored, and judged by people who will never meet you.
Prepare like the room is taking notes that a stranger will read, because that's exactly what's happening. Say your reasoning out loud. Attach your decisions to your outcomes. Make every interviewer's write-up easy to make strong. The candidates who understand the process is built around a written packet, not a performance, are the ones who give the committee an easy yes.
If you're running loops at more than one company, the contrast is worth reading. The Microsoft interview process publishes its competencies but no committee, and the Netflix interview process publishes almost nothing about its loop while handing you the culture document it expects you to argue with.
For how this compares against sixteen other employers, including which of them publish their process at all, see our guide to how tech companies run their interview processes.