Meta Machine Learning Engineer Interview: What Actually Gets Tested
- Dual bar: The Meta MLE loop applies the full SWE coding bar plus a separate ML system design and applied ML bar, with neither softening the other.
- Two problems per coding round: Each 45-minute session has two problems; silence and a slow start both generate negative signals on Meta's rubric.
- Two-stage ML architecture: Meta's scale demands a fast retrieval model (ANN) followed by a heavier ranker; knowing when and why to use each stage is nearly a prerequisite.
- Problem framing first: In ML system design, establishing the objective and proxy metric before touching architecture separates engineering judgment from pattern-matching.
- Behavioral round sets your level: E4 vs E5 vs E6 is decided in the Jedi round and system design, not coding; thin behavioral evidence means a downlevel, not a rejection.
- Eight-week prep sequence: DSA first (weeks 8-6), ML system design (weeks 6-4), applied ML depth (weeks 4-2), mock interviews and behavioral stories in the final two weeks.
You have to pass a full SWE coding loop. And a machine learning system design interview. And a theory depth round where they ask what happens when your model breaks in production. And a behavioral round that Meta, completely seriously, named after Star Wars characters.
All of these happen. All of them count. Neither bar softens the other.
Most people prepping for this role think it's a regular SWE loop with some ML questions bolted on at the end. That mental model will get you downleveled or rejected. The coding bar is identical to a standard software engineer hire. On top of that you need to convince an experienced ML engineer you can build systems that run at Instagram Reels scale.
The Full Loop: More Rounds Than You Were Hoping For
| Round | Format | Duration | What It Tests |
|---|---|---|---|
| Recruiter screen | Phone | 30 min | Background, leveling fit |
| Technical phone screen | Video (CoderPad) | 45 min | 2 coding problems + brief behavioral |
| Coding round 1 | Video (CoderPad) | 45 min | 2 DSA problems |
| Coding round 2 | Video (CoderPad) | 45 min | 2 DSA problems |
| ML system design | Video (whiteboard) | 60 min | End-to-end ML pipeline design |
| Applied ML depth | Video | 45-60 min | Theory, modeling decisions, debugging |
| Behavioral (Jedi round) | Video | 45 min | Leadership, cross-functional work |
The phone screen is two problems immediately, one medium and one hard, roughly 15-17 minutes each. The virtual or onsite loop is five to six rounds over one to two days. Meta's pace is deliberate. "Deliberate" is the polite word for it.
Coding: Two Problems, No Warm-Up, Godspeed
You have roughly 40 minutes to solve two problems in CoderPad. An interviewer watching the clock at minute 25 who sees you still on problem one is already forming a signal. That signal is not a compliment.
The difficulty skews medium to hard. Meta's distribution for software roles is roughly 26% easy, 60% medium, 14% hard, and MLE doesn't soften this. Expect a medium that comes quickly and a second problem designed to see if you can shift gears.
The Patterns That Come Up Most
Graphs are the biggest category. BFS for shortest paths, DFS for connectivity, topological sort for dependencies, Union-Find for connected components. Graph problems are a staple because they test whether you can reason about complex relationships while someone watches a timer.
Hash maps and frequency counting appear constantly. They underpin interval overlap problems, sliding window variants, and grouping tasks. If your first instinct on any "count things" problem isn't immediately "hash map," practice until it is.
Trees, especially binary trees and N-ary trees, come up regularly. Level-order traversal, LCA, path sum, serialization. Know both recursive and iterative forms, because interviewers sometimes ask you to redo the same solution in the other style.
Dynamic programming shows up less than graphs but still appears, usually as a follow-up or the second problem. 1D DP and 2D grid patterns are the most common shapes.
Common problems from candidate reports: Accounts Merge, Minimum Window Substring, Number of Islands, Word Break, Meeting Rooms variants, Decode Ways, Serialize/Deserialize Binary Tree.
Beyond correctness, Meta's rubric penalizes silence, messy code, and solutions that miss obvious edge cases. The coding interview scoring model applies: correctness, efficiency, communication, testing. Solve the first problem cleanly enough to actually reach problem two.
The MLE version of this: "Before we start, can you invert a binary tree and also design a two-tower retrieval system at billion-user scale?"
ML System Design: Think at Meta's Scale
This is where the MLE loop parts ways from SWE. Common questions:
- Design a personalized news feed ranking system
- Design a video recommendation system for Reels
- Design an ad ranking pipeline
- Design a friend suggestion system
- Build an abuse detection classifier at scale
The interviewer is not checking whether you memorized a paper. They want to see you structure the problem the way a senior engineer would in a design doc.
Start with the Problem, Not the Model
Start with the problem framing, not the model. What is the objective? What proxy metric will you optimize? How does offline accuracy connect to the online business metric you actually care about? Candidates who jump straight to "I'll use a transformer" before establishing the problem frame are signaling pattern-matching, not engineering judgment.
Then cover these layers:
Data. What training data exists? How is it labeled? What are the risks of label leakage or selection bias? For feed ranking, implicit feedback (clicks, watch time) is noisy. What counts as a positive signal? What as negative?
Features. Batch features (user history, content metadata, social graph), real-time signals (session context, recency), and dense embeddings. Be concrete. "User engagement rate" is vague. "7-day click-through rate per content category, bucketed into 10 bins" is a feature.
Model. Two-stage architectures dominate at Meta's scale: a fast retrieval model (ANN over embeddings) that narrows billions of candidates to thousands, followed by a heavier ranking model (GBDT or deep net) that scores the shortlist. Knowing when each stage is appropriate is close to a prerequisite for this interview.
Evaluation. Offline metrics (AUC-ROC, NDCG, precision/recall at K) and their limits. Why offline metrics alone are never enough. How you'd structure an A/B test, what guardrail metrics you'd track, and what significance looks like at Meta's traffic volumes.
Serving and monitoring. Inference latency constraints for a feed (typically under 100ms). Feature freshness. Model staleness. How you'd detect distribution shift or training-serving skew.
The Meta software engineer interview guide covers the general system design format. For MLE, expect the same structure with a full ML layer on top.
Applied ML Depth: Theory That Has to Do Something
Most system design rounds bleed into this through follow-up questions. The format is classic ML theory, framed around actual product decisions.
Expect questions like:
- Your model accuracy looks great offline but engagement dropped 3% after launch. What happened?
- You have 99% negative class imbalance in your abuse detection data. How do you handle it?
- Your model is well-calibrated on training data but badly miscalibrated on mobile users. Why?
- How would you decide between logistic regression and a deep two-tower model for this retrieval problem?
The best answer names the failure mode, explains the mechanism, and proposes a concrete mitigation. "I'd tune hyperparameters" earns partial credit at best. What breaks? Why does it break? What specifically do you change?
Topics to be solid on: bias-variance tradeoff, regularization (L1 vs L2 in terms of sparsity, not just the formula), calibration, class imbalance handling (cost-sensitive loss, oversampling, threshold adjustment), offline-online metric gaps, A/B testing fundamentals.
The Jedi Round: Where Your Level Gets Decided
Meta calls the behavioral round the "Jedi round." Yes, genuinely. The name is real and it is not optional.
Coding is the floor. Leveling between E4, E5, and E6 is decided almost entirely in the behavioral and system design rounds. A candidate who codes perfectly but shows thin behavioral evidence gets downleveled, not rejected. Targeting E5 but can't demonstrate cross-functional leadership and independent project ownership? You land at E4. The coding loop was just the ticket to get in the room.
Questions follow predictable themes: driving impact on an ambiguous project, navigating disagreement with stakeholders, mentoring others, making a call under incomplete information, recovering from a project that failed. Prepare three to four substantial stories from your own work. For each one, know the technical scope, the people involved, the decision you made, and the outcome you can quantify. The interviewer will probe every claim, so know the details behind your numbers.
Mistakes That Kill Good Loops
Solving problem one and running out of clock. Some candidates burn the full 40 minutes on a perfect first solution and never touch the second. Meta interviewers have limited ability to advocate for a 1/2 candidate. Get working solutions on both, even if the second is rough.
Designing the model before the problem. Starting with architecture before establishing the objective and metrics signals you memorized a template. Not the same as engineering judgment.
Hand-waving scale. "We can scale horizontally" without quantifying the problem (requests per second, candidate pool size, latency budget) is a missed signal. Meta's systems operate at a scale where vague answers are obvious.
Treating applied ML as a trivia quiz. Reciting the bias-variance tradeoff without connecting it to the product scenario is a weak answer. Name what breaks, explain the mechanism, then fix it.
Going silent in coding rounds. The communication signals Meta looks for in SWE interviews are identical for ML roles. Narrating your reasoning while you code is not optional.
The interview prep experience, accurately depicted.
Eight Weeks Is Enough
Eight weeks out: Cover the full DSA base. Graphs (BFS, DFS, Union-Find, topological sort), trees, DP patterns, sliding window, hash maps. Use LeetCode filtered by Meta tags, last six months. Target 60-70% medium, 20-25% hard. Practice explaining your approach out loud from problem one.
Six weeks out: Start ML system design. Pick five canonical problems (feed ranking, video recommendation, ad ranking, fraud detection, content moderation) and practice designing each end to end. Use the problem-frame-data-features-model-evaluation-serving structure until it is automatic.
Four weeks out: Layer in applied ML depth. Review calibration, class imbalance, feature engineering, A/B testing, offline-online metric gaps. For each topic, prepare a one-minute explanation and a product scenario where it becomes a real problem.
Two weeks out: Mock interviews under time pressure. The gap between knowing the material and performing it in a 40-minute session is real. Simulating the interview format at voice level closes that gap faster than re-reading notes.
One week out: Behavioral prep. Write out three to four STAR stories. Practice them spoken, not just written. Time yourself. Know the numbers behind your results.
For a broader view of the DSA patterns that matter for platform engineering roles, the DSA for backend engineers guide covers the same coding expectations that apply to MLE candidates.