Chapter 24 · Interview preparation
The Google Applied Scientist and MLE Loop
What each round assesses, how the scoring and hiring committee actually work, and a preparation plan that maps every round back to the chapters of this course — including an honest list of what this course does not cover and where to get it.
[!] Read this chapter differently from the others
Every other chapter in this course describes things that are true independently of who is reading — a Poisson distribution behaves the same way this year and next. This chapter describes a company's internal process, which changes without notice, varies by office and by team, and is reported second-hand.
So treat the specifics as informed expectations rather than facts, and the structural advice as the durable part. Where a claim comes from a named practitioner or a recurring pattern across many reports, this chapter says so. Where it is general reasoning, it says that too.
[i] Who this is for
Candidates targeting applied scientist, research scientist, or machine learning engineer roles. The coding rounds are shared with software engineering, so chapters 22 and 21 apply directly; the difference is everything layered on top — ML system design, modelling depth, experiment design, and a research or project deep dive.
24.1 Sources and how to read them
Interview advice is unusually prone to confident invention, so it is worth being explicit about where the claims in this chapter come from and how much weight each deserves.
| Source | What it supports | How much to trust it |
|---|---|---|
| Aggregated interviewer and candidate reports published by interviewing.io, including direct quotes from people who have interviewed at Google | Process shape, the seven-point rating scale, hiring committee mechanics, the relative weighting of coding versus system design, the deliberate use of disguised questions | High for structure, moderate for specifics — these are first-hand but individual accounts, and practice varies by office and team. |
| A published account by a named engineer with roughly a decade across Meta and Google, writing specifically on ML engineering roles and ML system design interviews | The five assessment areas in an ML system design round, and how expectations differ for generalists versus specialists and for infrastructure versus modelling teams | High for the shape of ML rounds; it is an insider account of running them. |
| Google's own public research and careers pages | Which research areas exist and where, and the existence of a centralised process | High but thin — official pages describe values, not scoring. |
| General reasoning from the rest of this course | The preparation plan, the round-to-chapter mapping, and what a good answer contains | This is the author's synthesis, not reported fact, and is labelled as such where it matters. |
[!] Three things reported consistently enough to plan around
The process is centralised. You are generally not interviewed by your future team, which is why team matching is a separate later stage. Coding is weighted heavily. Multiple accounts describe Google as the one large tech company where coding matters more than system design. Process beats result. Reaching the optimal answer without communicating the reasoning is repeatedly described as insufficient. Everything else in this chapter is more variable than these three.
24.2 The shape of the process
[→] The stages, in order
- Application or referral, then a recruiter call. Largely logistical, but it sets your provisional level.
- Technical phone screen. Coding, on data structures and algorithms.
- Possibly a second phone screen, which happens when the first did not produce a clear enough signal — not necessarily because you failed.
- Onsite, typically four to six rounds. Primarily coding, secondarily design, plus the ML-specific rounds for these roles and sometimes a behavioural round.
- Hiring committee. Four to five engineers and managers who did not interview you review the written packet and decide.
- Team matching. Finding an actual team with an actual opening, after the hire decision.
- Offer and levelling. Level is decided by the committee, not by your interviewers.
[+] Two consequences of centralisation worth planning around
You cannot interview with several teams at once, unlike some other large companies, so you get one attempt per cycle rather than several parallel shots. There are also reported limits on how often you may reapply after unsuccessful attempts, which makes each attempt worth preparing for properly rather than using as a practice run.
Your interviewers may know nothing about your speciality. A centralised pool means the person assessing you may not work in machine learning at all. Pitch explanations accordingly — assume a strong generalist engineer rather than a specialist in your subfield, and define your terms.
[≡] A process in flux
There are reports of experiments with a more decentralised model in which a hiring manager selects you for a specific team before you interview, removing the separate team-matching stage. As of the sources used here this was not company-wide. Ask your recruiter which process you are in — it is a reasonable question and it changes how you should think about team matching.
24.3 How scoring actually works
Each interviewer independently submits written feedback and a rating on a seven-point scale: Strong No-Hire, No-Hire, Leaning No-Hire, On the Fence, Leaning Hire, Hire, Strong Hire. The feedback process is largely asynchronous, so your interviewers typically do not meet to discuss you — the written record is the artefact the decision is made from.
[!] The most actionable reported fact in this chapter
Uniformly middling scores tend to fail. One Google interviewer describes candidates receiving five "Leaning Hire" ratings and positive recruiter feedback, and still being rejected. Meanwhile a single "Strong Hire" can carry weight, and can even earn an extra round to resolve an otherwise borderline packet.
The strategic implication is genuinely counter-intuitive: being uniformly decent is a losing profile. If a round is going well, do not coast to a comfortable finish — push for a clearly exceptional performance in that round, because one outstanding signal is worth more than several adequate ones. Conversely, a Strong No-Hire is reported to carry a cooling-off period, so a round that is going badly is worth actively salvaging.
[+] Write for the note-taker
Because the decision is made from written feedback by people who never met you, your real audience is an interviewer trying to reconstruct your reasoning afterwards. Anything you did not say out loud does not exist. State your assumptions, name your trade-offs, and summarise your solution and its complexity at the end — you are effectively dictating the summary paragraph of your own review.
24.4 Which role are you interviewing for
"Applied scientist" and "machine learning engineer" describe overlapping but genuinely different jobs, and the loop composition follows the job. Working out which one you are in tells you what to prepare.
ML teams sit on two axes: infrastructure-focused versus modelling-focused, and research-oriented versus application-oriented. A team building training pipelines and deployment frameworks wants different evidence from a team improving ranking quality, which wants different evidence again from a team publishing at NeurIPS.
| Team type | What the loop emphasises | What is de-emphasised |
|---|---|---|
| ML infrastructure — training platforms, serving frameworks, pipelines | Strong general software engineering, distributed systems, general system design. Closest to a standard SWE loop. | Deep modelling knowledge, unless the role is explicitly hybrid. |
| Applied ML generalist — ranking, recommendations, integrity, ads | Breadth: the end-to-end lifecycle from problem framing through features, modelling, evaluation and deployment. Practical intuition across supervised methods, embeddings and metrics. | Frontier-level depth in any single subfield. |
| ML specialist — a named subfield such as NLP, vision, or reinforcement learning | Depth: current research, benchmarks and datasets in that subfield, and the ability to read and apply papers. | Broad coverage outside the speciality. |
| Research scientist | Publication record, research presentation, open-ended modelling problems. Some research loops reportedly reduce or skip conventional coding rounds in favour of whiteboard proofs and a talk. | Production engineering concerns. |
[+] The question to ask your recruiter, verbatim
"Is this role closer to ML infrastructure or to modelling, and is the team applied or research-oriented?" Recruiters answer this readily, and the answer redirects your preparation substantially — toward distributed systems for the first, toward lifecycle breadth for the second, toward your subfield's recent literature for the third. Asking it also signals that you understand the space, which does no harm.
24.5 Recruiter screen
Assesses: almost nothing technical. Decides: your provisional level, which is harder to move later than it is to set now.
Treat this as the round where you gather information rather than perform. Ask which process you are in, whether the team is infrastructure or modelling, how many rounds to expect and of what type, and what level the role is targeting. Recruiters generally answer all of this.
[!] Down-levelling is common and starts here
There are consistent reports of candidates being levelled lower than expected, and of those offers being accepted anyway. Two practical responses. First, describe your scope in terms of ownership and impact rather than years, since level maps to scope. Second, if you are told you have passed the onsite, ask whether you can submit an updated CV for the hiring committee — some recruiters allow it, and the committee may see only that version. Your original application CV was probably optimised for a keyword filter rather than for a group of senior engineers deciding your level.
Prepare from: nothing technical. Have a two-minute summary of your background and one crisp statement of the largest-scope thing you have owned.
24.6 Technical phone screen
Assesses: data structures and algorithms, exclusively. Format: 45 minutes, code written in a shared document.
This round is identical to the software engineering screen, and it is where ML candidates most often underprepare — the assumption that an applied science role will go easy on algorithms is wrong, and coding is reportedly the most heavily weighted round type in the entire loop.
[!] Practise in a plain document, not an IDE
Google has historically used Google Docs for coding interviews — no syntax highlighting, no autocomplete, no bracket matching, no execution. More recently some locations use an internal tool with highlighting and bracket completion, but which you get depends on geography. Prepare for the harder case: write code in a plain document for a few sessions before the interview. Candidates who have only ever written Python in an editor drop colons and mismatch indentation under pressure, and it reads as carelessness rather than as a tooling artefact.
[+] A second phone screen is not a rejection
It is reported to happen when the first screen did not generate enough signal — unclear communication, or code quality, or pace — rather than a clear failure. If you get one, press the recruiter for specific feedback first. You will often be told nothing, but when you are told something it is unusually valuable, because it names exactly what the second screen will be checking.
Prepare from: chapter 22 in full, and chapter 23 if the role is data-science adjacent. The first ninety seconds routine in 22.2 matters more here than anywhere, because a 45-minute round punishes solving the wrong problem.
24.7 Onsite coding rounds
Assesses: the same material as the phone screen, with more room for follow-ups. Weight: the heaviest in the loop.
Three properties of Google coding rounds are reported consistently, and each has a direct preparation implication.
| Reported property | Implication |
|---|---|
| Interviewers may ask anything; the question bank is large and community-maintained, and leaked questions are actively retired. | You will likely see something you have not practised. Pattern recognition (chapter 22) beats problem memorisation, and it is the only thing that transfers to an unseen question. |
| Questions are sometimes deliberately disguised to resemble a well-known problem that they are not. | Verify the preconditions of a pattern before applying it. Section 22.20 exists for this round. |
| Complexity matters more than speed, and interviewers often layer additional constraints once you solve the base problem. | Expect the follow-up that removes an assumption. Finishing early is not the goal; the extra time is where the harder signal gets generated. |
[+] An unusually specific practice technique
Practise with a partner who deliberately plants a red herring — who makes a problem look like a standard one and then confirms it is not — and who withdraws an assumption after you solve it: "remember when we said the values were distinct? Suppose they are not." This is drilling the two things this round actually tests, and it is very different from solving problems alone against a timer.
Prepare from: chapter 22 entirely, with 22.18 through 22.21 weighted heavily. These rounds are graded on communication as much as correctness.
24.8 ML system design
Assesses: whether you can take a vague business problem to a deployed model, and where the edge of your knowledge is. Format: open-ended discussion, 45 to 60 minutes.
This is the round most specific to these roles, and there is a clear published account of how it is assessed, from an engineer who has run them. The interviewer does not know in advance whether you are a generalist or a specialist, and the round is explicitly designed as a conversation to discover the edge of your knowledge — which means being taken to the limit of what you know is the intended outcome, not a failure.
[→] The five areas you are scored on
- Problem framing. Do you explore the business context and connect the ML decision to the business problem, rather than jumping to a model?
- Data collection. How would you obtain training data? Do you raise bias, cold start, labelling cost, and privacy without being prompted?
- Features. Can you identify the relevant signals and their relative importance, and reuse information already available in the system?
- Modelling. Can you justify the choice, keep it consistent with your feature decisions, and describe the architecture?
- Evaluation and deployment. Offline and online testing, launch experiments, caching, and rollback strategy.
[+] Generalists and specialists are graded differently on the same question
Both must cover all five areas, but the weighting differs, and knowing which profile you are presenting matters. For a generalist, the verdict the interviewer is trying to reach is roughly "I would trust them to get the first versions of this system running" — which means offering two or three techniques at the modelling stage and being solid on practical concerns like evaluation latency versus feature availability, train/test contamination, and caching.
For a specialist, the verdict is "I would trust them to build the most optimised version of this in the company" — which means briefly covering the standard options and then going to state-of-the-art methods in your subfield, the trade-offs between them, and how you would adapt them to this specific problem. A specialist is not expected to be strongest outside their area, and pretending otherwise is worse than saying so.
[!] Ask more questions than feels natural
Google design rounds are reported to include linchpin questions — details that, if you do not ask about them, make the problem unsolvable. The published example involves a dependency on a third-party service where the unasked question is "what is its service level agreement?", without which you cannot reason about availability at all. The defence is to front-load clarifying questions well past the point of comfort. In this round, asking is scored, not penalised.
Prepare from: chapter 5 (retrieval), chapter 18 (ML foundations, especially metrics and calibration), chapter 19 (launch experiments and rollback), chapter 16 (service boundaries), chapter 12 (data layer), and chapter 6 (serving and latency). The five areas map almost exactly onto those chapters.
24.9 ML breadth and depth
Assesses: whether your understanding is mechanical or memorised. Format: rapid questions, often escalating in depth until you reach your limit.
The reliable structure of this round is that every question has a "why" behind it, and the interviewer keeps asking why until you stop having an answer. Preparing by memorising definitions fails immediately; preparing by being able to derive things works.
| Opening question | Where it escalates to | Revise |
|---|---|---|
| Explain the bias-variance trade-off. | Why does adding data reduce variance but not bias? What does regularisation actually do to the loss surface? | Chapter 18 |
| How do you handle class imbalance? | Why is accuracy the wrong metric? When is PR-AUC better than ROC-AUC, and why? | Chapter 18 |
| What is attention? | Why divide by the square root of the key dimension? What is the complexity in sequence length, and what breaks at long context? | Chapter 2 |
| How would you evaluate a retrieval system? | Why does recall at k matter more than precision for a reranking pipeline? How do you build the evaluation set without leakage? | Chapters 5 and 18 |
| Your model says it is 90% confident. What does that mean? | Is it calibrated? How would you check? Why is an LLM's stated confidence not a probability? | Chapter 18 |
| Why is cross-entropy the loss for classification? | What is its relationship to maximum likelihood? What happens to the gradient when the model is confidently wrong? | Chapters 18 and 20 |
[+] "I do not know" is a scoring move, used correctly
Since the round is designed to find your limit, reaching it is expected. The distinguishing behaviour at that point is to say so plainly and then reason forward anyway: "I have not worked with that directly. Based on how the related method behaves, I would expect X, because Y — is that roughly right?" That demonstrates calibrated self-knowledge and the ability to reason under uncertainty, both of which are being assessed. Confabulating is the failure mode, and experienced interviewers detect it immediately.
Prepare from: chapters 18, 2, 3, 5 and 19. Chapter 20 matters more than candidates expect here, because "why does this loss function look like that" questions bottom out in probability.
24.10 Statistics and experiment design
Assesses: whether you can tell a real result from noise. Appears in: applied scientist and data-science-adjacent loops especially, and as follow-ups inside the ML design round.
This round exists because shipping a model requires proving it helped, and the failure mode it screens for is a candidate who can train a model but cannot establish that it works. Expect questions on experiment design, sample size, and the many ways an experiment silently lies.
| Question | The underlying check | Revise |
|---|---|---|
| Design an experiment for this model change. | Randomisation unit, primary metric chosen in advance, guardrail metrics. | Chapter 19 |
| How many users do you need? | Whether you can actually compute it, and know that halving the detectable effect roughly quadruples the sample. | Chapters 17, 19 |
| The result is significant after three days. Ship it? | Peeking. Repeatedly testing until significance inflates the false positive rate substantially. | Chapter 19 |
| Your two arms have 51,200 and 48,800 users. Any concern? | Sample ratio mismatch — a split that far from 50/50 is essentially impossible by chance and indicates a bug that invalidates the experiment. | Chapter 19 |
| Model A scores 0.71 and model B scores 0.73 on 200 queries. Is B better? | Whether you reach for a significance test rather than accepting the point estimate. On 200 queries that gap is comfortably inside the noise. | Chapters 17, 19 |
| The metric moved but only in one country. Real? | Multiple comparisons and segment fishing — test enough segments and one will look significant by chance. | Chapters 17, 19 |
[+] The answer pattern that works across all of these
State the null hypothesis, name the test, state what would change your mind, and give a number where a number is computable. "I would treat this as a two-proportion test; with 200 queries per arm and a two-point difference the interval is far too wide to conclude anything, and I would want roughly an order of magnitude more data before separating them." A quantified answer with a stated assumption beats a qualitative one every time in this round.
Prepare from: chapters 17, 19 and 20 — and chapter 23 if the loop is data-science leaning, since the simulation questions cluster here.
24.11 Research and project deep dive
Assesses: whether the work on your CV is genuinely yours and whether you understand it beyond the summary. Format: you present, they interrogate.
For research roles this is often a formal talk on your published work. For applied roles it is usually a conversational deep dive into one project. Either way the interrogation follows a predictable path, and the questions are the ones you were hoping not to be asked.
[→] The questions that always come, in roughly this order
- Why this approach and not the obvious simpler one? The single most common question, and the one where "it is what the team was using" is a losing answer.
- What was your specific contribution? Be precise about the boundary between your work and your collaborators'. Overclaiming is detectable and fatal; underclaiming loses you the round.
- How did you know it worked? Which metric, measured how, against what baseline, and with what confidence.
- What did not work? A candidate with no failed approaches either did not push hard enough or is not being candid.
- What would you do differently now? Tests whether you have reflected or merely finished.
- How would this scale to a hundred times the data or traffic? Where the round connects back to system design.
[!] Prepare one project properly rather than five superficially
Choose a project you can defend at every level: the business motivation, the data, the modelling choice and its alternatives, the evaluation, the deployment, and the outcome including what went wrong. Then rehearse it at three lengths — two minutes, ten minutes, and forty-five minutes with hostile questioning. Because the interviewer may not share your speciality, the two-minute version must land for a strong generalist engineer with no background in your subfield.
Prepare from: your own work, primarily. Chapters 16 and 14 help with the scaling and deployment follow-ups, and chapter 19 with "how did you know it worked".
24.12 General system design
Assesses: distributed systems reasoning, independent of machine learning. Weight: secondary to coding at Google, but heavier for infrastructure-leaning ML roles and for senior levels.
The reported guidance here is specific and slightly unusual: practise low-level design questions such as "design a load balancer" at least as much as the familiar high-level ones such as "design a messaging service". Candidates over-rehearse the high-level format and are caught out by a question about the internals of a single component.
[+] The same linchpin warning applies here
As in the ML design round, some questions contain a detail you must ask about or you cannot solve the problem — the third-party dependency whose service level agreement determines your whole availability story is the published example. Ask more than feels necessary, and state your assumptions explicitly when you do not get an answer: "I will assume this dependency is 99.9% available; if it is worse, the design needs a fallback path here."
Prepare from: chapters 16 (service boundaries and distribution costs), 11 (storage and consistency), 6 and 7 (serving, batching, scaling), 9 (API design), and 13 (deployment and rollout).
24.13 Behavioural and Googleyness
Assesses: collaboration and self-awareness. Weight: reported as the lightest round in the loop, and sometimes absent entirely.
Reports describe Google's behavioural round as the least demanding among comparable companies, occasionally skipped, and sometimes conducted by an interviewer with little enthusiasm for running it. That is not a reason to skip preparing, but it is a reason not to spend a third of your preparation time here.
[+] The reflective-question format, and how to handle it
Google is reported to favour reflective questions where other companies use situational ones. Instead of "tell me about a time you disagreed with a colleague", you may get "what do you think about setting goals?" — abstract, with no obvious structure to hang an answer on.
The technique that works is to convert it into a situational question and then answer that: "I will answer that through an example — here is a time I used goal-setting to manage a project that was drifting." You keep the concreteness and evidence of a STAR-style answer while directly addressing what was asked. Answering a reflective question purely in the abstract produces opinions with no evidence behind them, which is difficult for an interviewer to write up positively.
[≡] Questions reported in this round
Tell me about a colleague who was difficult to work with. Tell me about receiving negative feedback. Tell me about mentoring a junior engineer where your feedback was not getting through. How would you plan a team offsite? Prepare three or four genuine stories with concrete outcomes and reuse them across whichever variant appears — the stories matter more than matching each question to a bespoke answer.
Prepare from: chapter 13 (how teams work) for the collaboration vocabulary, and your own history for the material. A few hours is proportionate.
24.14 Hiring committee and levelling
A committee of four to five engineers and managers who did not interview you reviews a written packet and decides. They never meet you, which is the single most important fact about how to behave in the rounds themselves.
The packet contains your CV, your recruiter's notes, referral notes if any, and the full written feedback from every interviewer. The committee evaluates it holistically and needs consensus to hire. They also set your level, which is why levelling feels disconnected from the conversations you actually had.
[+] Three things this structure implies
Unsaid reasoning does not exist. Your interviewer writes down what you said, not what you were thinking. The habit of narrating trade-offs is not a stylistic preference — it is the only mechanism by which your reasoning reaches the decision-makers.
A uniformly middling packet loses. Five "Leaning Hire" ratings is reported to be a likely rejection, even alongside encouraging recruiter feedback. One genuinely excellent round is worth more than several adequate ones, which argues for pushing hard in a round that is going well rather than settling for a comfortable finish.
Your CV is read by senior engineers, not a keyword filter. If you are told you passed the onsite, ask whether you can submit an updated version — some recruiters allow the committee to see only the new one, and the version you applied with was probably written for a different audience entirely.
[!] On down-levelling
Reports of down-levelling have increased, and candidates frequently accept the lower offer. Decide your walk-away position before you receive an offer rather than while responding to one, because level determines scope, compensation, and how long promotion takes. It is also worth knowing that a passed onsite is reported to remain valid for roughly a year, so re-engaging later often skips the phone screen — which changes the calculus of declining.
24.15 Team matching
Passing the committee means Google will hire you; it does not yet mean a team has. Team matching is a separate stage, and it is the one candidates are least prepared for because it is not adversarial and therefore does not feel like an interview.
Your recruiter proposes teams with openings matching your profile, and you have conversations with hiring managers. It is closer to mutual selection than assessment, but it is not a formality — candidates do occasionally clear the committee and fail to find a team, and the wait can be long.
[→] What to actually ask a prospective manager
- Where does this team sit on the two axes? Infrastructure or modelling, research or application (24.4). This determines your day-to-day work more than the job title does.
- What does the team's roadmap look like for the next year? A team whose charter is uncertain is a real risk regardless of how interesting the work sounds.
- How is impact measured here? If the answer is a launch metric, you are on an application team; if it is publications, a research one. Both are fine; mismatched expectations are not.
- What would I own in the first six months? Scope in the answer maps directly to whether your level is right.
- How much of the work is modelling versus infrastructure? Ask for a rough percentage. The answer is often surprising, in both directions.
[+] If a decentralised process is in use
Where a hiring manager selects you for a specific team before you interview, team matching disappears — which means the questions above must be asked before the loop rather than after it, and the team you are matched to is fixed rather than chosen. Establish which process you are in during the recruiter screen (24.5), because it changes when you get to evaluate the team.
24.16 The round-to-chapter map
Every round in the loop, mapped to what to revise in this course and what to add from elsewhere. This is the practical core of the chapter.
| Round | Revise first | Also useful | Not in this course |
|---|---|---|---|
| Technical phone screen | Ch 20 entirely, especially 22.2 and 22.18–22.21 | Ch 21 if data-science adjacent | Volume practice on unfamiliar problems — the patterns need repetitions against questions you have not seen. |
| Onsite coding | Ch 20, weighting 22.20 (disguised questions) heavily | Ch 21 for probability-flavoured variants | Mock interviews with a partner who plants red herrings and withdraws assumptions. |
| ML system design | Ch 17 (metrics, calibration, drift), Ch 5 (retrieval), Ch 18 (launch and rollback) | Ch 6 and 7 (serving, latency, scaling), Ch 11 (data layer), Ch 15 (service boundaries), Ch 4 (vector indexes) | Recommender and ranking system specifics: candidate generation, two-tower retrieval, feature stores, training/serving skew at scale. |
| ML breadth and depth | Ch 17 (foundations), Ch 2 (transformers and attention) | Ch 3 (embeddings), Ch 5 (retrieval evaluation), Ch 19 (why the losses look like that) | Classical ML depth: trees and boosting internals, SVM duality, unsupervised methods beyond clustering. |
| Statistics and experiments | Ch 18 (A/B testing) and Ch 16 (statistics) | Ch 19 (distributions), Ch 21 (simulation) | Causal inference beyond randomised experiments: instrumental variables, difference-in-differences. |
| Research or project deep dive | Your own work | Ch 18 (how you knew it worked), Ch 13 and 15 (how it would scale) | Presentation practice with a hostile audience. Nothing substitutes for rehearsal. |
| General system design | Ch 15 (distribution costs), Ch 11 (storage and consistency) | Ch 6, 7, 9, 13, 14 | Low-level component design: load balancers, rate limiters, connection pools, consistent hashing internals. |
| Behavioural | Ch 12 (how teams work) | — | Three or four rehearsed stories from your own history. |
24.17 A twelve-week plan from scratch
This assumes you are starting cold and can give it roughly ten hours a week. Compress it if you have less time by cutting breadth rather than the coding foundation, since coding carries the most weight and is the slowest skill to build.
[→] Weeks 1–4: the coding foundation
- Week 1. Chapter 22 sections 22.1–20.8. Linear patterns: two pointers, sliding window, hash maps, intervals. Solve five unfamiliar problems per pattern, in a plain document.
- Week 2. Sections 22.9–20.14. Binary search on the answer, heaps, BFS, DFS, topological sort. Same drill.
- Week 3. Sections 22.15–20.17. Dynamic programming, which needs the most repetitions — derive each solution from the recursion rather than recalling the table.
- Week 4. Sections 22.18–22.21 and chapter 23. Communication, disguised questions, and the probability-flavoured coding questions. Start mock interviews now, not later.
[→] Weeks 5–8: the ML core
- Week 5. Chapter 18 in full, plus chapter 20 sections on the distributions you use most. This is the foundation the depth round drills into.
- Week 6. Chapters 17 and 19. Experiment design, sample size, peeking, sample ratio mismatch. Be able to compute a sample size unaided.
- Week 7. Chapters 2, 3, 4 and 5. Transformers, embeddings, vector indexes, retrieval — the substrate of most current ML system design questions.
- Week 8. Chapters 6, 7, 12 and 15. Serving, scaling, data layer, service boundaries. Practise the five-area ML design structure from 24.8 on three different problems out loud.
[→] Weeks 9–12: integration and rehearsal
- Week 9. Your project deep dive. Write it out, then rehearse at two, ten and forty-five minutes. Have someone unfamiliar with your subfield listen to the two-minute version.
- Week 10. Fill the external gaps from 24.16 that apply to your target role — usually ranking systems for applied roles, or low-level design for infrastructure roles.
- Week 11. Full mock loops: coding, ML design, and depth in a single sitting, to build the stamina for four to six consecutive rounds. Chapter 13 and behavioural stories this week.
- Week 12. Weak spots only, identified from the mocks. Reduce volume toward the end of the week.
[!] The most common preparation mistake
Over-indexing on ML content because it is the interesting part, and under-indexing on coding because it feels like a solved problem from a previous career stage. Coding is reportedly the most heavily weighted round type in this loop, and it is the one where an ML specialist is most likely to be caught out. If you must cut something, cut breadth in ML, not the algorithm work.
24.18 Gaps this course does not cover
An honest inventory. These come up in applied scientist and MLE loops and are either absent from this course or covered too lightly to rely on. Knowing what you are missing is more useful than a reading list that pretends otherwise.
| Gap | Why it matters | Priority |
|---|---|---|
| Recommender and ranking systems — candidate generation then ranking, two-tower retrieval, feature stores, training/serving skew | An enormous share of applied ML roles at large consumer companies are ranking roles, and ML design questions default to this shape. | High for applied roles |
| Classical ML internals — gradient boosting mechanics, tree splitting criteria, SVM duality, PCA derivation | The depth round goes wherever your CV points, and most production ML is still not deep learning. | High |
| Low-level system design — load balancers, rate limiters, consistent hashing, connection pooling | Reported to be under-practised relative to high-level design, and specifically worth drilling. | Medium to high |
| Causal inference beyond randomised experiments — instrumental variables, difference-in-differences, propensity scores | Chapter 19 covers experiments you can run; these are the tools for when you cannot randomise. | Medium for applied scientist |
| Deep learning training practice — optimiser behaviour, learning rate schedules, initialisation, distributed training strategies | Depth questions on "how would you actually train this" bottom out here. | Medium |
| Your subfield's recent literature | Specialist loops expect familiarity with current benchmarks and datasets, not just methods. | High if specialist |
| Volume practice against unseen problems | Chapter 22 teaches the patterns; only repetition against unfamiliar questions builds the recognition reflex under time pressure. | High, always |
[+] How to prioritise these against your own background
Work backwards from your CV. The depth round follows whatever you claim, so the gaps that matter most are the ones adjacent to your stated experience — if your CV says "ranking", the recommender gap is urgent; if it says "NLP research", the literature gap is. A gap far from anything on your CV is unlikely to be probed deeply and is a poor use of limited preparation time.
24.19 The week before
[→] What is worth doing, and what is not
- Confirm the loop composition with your recruiter. How many rounds, of what type, and whether there is a behavioural. This is a normal question and the answer redirects your final week.
- Practise in the actual medium. If it is a plain document, write code in one. Set up your environment and test the video call software in advance.
- Rehearse the openings, not the endings. The first ninety seconds of a coding round (22.2) and the first five minutes of a design round (24.8) are the highest-leverage minutes in the loop, and they are the parts you can genuinely make automatic.
- Re-read your own project description. You will be asked what did not work and what you would change — have real answers rather than improvising under pressure.
- Do one full-length mock, then stop. Cramming new material in the final days displaces sleep and rarely converts into recall under pressure.
- Prepare your questions for the interviewers. Not for scoring, but because you are also deciding whether to work there.
[!] On AI assistance
Using AI tools during a Google interview is reported to be strictly prohibited. Some other companies have begun running explicitly AI-assisted rounds; do not carry that assumption across. If you are unsure what is permitted in a specific round, ask the recruiter beforehand rather than the interviewer during.
[+] A realistic expectation
Strong engineers fail these loops regularly, and the process itself is reported to be noisy — interviewer quality varies, questions vary, and a packet of uniformly reasonable scores can still be rejected. Preparation raises your probability substantially; it does not make the outcome deterministic. Treating a rejection as information about a single noisy sample rather than a verdict on your ability is both more accurate and more useful, particularly given that a passed onsite stays valid for around a year and reapplication is possible.
24.20 Key takeaways
- Treat process details as informed expectations, not facts. Company processes change without notice and vary by office and team; the structural advice outlasts the specifics.
- The process is centralised, so you generally do not interview with your future team, cannot interview with several teams at once, and face team matching as a separate later stage.
- Coding carries the most weight — reportedly the one large tech company where coding outranks system design. It is where ML specialists most often underprepare.
- Process beats result. Reaching the optimal answer without communicating the reasoning is repeatedly described as insufficient; narrated partial progress often is not.
- Uniformly middling scores lose. Five "Leaning Hire" ratings is a likely rejection, while one Strong Hire carries real weight — so push hard in a round that is going well.
- The decision is made from written feedback by people who never met you. Anything you did not say out loud does not exist in the packet.
- Establish which role you are interviewing for: infrastructure or modelling, research or application. It changes the loop composition substantially, and recruiters will tell you.
- Practise coding in a plain document. No highlighting, no autocomplete, no execution — and prepare for the harder case, since tooling varies by location.
- A second phone screen means insufficient signal, not failure, and it is worth pressing for specific feedback before it.
- Expect disguised questions and withdrawn assumptions. Verify a pattern's preconditions before applying it, and expect follow-ups that remove a constraint after you succeed.
- ML system design is scored across five areas: problem framing, data collection, features, modelling, and evaluation plus deployment. Cover all five regardless of your speciality.
- Generalists and specialists are graded differently on the same question — breadth and "can get v1 running" versus depth and "can build the best version in the company".
- Ask about linchpin details past the point of comfort. Some design questions are unsolvable unless you ask about one specific constraint, and asking is scored positively.
- The depth round is designed to find the edge of your knowledge, so reaching it is expected. Say so plainly and reason forward; confabulating is the actual failure.
- Statistics rounds check whether you can tell a result from noise. Quantify: name the test, state the assumption, give a number.
- Prepare one project exhaustively rather than five superficially, at two, ten and forty-five minutes — and make the short version land for a non-specialist.
- Practise low-level design, not just high-level. "Design a load balancer" is under-rehearsed relative to "design a messaging service".
- Behavioural is the lightest round and sometimes absent. Convert reflective questions into situational ones and answer with a concrete story.
- Ask for an updated CV to reach the hiring committee if you pass the onsite — the version you applied with was written for a keyword filter, not for senior engineers setting your level.
- Decide your walk-away level before an offer arrives, since down-levelling is common and a passed onsite reportedly stays valid for about a year.
- The process is noisy. Preparation raises your probability substantially without making the outcome deterministic; a rejection is one noisy sample, not a verdict.
[i] Vocabulary check
You should be able to explain: centralised versus decentralised hiring, technical phone screen, onsite loop composition, the seven-point rating scale, hiring committee, levelling and down-levelling, team matching, linchpin questions, disguised questions, process-oriented versus results-oriented assessment, ML generalist versus specialist, the five ML design assessment areas, reflective versus situational behavioural questions, and what a Strong Hire is worth.
24.21 Interview drills
These are the meta-questions: not "solve this problem" but "how would you approach this round". Answer out loud before expanding.
1. You have six weeks, a strong ML background, but have not done algorithm work in years. How do you allocate the time?
Roughly two thirds on coding, which is the opposite of what instinct suggests. Coding is reportedly the heaviest-weighted round type in this loop, it is the slowest skill to rebuild, and it is exactly where a strong ML candidate is most likely to be caught out. My ML knowledge is already largely in place and needs organising rather than building.
Concretely: weeks one to four on the eleven patterns, solving unfamiliar problems in a plain document rather than an IDE, with mock interviews starting in week two rather than at the end. Weeks five and six on ML system design structure, statistics for experiments, and rehearsing one project deeply. If I ran short I would cut ML breadth, not the algorithm work.
2. What is the single most important thing to do differently in a Google coding round versus another company?
Narrate continuously, because the process is weighted above the result and the decision is made from written feedback by people who never met me. My reasoning only reaches the hiring committee if my interviewer heard it and wrote it down.
Practically that means stating the brute force and its complexity before optimising, justifying each data structure by the trade-off it buys, proving the complexity rather than asserting it, and summarising at the end. A silent candidate who writes correct code can score worse than one who reasons aloud and does not finish, which is genuinely counter-intuitive coming from companies that grade on output.
3. Your ML system design round starts with "design a system to detect fraudulent transactions." What are your first four minutes?
Questions, not architecture. What is the business cost asymmetry between a missed fraud and a blocked legitimate transaction — that ratio determines the entire threshold strategy. What volume and what latency budget? Is this a synchronous block at payment time or an asynchronous review queue? What labelled data exists, and how delayed are the labels, since chargebacks can take weeks?
I would ask deliberately more than feels natural, because these rounds are reported to contain linchpin details that make the problem unsolvable if unasked — here the label delay is the likely candidate, since it dictates how I can train and evaluate at all. Then I would state the five areas I intend to cover — data, features, modelling, evaluation and deployment — so the interviewer knows the shape of my answer up front.
4. In the depth round you are asked something you genuinely do not know. What do you say?
I say I do not know it directly, and then reason forward from what I do know: "I have not worked with that method. From how the related approach behaves, I would expect it to trade X for Y, because of Z — is that the right intuition?"
The round is explicitly designed to find the edge of my knowledge, so reaching that edge is the expected outcome rather than failure. What is being assessed at that point is whether I know what I do not know and can still reason productively. Confabulating a confident wrong answer is the real failure mode, and an experienced interviewer identifies it immediately — it also poisons everything I said earlier, because it makes my confident claims unreliable too.
5. Why might a candidate with five "Leaning Hire" scores be rejected, and what should they have done?
Because the committee looks for clear positive signal, and uniformly middling feedback provides none — it says nobody objected, not that anyone was convinced. This is reported directly by a Google interviewer, including cases with encouraging recruiter feedback that still ended in rejection.
The correction is counter-intuitive: when a round is going well, do not coast to a comfortable finish. Take the follow-up, discuss the extension, go deeper than required — because one Strong Hire is worth more than several adequate rounds and can even earn an extra round to resolve a borderline packet. Optimising for never doing badly produces exactly the flat profile that loses.
6. How does your preparation change if the role is ML infrastructure rather than modelling?
It moves substantially toward general software engineering and distributed systems. Infrastructure teams build training platforms, serving frameworks and pipelines, so the loop looks much more like a standard SWE loop, and deep modelling knowledge is de-emphasised unless the role is explicitly hybrid.
So I would weight general system design heavily — including low-level component questions like designing a rate limiter or a load balancer, which are reportedly under-practised — along with serving, scaling, storage and deployment. I would still expect to explain why a model needs what it needs, but I would not spend my time on frontier modelling literature. This is exactly why I would ask the recruiter which side of that axis the team sits on.
7. What do you ask a hiring manager during team matching?
Where the team sits on infrastructure versus modelling and research versus application, because that determines the day-to-day work far more than the title. What the roadmap looks like for the next year, since an uncertain charter is a real risk. How impact is measured — a launch metric implies an application team, a publication implies a research one.
Then two questions about fit specifically: what I would own in the first six months, because the scope in that answer tells me whether my level is right; and roughly what percentage of the work is modelling versus infrastructure, where the honest answer is often surprising. Team matching is mutual selection rather than assessment, so not asking these is a wasted opportunity rather than a safe choice.
8. You are asked "what do you think about setting goals?" How do you answer?
This is a reflective question rather than a situational one, and Google is reported to use them more than most. The trap is to answer purely in the abstract, which produces opinions with no evidence and is hard for the interviewer to write up positively.
So I convert it into a situational question and say that I am doing so: "I will answer that with an example — here is a project that was drifting and how I used explicit goals to get it back on track, and what I would do differently now." That keeps the concreteness and evidence of a STAR-style answer while directly addressing what was actually asked.
9. Which chapters of this course map to the ML system design round?
Primarily chapter 18 for metrics, calibration and model decay, chapter 5 for retrieval, and chapter 19 for launch experiments and rollback — those three cover the framing, evaluation and deployment areas, which is where most of the scoring sits.
Supporting: chapters 6 and 7 for serving latency and scaling, chapter 12 for the data layer and feature storage, chapter 16 for service boundaries and what distribution costs, and chapter 4 for vector indexes if the problem involves retrieval. The main gap I would fill externally is recommender and ranking specifics — candidate generation, two-tower retrieval and feature stores — because ML design questions at consumer-scale companies default to that shape.
10. Your interviewer seems disengaged and is barely responding. What do you do?
Keep narrating and do not read it as a verdict. Interviewer quality is reported to vary considerably, partly because interviewing is not most engineers' primary job, and a flat affect carries no information about how the round is being scored.
Practically, I would keep stating my reasoning out loud, since the written feedback is what reaches the committee and it can only contain what I said. I would also create explicit checkpoints — "before I code this, does the approach look reasonable to you?" — which invites engagement without demanding it, and protects me from spending twenty minutes on a direction the interviewer already knew was wrong.
11. What is the most common preparation mistake for someone with a strong ML background?
Over-investing in ML content because it is interesting and familiar, and under-investing in algorithms because it feels like a solved problem from an earlier career stage. That allocation is backwards for this loop specifically, where coding is reportedly the heaviest-weighted round type.
The second version of the same mistake is practising algorithms by re-solving problems already seen. Leaked questions are actively retired, so the questions circulating publicly are close to a list of what will not be asked. Practice has to be against unfamiliar problems, with the goal of recognising the pattern rather than recalling the solution — ideally with a partner who plants red herrings and withdraws assumptions afterwards.
12. You get the offer but at a level below what you expected. How do you think about it?
First, I decide this before the offer arrives rather than while responding to it, because the decision is much worse made under time pressure and social momentum. Down-levelling is reported to be common and frequently accepted, so it is a foreseeable outcome rather than a surprise.
Level determines scope, compensation and how long promotion takes, so I would weigh it against the specific team and work rather than treating the title as the whole question. Two facts change the calculus: level is set by the hiring committee from the written packet, so it is worth having asked whether an updated CV could reach them; and a passed onsite reportedly stays valid for about a year, which means declining is not necessarily starting over.
Where this leaves you
Twenty-two chapters: the systems, the mathematics behind them, the methods for knowing whether any of it worked, and finally the process by which someone decides to hire you to do it. This chapter is the least durable of the set, and deliberately so — processes change, while the twenty-one chapters before it do not.
The through-line, if there is one, is that everything here was built the same way: derive the thing rather than memorise it, verify it rather than assume it, and be able to say out loud why it is true. That happens to be exactly what the interviews described in this chapter are trying to measure, which is not a coincidence.
Chapter 10 returns to building. Chapter 8 argued that an agent's loop is trivial and its harness is everything; the final chapter constructs that harness concretely in Google ADK — grounded loops that can prove a claim, four control-flow shapes composed into one pipeline, and a multi-agent flow run over every row of a batch.