How Google decides, from the recruiter screen to team match
Two decisions get made about you at Google, and almost everyone treats them as one. The first is whether to hire you at all. The second is which team will take you. They happen in that order, by different groups, and a candidate can clear the first and still stall on the second for weeks. Most of the confusion about the google interview process comes from not knowing that split exists.
The google interview process skeleton itself is stable and Google publishes it: recruiter screen, technical phone screen, onsite loop, hiring committee, team match, offer. What’s worth writing down is the texture inside those stages, because that’s where preparation actually pays.
Stage 1: the recruiter screen, which is really a levelling call
Thirty to forty-five minutes, usually non-technical. The recruiter is checking your background clears the bar and, more consequentially, deciding which level to slot you at.
That levelling decision propagates through everything after it. Your onsite difficulty is calibrated to it, and so is your compensation band if you get an offer. If you’re experienced and the level being discussed sounds low, this is the call to raise it on, politely and with evidence. Being put at L4 when your scope is L5 makes the rest of the process harder and the eventual number smaller. Public compensation bands by level are collated on Levels.fyi if you want to see what the gap is worth before that conversation.
Give the recruiter something specific to write down. “I worked on backend systems” gives them nothing. “I owned the API layer for a payments service handling around 40,000 requests a second” gives them a sentence they can paste into your profile. They’re building a written record from this call, and vague answers produce a vague record.
Stage 2: one problem, in a Google Doc
A single coding problem, forty-five minutes, conducted over Google Meet in a shared Google Doc. Not an IDE. Not a coding platform with a test runner.
That detail matters more than it reads. If every hour you’ve practised has been in VS Code or LeetCode’s editor, you’ve been leaning on autocomplete, syntax highlighting and instant feedback that won’t be there. Write code in a plain document a few times before this round. It’s a small change and it removes a real source of friction on the day.
Difficulty is usually around LeetCode medium. The interviewer wants working code and a coherent narration of how you got there. Ask clarifying questions before writing anything, state your first approach and its complexity out loud, then optimise. Candidates who think aloud tend to be rated better than candidates who reach the same answer in silence, which is a bit unfair to quiet people and is nonetheless how the rubric works.
Stage 3: the onsite loop
Four or five interviews, usually one day, sometimes split across two. Two or three coding rounds, a system design round for L5 and above, and at least one behavioural round.
Google’s own hiring material describes a structured approach, where interviewers work from consistent questions and a defined rubric rather than improvising. Its re:Work guide on structured interviewing sets out the reasoning. The practical consequence for you is that your interviewer is filling in a form, not forming a vibe, and every answer is being written down for somebody else to read later.
The behavioural round is the one candidates underprepare. Google refers to this dimension as Googleyness in its published material, though interviewers rarely use that word in the room. It’s assessing collaboration, comfort with ambiguity and how you handle disagreement. Prepare it with the same seriousness as a coding round, because it’s scored with the same weight.
Stage 4: what the hiring committee actually reads
Most candidates know a committee exists. Fewer know what lands in front of it, and that gap drives a lot of bad preparation.
The committee reads a packet: written feedback from every interviewer, the recruiter’s notes including the levelling call, any previous Google interview history attached to your account, and the hiring manager’s input if a team has already shown interest. It’s reading assessments of your performance, not meeting you. Nobody on it was in the room.
Two things follow. Your interviewer’s ability to write a persuasive account of your round is part of your outcome, which is partly outside your control and is a decent argument for making your reasoning easy to summarise. It is also why the google interview process rewards candidates who are explicit rather than merely correct. And one very strong round doesn’t reliably cancel a weak one, because the packet is read as a whole rather than averaged.
The how-we-hire page is Google’s own description of the sequence, and it’s worth reading in its current form rather than trusting any secondhand account, this one included.
The timeline, and why nobody can give you a straight one
People want a number of weeks and there isn’t a reliable one. The stages themselves are fairly quick; the queues between them are not.
Scheduling an onsite depends on interviewer availability, and interviewing is something Googlers do alongside their actual jobs. Committee review runs on a cadence rather than on demand, so a packet finished just after a sitting waits for the next. Then team match has no fixed length at all. Add holidays and quarter boundaries and two identically strong candidates can be four weeks apart for reasons neither of them influenced.
What this means practically: don’t stop other processes while you wait, and don’t read silence as rejection. If you have a competing offer with a deadline, tell your recruiter the actual date early. That is the one input that reliably moves the internal pace, and it stops working if you produce it at the last minute.
Stage 5: team matching, and why the wait gets long here
This is the part that surprises people. Committee approval means you’re hireable. It doesn’t mean you have an offer, because an offer needs a team with headcount that wants you.
Team match can run quickly or it can sit for weeks, and the variable is usually headcount rather than you. A candidate approved in a quarter where their specialism has few open roles waits longer than an equally strong candidate in a busier area. Recruiter timeline language has drifted longer for senior roles over recent cycles, and I’d treat any specific week count you’re quoted as an estimate rather than a commitment.
What you can do here is narrow: stay responsive, be honest about what you want to work on rather than saying yes to everything, and ask your recruiter directly how many teams have seen your packet. That last question gets a real answer more often than people expect.
Where the google interview process loses strong candidates
Not usually on the hardest problem. Four patterns come up far more.
Silent coding is the first. A correct answer with no narration reads, on the feedback form, as a candidate the interviewer couldn’t assess. Second is skipping the clarifying questions and solving a problem nobody asked for, which then costs the time you needed for the real one. Third is the behavioural round, prepared as an afterthought by people who spent six weeks on algorithms. Fourth is levelling: accepting a low level early and discovering at offer stage what it cost.
One opinion that could be wrong. I think candidates overinvest in exotic algorithm practice relative to system design and communication, particularly at L5 and above, where the design round and the write-up quality carry more of the decision than one more dynamic-programming variant will.
How to prepare for the parts that are not algorithms
Do the coding practice, obviously, and do some of it in a plain document. Beyond that, the underprepared surface is talking: narrating a solution while you write it, and answering behavioural questions without wandering.
That’s hard to rehearse alone, because alone nobody interrupts you and you unconsciously speed up. Craqly’s mock interview mode runs it on your desktop: it asks out of order, cuts in when an answer runs long, pushes on the parts you skipped, and gives you a transcript afterwards so you can see your own answer lengths and how much of the round you spent talking. Seeing that written down is the useful bit, since nobody judges it accurately in the moment. The free Starter plan is 20 credits a month, one credit being a minute of live session, and credits reset monthly. Paid plans start at $19 a month billed yearly, or $38 month to month, checked on 6 September 2026.
For the rounds themselves, the system design guide covers the L5 round, STAR structure covers the behavioural one, and the coding interview notes cover narration while you code.
If you take one thing from this: the levelling conversation on the first call is the fifteen minutes that shape everything after it, and it happens before anybody has tested you on anything.
