Google ML engineer interview questions and process

The model was beautiful. Gradient-boosted, well tuned, 0.94 AUC on a held-out set, and the candidate walked through it with real pride. The interviewer asked one question: "Where does the label come from at serving time?" It came from a column that was populated three days after the event. The model had been reading the future for the entire notebook, and nobody had noticed, because notebooks do not tell you things like that.

That is the shape of Google ML engineer interview questions. Google hires ML engineers to build systems that keep working after the notebook closes, so the loop is roughly two-thirds software engineering and one-third machine learning — and the ML third is much more interested in leakage, drift and serving than in whether you can name a loss function. I built Greenroom after freezing in an interview I had prepared hard for, so this guide covers what Google asks an ML engineer and how to say it out loud.

The Google ML engineer interview process in 2026

• Recruiter screen — level calibration and, importantly, whether the role is research-adjacent or production ML. The loops differ.
• Coding phone screen — around 45 minutes of algorithmic coding, at the same bar as the generalist software engineering loop.
• Onsite (virtual) — usually one or two more coding rounds, an ML fundamentals round, an ML system design round, and a Googleyness and leadership round.
• Hiring committee — written feedback reviewed by people who never met you.
• Team matching — separate from the hiring decision and often the slowest stage.

The most common failure is preparing only for the ML rounds. Our Google interview preparation guide covers the company-wide loop and the machine learning engineer interview questions guide covers the role-general question bank.

The coding rounds are still algorithm rounds

Google does not lower the algorithm bar for ML candidates. Graphs, dynamic programming, binary search, heaps, intervals and strings all show up, frequently in a shared document with no execution.

There is one useful pattern: ML loops often pick problems with a data flavour — sampling, deduplication, top-K, streaming aggregation, sliding-window statistics. Practise those specifically, and state complexity unprompted.

# reservoir sampling: uniform sample of k items from a stream of unknown length
import random

def reservoir(stream, k):
    out = []
    for i, item in enumerate(stream):
        if i < k:
            out.append(item)                 # fill the reservoir first
        else:
            j = random.randint(0, i)         # keep item with probability k/(i+1)
            if j < k:
                out[j] = item
    return out

Then say the proof sketch in one sentence — "each item survives with probability k over n by induction on i" — because at Google the analysis is graded as heavily as the code. Our DSA coding interview preparation guide covers the broader list.

ML fundamentals: derivations, not definitions

The fundamentals round is a conversation, and the follow-ups go one level below the textbook answer.

• Bias and variance — not the definition, but what you would actually change when the training error is already low and validation error is not.
• Regularisation — why L1 produces sparsity in a way L2 does not, and what dropout is doing at inference time.
• Metrics — why accuracy is the wrong metric for a 0.1% positive class, when precision-recall beats ROC-AUC, and how to choose a threshold when the two error types cost different amounts. This is the highest-yield topic in the round.
• Leakage — the question from the opening scene. Target leakage, temporal leakage, and leakage through a preprocessing step fitted before the split.
• Validation — why a random split is wrong for time series and for grouped data, and what you use instead.
• Trees versus neural networks — when gradient boosting is the correct production answer, which is more often than candidates want to admit.
• Calibration — a model that ranks well can still output probabilities that mean nothing, and downstream systems usually need the probability.

Our deep learning interview questions guide covers the neural-network half and data scientist interview questions covers the statistics half.

ML system design: the round that decides it

The prompt is a product: design YouTube recommendations, design a ranking system for search suggestions, design spam or fraud detection, design a system that predicts delivery time. Model architecture is maybe fifteen percent of a strong answer.

• Frame the problem. What is being predicted, what the label is, where the label comes from, and how long you wait to observe it. Delayed labels change everything downstream.
• Data and features. Sources, freshness, and the feature store question: how do you guarantee the feature computed at training time equals the feature computed at serving time? Say training-serving skew and describe the mechanism preventing it.
• Baselines. Start with a heuristic or logistic regression baseline and say why. Google interviewers reward this heavily; jumping to a transformer reads as inexperience.
• Two-stage architecture. For anything recommendation-shaped: cheap candidate generation over millions of items, then an expensive ranker over hundreds. Say the latency budget for each.
• Training cadence and freshness. Retraining schedule, online versus batch, and what breaks when the world moves faster than the retrain.
• Evaluation. Offline metric, online metric, and the gap between them. Then A/B testing: what you randomise, what you measure, how long you run it, and what a network effect does to your assumptions.
• Monitoring. Data drift, prediction drift, feature nulls appearing upstream, and the alert that fires before the metric moves.
• Failure mode. What the product does when the model is unavailable or is returning garbage. A fallback ranker is a strong answer.

