Preparing for the Google ML domain round

Six days before my Google ML domain round, I ran a mock where every question asked me to implement something from scratch in NumPy. Logistic regression held. Backpropagation through a two-layer network held. A pairwise ranking loss held. Then three things I had marked “done” weeks earlier came apart: an embedding layer with its backward pass, matrix factorization, and attention. And four more (k-means++ initialization, a 2D convolution, batch normalization and He initialization) I had never once written cold without help.

That was the point of the mock. Implementation from scratch was the weakest skill I had, and it sat directly under my strongest area of knowledge. I could explain how attention works in depth; I could not reliably write it on a blank page with someone watching.

This post describes how I prepared for the round: a topic universe built from the recruiter’s scope and public candidate reports, a readiness bank with a fixed shape per topic, a final week of clean-room mock interviews, and the specific gaps each mock exposed. It is part 9 of the 35 companies, 8 offers series. I do not describe any question from the real round; the topics below come from the scope my recruiter shared and from public preparation material.

For context, this was the ML and AI domain round of a Google Software Engineer III loop in India, one 45-minute interview. My background was production ranking and personalization, LLM systems, and a first-author NLP paper.

The headline results:

• Implementation regressions: caught six days before the round, in a mock rather than in the interview
• Mock sessions in the final week: more than a dozen, across debugging, pipelines, implementation, ranking, LLMs, statistics and resume defense
• Coach’s read after the real round: likely Hire
• Actual result: Strong Hire

Background: what the round tests#

The recruiter described the scope twice. In late May the list was ML fundamentals, NLP, generative AI, computer vision, ranking and recommendations, ML pipelines, implementing neural networks from scratch, and supervised, semi-supervised and unsupervised learning. A call three days before the round added debugging, LLM usage and evaluation, fine-tuning, activations and the bias-variance trade-off, and similarity search, with light coverage of MLOps. The recruiter’s advice on delivery was short: keep the introduction brief, and treat the round as a two-way conversation rather than an oral exam.

Three properties of the round shaped everything else.

It asks scenarios, not definitions. Every L4 ML question I found in public reports was an applied scenario: a model that looks better offline and worse online, a loss going to NaN, a fine-tuned encoder that improves recall on rare queries but hurts click-through rate. Reciting what something is earns little; reasoning about what to do earns the score.

It is often built from your resume, then drilled. Chip Huyen’s ML interviews book describes open-ended design questions that draw on your experience building and deploying models, and notes that nearly every company asks at least one. At Google the resume is the natural starting point: you describe a system, and the interviewer probes it until you reach the edge of what you know.

It can pivot from design to implementation. A design discussion can turn into “now implement the scoring layer” with no warning. That pivot is where candidates with strong design and weak implementation lose the round.

The L4 bar is applied execution and reasoning, not research depth. Preparing like it was a research qualifying exam would have spent my time on the wrong things.

The preparation architecture#

The preparation ran as a pipeline from scope to mock results and back.

graph LR
    A["Recruiter scope"] --> D["Topic universe<br/>with priorities"]
    B["Public candidate<br/>reports and guides"] --> D
    C["My resume"] --> D
    D --> E[("Readiness bank:<br/>12 entries")]
    E --> F["Daily study chat<br/>with retrieval warm-up"]
    F --> G["Clean-room<br/>mock interview"]
    G --> H["Four-bucket<br/>results"]
    H --> I["Coaching and<br/>retest"]
    I --> E

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

The topic universe split the round into seven areas with priorities: implementation from scratch, applied modeling and debugging, model and pipeline design, statistics and experimentation, core theory breadth, responsible AI, and a small SQL safety net. Each topic carried a P0, P1 or P2 tag. LLM topics were P1 by default and would become P0 if the team turned out to be LLM-focused.

The readiness bank turned each area into an entry with the same shape: likely questions, points I must be able to explain, things I must be able to derive without notes, and one worked example to read but not answer. The worked example existed to show the shape of a strong answer (conclusion first, a number or trade-off attached, the failure mode named) before I studied the material. An entry was done when I could answer its likely questions cold, hitting every must-explain point.

Each day opened with retrieval. Two or three random questions from earlier P0 topics, answered cold before any new material. That warm-up is what eventually exposed the implementation regressions.

Implementation from scratch#

This was the area I ranked first, and the one that took the most repetitions.

The depth bar came from public material on ML coding rounds. Yuan Meng’s overview of ML engineering interviews describes the ideal candidate as able to write common architectures and their building blocks from memory, and to overfit a toy dataset to prove the model learns. I adopted that as the standard: NumPy, forward pass, loss, backward pass and update, then a quick overfit on a tiny batch, with the math narrated as I wrote.

The mock six days out sorted my list into three groups:

