The Google loop, round by round

The night after my two onsite coding rounds, I asked Claude to look at the approach I had used in the first one. It found the problem in a few minutes: the algorithm I had used, a familiar pattern that peels a graph from the outside in, removes exactly the answers the problem was asking for. On some inputs it would return nothing when a valid answer existed. I was certain that round was a No Hire, and asked whether there was any chance of even a Lean Hire.

Both coding rounds came back Hire.

This post walks through the whole Google process as I experienced it, from the first recruiter conversation in March to the signed offer at the end of August: the format of every round, its result, what I think decided it, and the steps between the main loop and the offer that most candidates do not hear about in advance. It is part 14 of the 35 companies, 8 offers series, and it links to the preparation posts for each round. Google interview content is confidential, so I describe problems only by pattern and failure mode, never by statement.

The loop at a glance:

• ML domain round: Strong Hire
• Googleyness and Leadership: Strong Hire
• Two onsite coding rounds: Hire and Hire, one of them with an incorrect approach
• After the loop: a team-specific round, a team fitment call, hiring committee approval, a final team conversation, and the offer
• Elapsed time: about five months from the first recruiter call to the signed offer

Background: the shape of the process#

The recruiter described the loop in March as four 45-minute rounds for an ML and AI role at L4: an ML domain round and a Googleyness and Leadership (G&L) round online, then two coding rounds back to back, in person, each with a medium and a hard problem, written in a shared document with no IDE. Solutions are reviewed after the interview, and each round is scored independently by its own interviewer.

What the recruiter described less, and what took the most time, was everything around the loop: scheduling, rescheduling, a team-specific round, team matching, and hiring committee review. Google’s own guidance on structured interviewing explains the logic behind the core of it: interviewers score against rubrics, and the decision is made from the written evidence rather than from any single interviewer’s impression.

The full sequence looked like this.

graph LR
    A["Recruiter call<br/>late March"] --> B["Invite<br/>May 31"]
    B --> C["ML domain<br/>July 9"]
    C --> D["G&L<br/>July 15"]
    D --> E["Two coding rounds<br/>late July, onsite"]
    E --> F["Team-specific round<br/>August 12"]
    F --> G["Team fitment<br/>August 17"]
    G --> H["Hiring committee<br/>approval"]
    H --> I["Final team call"]
    I --> J["Offer signed<br/>August 31"]

    class A,B gray
    class C,D,E amber
    class F,G,I violet
    class H blue
    class J green

Scheduling: the dates moved#

The invite came on May 31, for June 24. Over the following weeks the dates moved several times: the ML domain round to early July and then to July 9, G&L to July 15, and the coding rounds to late July. A short prep call with the recruiter about a week before the domain round refreshed the scope and gave two pieces of advice I used: keep the introduction short, and treat each round as a conversation rather than an exam.

The moving dates were frustrating and, in hindsight, useful. Each delay added preparation time, and because my plan ranked topics by risk rather than by date, each move cost an hour of rescheduling rather than a rebuilt plan. The baseline post covers how.

ML domain round: Strong Hire#

Format. One online round covering ML and AI fundamentals, with a live implementation component.

What happened. The round was a wide sweep from classical ML through the internals of large language models, including writing a component from scratch. My strongest moments were the implementation and a discussion of systems optimization. My weakest were a derivation where I hedged instead of working it out aloud, a numeric slip, and one answer that stayed generic on an area I know well.

What decided it. In my view, the implementation. From-scratch implementation was the area I had ranked as my highest risk months earlier, and the mocks in the final week had found and fixed three regressions in exactly that area. My coach’s read afterwards was a likely Hire; the result was one level higher. The domain round post covers the preparation.

Googleyness and Leadership: Strong Hire#

Format. One online round of behavioral and hypothetical questions.

What happened. The interviewer was relaxed and conversational, with no pushback. My answers were grounded in specific events with numbers, and on one hypothetical I asked a clarifying question before answering, which my mocks two days earlier had flagged as a habit I was missing.

What decided it. Delivery more than content. The stories had been strong since March; what changed was structure (conclusion first), attribution (“we” for context, “I” for my contribution) and enough spoken practice that both held without thinking. My coach read it as a Hire; the result was Strong Hire. The G&L post covers the preparation.

The onsite coding rounds: Hire and Hire#

Format. Two 45-minute rounds back to back, in person, each with a main problem and follow-ups, written in a shared document.

