What you need to know
Prepare for Machine Learning Engineer interviews with ten explained questions on leakage, preprocessing, classification metrics, calibration, error analysis and reproducible model comparisons.
Prepare for Machine Learning Engineer interviews with ten explained questions on leakage, preprocessing, classification metrics, calibration, error analysis and reproducible model comparisons.
These are original practice questions, not questions reported from a particular employer. Every scenario below is hypothetical. Use the answers to understand the reasoning, then explain the decision in your own words and connect it to work you actually did.
How to practise
First answer aloud without reading. State the goal, assumptions, proposed approach, checks and trade-offs. Then compare your reasoning with the answer, tackle the follow-up and write down one gap to practise. Aim for a clear two-minute initial explanation; expand when asked. This timing is a practice suggestion, not an interview rule.
Role-based questions and detailed answers
1. Why must you define the prediction instant before selecting features?
Answer: A feature is usable only if its value would be available when the prediction is made. Define that instant and inspect how each field is produced and updated. Exclude future outcomes and retrospectively corrected information unavailable then. Reconstruct historical feature availability where possible; strong offline scores can otherwise reflect information the deployed system never receives.
Hypothetical scenario: A churn model uses an account-closure reason populated after the customer has already left.
Follow-up: How would you audit a field whose update timestamp is missing?
Common mistake: Checking correlation without checking when the information becomes available.
2. When is a random train-test split misleading?
Answer: Random splitting can leak shared entities, repeated records or future conditions across partitions. Choose a split that approximates deployment: hold out entities for unseen-customer use, or later periods for future prediction. Keep the final test set separate from model selection. Document the intended generalization claim because no split answers every deployment question.
Hypothetical scenario: Photographs of the same manufactured item appear in both training and test partitions.
Follow-up: Would an entity split or time split better match this product?
Common mistake: Assuming random splitting always guarantees independent evaluation.
3. Where should imputation and normalization be fitted?
Answer: Fit learned preprocessing parameters on the training partition only, then apply those saved parameters to validation, test and production inputs. During cross-validation, fit them separately inside each training fold. This prevents evaluation data from influencing the learned transformation. Package the transformer with the model so deployment does not recompute incompatible means or category mappings.
Hypothetical scenario: A team computes missing-value medians using the complete dataset before creating evaluation folds.
Follow-up: Which preprocessing operations learn information from the data?
Common mistake: Believing only the model estimator can cause data leakage.
4. How do you evaluate an imbalanced classifier?
Answer: Begin with the decision costs and confusion counts rather than accuracy alone. Precision measures how many predicted positives are correct; recall measures how many actual positives are found. Compare thresholds using validation data and report the workload they create. Include sample sizes and slice behaviour because an attractive aggregate score may conceal costly missed cases.
Hypothetical scenario: Only a small fraction of transactions are fraudulent, and investigators can review a limited daily queue.
Follow-up: How does reviewer capacity affect the operating threshold?
Common mistake: Selecting the highest accuracy model when predicting every case negative already scores highly.
5. How are ranking quality and probability calibration different?
Answer: Ranking asks whether higher-risk examples tend to score above lower-risk ones. Calibration asks whether predicted probabilities agree with observed frequencies. A model may rank well yet systematically overstate risk. Evaluate both if probabilities drive financial or operational decisions, and fit any calibration step on separate validation information without consuming the final test set for tuning.
Hypothetical scenario: Cases scored near 0.8 are positive only about half the time, despite useful ordering.
Follow-up: Could changing a threshold fix probability calibration itself?
Common mistake: Treating a good ranking metric as evidence that probabilities are reliable.
6. Can validation performance legitimately exceed training performance?
Answer: Yes. Training may include augmentation, dropout, harder examples or a different loss calculation, while validation uses inference settings. It can also indicate sampling differences or leakage. First compare metric definitions and evaluation modes, then inspect distributions and preprocessing. The direction of the gap alone is not a diagnosis and does not justify changing the model blindly.
Hypothetical scenario: Training accuracy is measured with strong augmentation, but validation uses clean, unmodified examples.
Follow-up: How would you compare both partitions under the same inference settings?
Common mistake: Declaring leakage solely because validation has a better score.
7. What should an error-analysis report contain?
Answer: Group mistakes by decision-relevant slices, error type and potential cause. Inspect labels and source examples before treating every disagreement as model failure. Report the denominator for each slice and distinguish systematic patterns from a handful of cases. Recommend a testable intervention, such as correcting labels or collecting a missing condition, rather than merely listing bad predictions.
Hypothetical scenario: Overall recall looks acceptable, but low-light examples have few positives and many missed detections.
Follow-up: What additional evidence would make that slice-level conclusion trustworthy?
Common mistake: Reporting a percentage for a tiny slice without its sample count.
8. Does a highly important feature explain what causes an outcome?
Answer: Feature importance describes behaviour of a particular fitted model under a particular method and dataset. It does not establish a causal effect. Correlated features, leakage and measurement choices can change the result. Explain the importance calculation, test stability and avoid recommending an intervention solely because a feature has a high predictive contribution.
Hypothetical scenario: A hiring model assigns importance to a field strongly associated with a historical recruiting channel.
Follow-up: What evidence would be needed before changing that channel as an intervention?
Common mistake: Turning predictive association directly into a causal business recommendation.
9. How do you diagnose training-serving skew?
Answer: Compare the same raw examples through training and serving transformations, including category mappings, missing values, time zones and feature versions. Check that model and preprocessing artifacts are released together. Log safe feature summaries and contract failures. A model can be unchanged while its effective input meaning changes, so investigate upstream data changes as well as prediction code.
Hypothetical scenario: Training encodes an unknown category as a separate token, while production silently maps it to zero.
Follow-up: What contract test would catch the mismatch before deployment?
Common mistake: Retraining before checking whether serving inputs match the training contract.
10. What makes a model comparison reproducible and fair?
Answer: Use the same evaluation examples, metric definitions and comparable tuning budgets. Record dataset snapshots, code, seeds, dependencies and resource settings, while acknowledging some operations remain nondeterministic. Repeat important comparisons where variance matters. Choose on meaningful error and operational constraints, not a tiny score difference selected after repeatedly checking the final test set.
Hypothetical scenario: Candidate A received extensive tuning while candidate B was evaluated once with default settings.
Follow-up: How would you report uncertainty around a small apparent improvement?
Common mistake: Calling a comparison fair because both candidates share the same test file.
Turn practice into evidence
Create a small tabular classifier with a clearly defined prediction time. Implement a training-only preprocessing pipeline and a grouped or chronological split where justified. Write an error report by slice, compare two decision thresholds and demonstrate that the saved preprocessing artifact produces identical transformations at inference.
Score each response informally: 0 if you cannot explain it, 1 for a definition, 2 for an approach with checks, and 3 for justified trade-offs plus a failure-recovery plan. This is a self-study rubric, not a validated hiring assessment. Revisit weak answers and never invent project outcomes or experience.
Career roadmap and related jobs
Build the underlying skills with the Machine Learning Engineer career guide. For a shorter starting point, read AI interview answer frameworks.
Explore relevant live jobs. Listings are filtered by Machine Learning and can include adjacent roles. Read the employer's requirements and original posting before applying. Use one listing to select the questions most relevant to its responsibilities.
Methodology
Editorial synthesis of cited sourcesAI-assisted original educational practice material. These are not actual employer interview questions, reported interview experiences or hiring guarantees. Answers, hypothetical scenarios, follow-ups and self-assessment advice are original editorial synthesis. Official Google references support background concepts, not endorsements of these answers. Related jobs use a specialization filter and may include adjacent roles; availability changes. References checked 17 October 2026.
Read our editorial and research policy →Sources
- Dividing datasets
Google for Developers · Checked 17 October 2026
- Classification: accuracy, recall, precision and related metrics
Google for Developers · Checked 17 October 2026
- MLOps: continuous delivery and automation pipelines
Google Cloud · Checked 17 October 2026