The regressions were the important finding. All three had been marked complete in my bank. None had been practiced cold in the previous two weeks, and all three had decayed. I spent most of the remaining implementation time on those three and on convolution and batch normalization, which Google-focused coaching material specifically called out, and left the long tail (Adam from scratch, recurrent cells, beam search) as reading only.

I also settled on one style for every implementation and stuck to it: a small class, NumPy first, a shape comment on every array, a small epsilon wherever division or logarithms could blow up, and no abstraction beyond what the problem needed. A consistent style meant one less thing to think about while someone watched.

Debugging and pipelines#

Debugging was the topic I judged my weakest on the theory side, so it got the longest single mock: 21 questions across scenarios (offline gains with online losses, NaN loss, embedding collapse, training-serving skew, stale features), production diagnoses, and short code snippets with planted bugs.

Two things came out of it. First, the gaps were mostly mechanical: an off-by-one error in batching, and integer division silently truncating values because of an array’s data type. Second, I caught the coach steering me toward one expected answer when my different answer was also valid. The protocol changed to accept any correct angle and grade the reasoning.

The most useful framing for this whole area was a short list of lead hypotheses. When a model does well in evaluation and badly in production, the first suspect is point-in-time correctness: features at training time that would not have been available at prediction time. Martin Zinkevich’s Rules of Machine Learning makes the same point from the engineering side: log the features used at serving time and train on them, share code between training and serving, and treat a gap between offline and live performance as a probable engineering error rather than a modeling one.

A separate pipelines mock surfaced a cluster of “I don’t know” answers on ordinary but under-practiced topics: target encoding, normalization versus standardization, handling missing data in neural networks, random versus grid search, the inputs to an A/B test sample size, and canary deployments. None were hard. All were things I had done in production without ever having to explain them, which is exactly the gap an interview finds.

Resume defense and LLM depth#

Later that week, a mock built entirely from my resume produced five “I don’t know” answers in a row, all on terms I had listed myself. That story is told in the resume post in this series; the fix was a plain-language explanation of every term on the page, drilled until each survived three follow-ups.

The same mock caught a verbal slip I kept repeating: I called one system “ads” when it was a notifications system, even after being corrected twice. Small slips like that read as confusion about your own work, which is the worst kind of confusion to show.

LLM depth was the area where my knowledge was strongest and my risk was different: not ignorance, but imprecision under pressure. The preparation document covered transformer architecture at production depth, pretraining and scaling laws, the fine-tuning stack from supervised fine-tuning through parameter-efficient methods, inference optimization (key-value caching, attention variants, quantization, speculative decoding), retrieval-augmented generation, agents, evaluation and safety. The drill that mattered most was arithmetic: sizing memory for model weights and caches at different precisions, out loud, without hedging.

For anything I genuinely did not know, I practiced a recovery script rather than more content: say what I do know, name the class of the problem, derive from first principles instead of recalling, ask one scoped clarifying question, and flag uncertainty honestly at the end. A structured partial answer scores; silence does not.

The final week#

The last week before the round was almost entirely mocks, each in clean-room mode (the coach saw only my resume), each followed by bucketed results and targeted coaching. The topics covered implementation, debugging, pipelines, ranking and recommendations, loss functions and regularization, probability and statistics, evaluation metrics, activations and optimization, NLP, computer vision, LLM usage and evaluation, fine-tuning, and a resume-grounded domain mock.

The round moved one more time that week, finally landing on July 9.

Results#

The round came back Strong Hire. Without describing any question: it covered a wide sweep from classical ML through LLM internals and included a live implementation. 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. My coach’s read after the debrief was a likely Hire; the actual result was one level higher.

What the preparation changed is easiest to see in the implementation table: every component in the regressed and never-written groups had been practiced cold at least once before the round. The mocks did not make me know more. They found, with six days to spare, the specific places where knowing was not enough.

What I’d do differently#

Retrieve “done” topics on a schedule. The three regressions happened because I treated completion as permanent. A fixed spaced-retrieval schedule for every closed P0 item would have caught them weeks earlier.

Start mocks earlier. The mock gauntlet was compressed into the final week because the round kept moving. Two mocks a week from the start would have spread the same discoveries over a calmer month.

Practice arithmetic aloud. My weakest moments in the real round were numeric. Sizing calculations deserve the same cold repetition as code.

Write the plain-language glossary first. Every resume term, explained in plain words, should have been the first document I wrote, not one I wrote after a bad mock.

Conclusion#

The ML domain round rewards applied reasoning about systems you have built, and punishes gaps between what you know and what you can produce on demand. The most valuable preparation was not more reading; it was a pipeline that kept testing whether knowledge was still available cold, and a week of mocks that found where it was not.

Know your material, but test it the way the round will: cold, aloud, from a blank page, with someone asking why.

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