The Google ML engineer prep page has a round-by-round checklist, and our system design interview guide covers the shared vocabulary.

MLOps and production reality

Increasingly the loop includes pipeline questions, because most ML work is data plumbing:

• Batch versus streaming features and the consistency guarantees each gives you.
• Versioning of data, features and models — and how you reproduce a prediction from six months ago during an incident.
• Shadow deployment and canary rollout for models specifically, where a bad release does not throw an error, it just quietly gets worse.
• Cost: GPU hours for training, and per-request inference cost at production QPS.

Our data engineer interview questions guide covers the pipeline vocabulary and llm production engineer interview questions covers the generative-AI variant of the same round.

LeetCode, Chip Huyen, ChatGPT — where each fits

• LeetCode — necessary, at medium climbing to hard, with a bias towards data-flavoured problems.
• Designing Machine Learning Systems by Chip Huyen — the closest published thing to Google's ML design round, especially on training-serving skew and monitoring.
• The Google research blog and the Rules of Machine Learning document — Google's own published ML engineering guidance is unusually explicit about baselines and about not starting complicated.
• Kaggle — good for modelling reflexes, actively misleading for production judgment. Say "baseline first" more often than Kaggle taught you to.
• ChatGPT — useful for generating design prompts and critiquing a written architecture. It will not ask where the label comes from at the moment your notebook is reading the future.
• Greenroom — the spoken layer. Ari, the AI interviewer runs the ML design round out loud, asks the follow-up about leakage and drift, and scores structure and clarity. Honest tradeoff: Ari will not review your training code, so pair it with real projects.

How to prepare for the Google ML engineer interview

• Week 1-2 — LeetCode mediums with a data flavour, complexity stated aloud, in a plain editor without autocomplete.
• Week 3 — ML fundamentals as ninety-second spoken answers: metrics under class imbalance, threshold selection, every kind of leakage, validation for time series, calibration.
• Week 4 — design recommendations, fraud detection and delivery-time prediction out loud. Label first, features second, baseline third, model fourth, monitoring last.
• Final week — five behavioral stories with numbers, two full spoken mocks, and the role-specific prep page the night before. Nothing new in the last 48 hours.

Interviewing across comparable loops? The Amazon ML engineer guide covers the leadership-principle overlay, the Meta ML engineer guide covers ranking at feed scale, and the Google data engineer guide covers the pipeline-heavy sibling role.

Frequently asked questions

What is the Google ML engineer interview process?

Candidates report a recruiter screen, a coding phone screen of about 45 minutes at the same algorithmic bar as the generalist loop, and a virtual onsite of one or two further coding rounds, an ML fundamentals round, an ML system design round and a Googleyness and leadership round. A hiring committee then reviews written feedback, followed by team matching, which is usually the slowest stage.

Does Google ask ML engineers LeetCode questions?

Yes. The algorithm bar is not lowered for ML candidates, and graphs, dynamic programming, binary search, heaps and string problems all appear, often in a shared document with no execution. ML loops do tend to favour data-flavoured problems such as reservoir sampling, deduplication, top-K and streaming aggregation, so practise those specifically and state complexity without being asked.

What ML system design questions does Google ask?

Product-shaped prompts dominate: design YouTube recommendations, a ranking system for search suggestions, spam or fraud detection, or delivery-time prediction. A strong answer spends most of its time on what is being predicted and where the label comes from, feature freshness and training-serving skew, a simple baseline before anything complex, two-stage candidate generation and ranking with latency budgets, offline versus online evaluation and A/B design, drift monitoring, and what the product does when the model fails.

What is training-serving skew and why does Google ask about it?

Training-serving skew is when the feature value computed during training differs from the value computed at serving time — because of different code paths, different data freshness, or a preprocessing step fitted on the full dataset before splitting. It is asked because it is the most common reason a model that validated well performs badly in production, and the expected answer is a mechanism such as a shared feature definition or a feature store, not just an awareness that the problem exists.

What ML fundamentals questions come up in a Google interview?

Expect derivation-level follow-ups rather than definitions: what you would change when training error is low but validation error is not, why L1 produces sparsity where L2 does not, why accuracy is wrong for a rare positive class and when precision-recall beats ROC-AUC, how to pick a threshold when the two error types have different costs, every form of leakage including temporal and preprocessing leakage, why random splits are wrong for time series and grouped data, and why a well-ranking model can still be badly calibrated.

Is the Google ML engineer interview harder than the software engineer interview?

It is broader rather than strictly harder. You face essentially the same coding bar as a software engineering candidate plus two additional ML rounds, so the common failure mode is a strong modeller who under-prepared the algorithms, or a strong engineer who can build pipelines but cannot discuss metrics, leakage and evaluation design with any depth.