Between the rounds. My plan for the short gap was deliberate: close the first round’s document without rereading it, stand up and move, tell myself the next interviewer knows nothing about the last round, review one pattern template, and breathe. The point is to stop a bad first round from leaking into the second, which matters because the rounds are scored independently.

Round one. A graph problem with a degree constraint. I recognized a familiar-looking pattern and used an approach that repeatedly removes outer nodes until a center remains. It was the wrong tool: it discards some of the very nodes the problem was asking for, and the correct approach was considerably simpler. I communicated clearly, coded cleanly and handled the follow-up discussion, but the core algorithm was not correct for the problem.

Round two. An interval problem: merge overlapping ranges and compute the gaps between them, with follow-ups that tightened the constraints on extra space and on sorting. This round went well, and I coded a follow-up as well as the main solution.

What decided it. I can only guess, but the evidence points one way. Communication, code quality, testing and complexity analysis count alongside the final answer, and a strong second round and strong earlier rounds count alongside a weak first one. Data from interviewing.io shows how much a single person’s interview performance varies, which is part of why one round rarely decides a loop on its own.

The lesson I took from round one is specific: I matched the problem to a pattern by its surface instead of reasoning from what a valid answer must satisfy. A minute spent on “what property must the answer have?” would have led somewhere simpler and correct. The DSA sprint post covers the preparation, including the process gaps this round exposed.

After the loop#

The coding results came back in early August. Then the process changed character: from being evaluated in general to being matched with a team.

graph TD
    A["Loop complete:<br/>SH, SH, H, H"] --> B["Recruiter shares<br/>team topics"]
    B --> C["Resume revised<br/>to surface them"]
    C --> D["Team-specific round:<br/>agentic AI"]
    D --> E["Team fitment call<br/>with hiring manager"]
    E --> F["Hiring committee<br/>approval"]
    F --> G["Final call with a<br/>senior team member"]
    G --> H["Offer call"]

    class A green
    class B,C gray
    class D,E,G amber
    class F blue
    class H green

Team-specific round, August 12. A one-hour round on agentic AI for the team’s domain, with an interviewer whose background was in ML infrastructure. Strong on designing systems I had built, weak on the internals of serving large models across hardware, and one inconsistent answer about my own past work. My coach read it as borderline. I advanced. The agentic AI post covers the week of preparation.

Team fitment call, August 17. A 30-minute conversation with the hiring manager. The introduction and outcome-led stories went well, and my questions about the team’s technical approach and roadmap landed. I also over-explained a past career transition, attributed a metric to the wrong system once more, and used too many fillers. After the call I did a structured decision analysis on the team and the role (scope, growth, location, how teams like it are seen internally) and the answer was to accept if offered.

Hiring committee and the final call. Hiring committee approval came in the second half of August. One more conversation followed with a senior member of the team, built around a deep dive into my resume and an agentic system design discussion. I prepared for it with a focused resume drill on my two most relevant roles and a baseline system design mock.

Offer. The offer call was on August 31, and I signed the same day. The negotiation gets its own post in this series.

Results#

Two things stand out in that table. The rounds I was most worried about (domain, because of implementation, and coding, because of where I started) came back at or above the bar. And my coach’s read was below the actual result on every round where I asked for one, which is why I stopped asking.

What I’d do differently#

Ask about the post-loop steps early. I learned about the team-specific round a few days before it was scheduled. Knowing in May that it might happen would have let me prepare agentic vocabulary and infrastructure fundamentals at a calmer pace.

Derive before pattern-matching in coding rounds. The wrong algorithm in round one came from recognizing a familiar shape. Asking first what a valid answer must satisfy is a ten-second habit that would have prevented it.

Keep one written statement of what I personally did. The two weakest moments after the loop were both about my own history: an inconsistent claim and a misattributed metric. A single page, reviewed before every conversation, would have closed both.

Stop predicting outcomes after rounds. My reads, and my coach’s, were consistently too harsh. The useful output of a debrief is the next fix, not a forecast.

Conclusion#

The Google loop is evaluated as a whole, by people reading written evidence from several independent interviewers. That cuts both ways: one weak round rarely sinks you, and one strong round rarely carries you. What carried my loop was preparation aimed at the specific risks in each round, delivery that made the evidence straightforward to write down, and enough consistency that a wrong algorithm in one round did not outweigh everything else.

Prepare for each round on its own terms, then let the loop be judged as a loop.

Part 14 of the 35 companies, 8 offers series. I join Google as a Software Engineer III, AI/ML, in October 2026.