SWE vs ML Engineer Interviews: What Changes at Senior Level

Moving from software engineer to machine learning engineer keeps the skeleton of your loop and changes its weights. As of 2026-10-16, object-oriented design falls from 16% of software-engineer write-up links to 6% of links from ML, AI, research and data-science candidates, while behavioral and knowledge rounds rise from 22% to 33%, coding falls from 44% to 38%, and only system design holds level at 15%. Our take: keep your algorithm prep, cut object-oriented design to a refresher, and spend the freed hours on ML coding, ML fundamentals drills and three ML design families.

Disclosure: TrueInterview is an interview-preparation product and publishes this article. Facts about other products come from their public pages on the dates listed under Sources.

How does the ML engineer loop compare with the software engineer loop?

The two loops share their largest blocks: coding and system design take similar shares for both groups, and the difference sits in object-oriented design, knowledge rounds and a handful of questions that only ML candidates report. The table compares shares of 4609 software-engineer write-up links with 739 links from ML, AI, research and data-science candidates, both as of 2026-10-16, so it measures what each group reported rather than the official structure of either loop.

Verdict on the SWE loop: if you are strong at object-oriented design, that strength buys less in an ML loop, so stop adding to it. Verdict on the ML loop: it rewards the production engineer who has learned to argue about data, which, in our view, is a gap of preparation rather than a new career.

PracHub's guide makes the same framing in one line: "The transition is not a reset." The sections below measure how far each round moves and name the questions that replace the ones you drop.

Do ML engineer candidates still get LeetCode-style coding rounds?

Yes. Coding is still the largest single block of the ML loop in the table above, and the moderndescartes.com essay describes the ML engineer coding round as "Code a solution to a LeetCode-style problem." Treat the algorithm screen as the first gate: it decides whether anyone ever sees your ML knowledge.

Aced's guide states the risk plainly: "If you overprepare the ML rounds and underprepare algorithms, you can fail the first screen." The same guide says the data-structures-and-algorithms bar for ML roles is rising toward the software engineering bar. Aced's guide also relays one Waymo candidate's view that a strong software engineer may pass the coding screen and then struggle on ML system design and ML coding, while a strong ML engineer may fail on the algorithm question. If that candidate's account holds for your loop, the algorithm screen is where a switcher starts ahead, and the ML rounds are where the work goes.

The topics that lead the bank's 1482 coding questions are graphs (233), hashing (209), strings (205) and arrays (190). In phone screens, graphs (158) and hashing (123) lead. The moderndescartes.com author considers indexing, search, graph, tree and heap problems the most appropriate for ML engineers. PracHub's guide agrees that core data structures and algorithms remain relevant for MLE candidates. So keep a daily coding slot with graph traversal and hash-map problems at the front, such as Course Schedule, and budget ML study on top of it rather than instead of it.

Our take: the common advice to trade LeetCode for ML theory is backwards for an experienced engineer. Your coding skill is a depreciating asset if you stop practising, and it is the round where you start furthest ahead.

Which round should you shrink?

Object-oriented design. It is the one category whose share drops by more than half between the two groups in the table, and it is falling across the whole bank too: object-oriented design took 19% of all write-up links in 2025-Q4 and 11% in 2026-Q3. That second trend is a share of links, not a total, and it covers every role.

At Meta, the bank files 15 object-oriented design questions against 172 coding and 147 behavioral or knowledge questions. If your SWE plan had a full week of low-level design, cut it to two evenings: one class-modelling warm-up and one concurrency-flavoured refresher. Move the rest of those hours to ML fundamentals and ML coding, where the ML-only questions in the next section live.

Keep one caveat in view. Amazon, Microsoft and Uber still list object-oriented design among their top non-coding subtypes (38, 26 and 21 questions). If one of those is your target, shrink the block to a refresher rather than deleting it.

What is the ML coding round, and which questions do only ML candidates report?

The ML coding round asks you to implement, vectorize or debug a model rather than solve a puzzle. Aced's guide says a coding round can mean "pure algorithms, basic Python, numpy data manipulation, or building layers in a framework like PyTorch". These are the questions ML candidates link and software engineers almost never do.

Three of these deserve a closer look.

Debug a Transformer and Convert It to a Classifier

This is the clearest ML-only signal in the bank's role split. The write-ups behind these counts give the title, not the full prompt, so what follows is general preparation for the task the title names. In our view, the standard approach is to check the places transformer code usually breaks: the attention mask, the axis of the softmax, the scaling by the square root of the head dimension, and the residual and layer-norm order. Then replace the language-model head with a pooled representation and a linear classification layer. Your SWE debugging habit transfers directly: shrink the input, assert tensor shapes at each layer and compare against a known output.

Vectorized 1-NN and Neural Network Forward Pass

As with the transformer question, the title is what candidates report; the preparation below is general technique, not the prompt's reported content. The core technique for nearest neighbour is the pairwise-distance identity (squared norms of each set plus minus twice the dot product) computed with broadcasting, followed by an argmin. The forward pass is matrix multiplication, bias and activation, layer by layer. Loops over rows are the failure mode, so practise writing both without a single Python loop.

Classifier with Noisy Annotators

In our view, this one tests data reasoning more than modelling; the title is reported, and the approach below is general technique. The standard options are aggregating labels before training (majority vote, or weighting annotators by estimated reliability) or keeping the soft label distribution and training against it. Say which you would choose given how many annotators label each example and whether their disagreement carries signal.

For the knowledge drills, diagnosis beats recall. Aced's guide relays a Pinterest interviewer who treats changing the batch size first as a red flag, because it forces retuning every other hyperparameter. Aced's guide recommends "diagnosis before action" instead. One candidate's write-up on artgor.medium.com also reports that ML theory interviewers vary widely in how much depth they expect. Ask your recruiter which form the coding round takes, then rehearse that form first.

Which data and evaluation questions trip up software engineers?

Data splits, leakage and metric choice. PracHub's guide says a backend engineer can design a reliable API and still fail an ML engineering interview by optimizing the wrong metric, splitting data incorrectly, or treating a notebook score as production evidence. These are the questions where a strong SWE answer sounds confident and is still wrong.

PracHub's guide gives two concrete traps. In PracHub's guide, random row splitting can leak the same user, device, patient, or seller into both train and validation sets. Time-dependent systems often need an out-of-time test rather than a random split, according to the same guide. When leakage comes up, PracHub's guide advises naming the offending operation and moving it inside a pipeline or fold. The same guide argues that the signal is a defensible choice under constraints rather than the volume of terms you can recite.

Our take: this is the cheapest gap to close and the one SWE candidates tend to skip, because it looks like theory. It is closer to the correctness reasoning you already do for distributed systems: who can see what, and when. Practise the label side on Classifier with Noisy Annotators, and the split and metric side on any ranking design you rehearse.

How is ML system design different from the system design you know?

It is narrower than an open-ended round on any ML system. In the bank's 475 design questions, ads, recommendation and ranking ML (59) and LLM, RAG and AI infrastructure (42) are the two largest families, and A/B testing and experiment design adds 30. These counts cover every role, not only ML candidates; even so, our take is that they are the three families an ML switcher should prepare end to end.

The round matters too. Onsite design questions lead with ads, recommendation and ranking ML (45) and LLM, RAG and AI infrastructure (28). Phone-screen design questions lead with A/B testing and experiment design (24). Aced's guide independently says ML system design rounds "keep returning to recommendation, ranking, and retrieval". If your phone screen includes design, rehearse an experiment design first; save the ranking system for the onsite.

The moderndescartes.com author found that some ML system design interviews were regular system design interviews with ML terms added. One candidate's write-up on artgor.medium.com describes ML system design as emphasizing data preparation, model training and deployment, monitoring, and maintenance. The two accounts pull in different directions: the moderndescartes.com author criticises the rounds that only add ML vocabulary, while the artgor.medium.com write-up stresses a lifecycle that classic design does not cover. Our take: prepare for both, so the classic boxes you already draw stay, and the data and model lifecycle is what you add.

PracHub's guide gives a usable opening order: "Start from the product action, not the model." PracHub's guide then advises drawing the serving path and the training path separately. PracHub's guide also warns that scheduled retraining is not automatically safe, because a new dataset or model still needs gates and rollback. Gates, rollback and serving latency are where your production record earns credit, so say them out loud.

One freshness caution comes from the moderndescartes.com author, who notes that interview problems can go stale as the field advances and that RAG was popular in 2024 and, in the author's view, already obsolete by 2025. Our take: still expect LLM and RAG prompts, since the bank's counts above put that family second, but frame retrieval as one component of a ranking or serving design so the answer does not date.

How should you position your SWE experience in behavioral and project rounds?

State it as the asset it is. Behavioral and knowledge rounds take a third of ML-candidate links in the table above, and Aced's guide says behavioral rounds at some companies now include a technical walkthrough of a past project. A project deep dive is where a shipped system, described with its data decisions, outweighs a notebook.

The bank's Project Deep Dive (Resume Drill) was last reported at a ByteDance phone screen in 2026-09. It is linked from 9 ML-candidate and 38 software-engineer write-ups, which, given the two groups' sizes, makes it slightly more common among ML candidates. The moderndescartes.com author would request a position-relevant project deep dive instead of testing recall of a specific algorithm. PracHub's guide recommends building one project that covers the full decision path instead of five notebooks.

Our take: do not apologise for coming from backend or infrastructure work. Pick one system you shipped that touched a model or a ranking, and write down the split you would use, the leakage check you would run and the metric you would defend. That one page turns a missing ML title into evidence that you have run ML in production and know where it fails. Rehearse it on Describe your most impactful project.

Where does ML content sit at each company?

It depends on the company, so match the add-on to the target. These company counts cover every role, including data-science loops where statistics and SQL concentrate, so read them as what each company's reports contain, not as an MLE-only mix. Statistics is a top-three non-coding subtype at Meta (58), Google (24) and Uber (20). ML fundamentals is a top-three non-coding subtype at Amazon (26), ByteDance (19) and Microsoft (7). The coding block stays at every one of them.

For AI labs, Aced's guide says Anthropic has woven safety and data-ethics reasoning into its technical rounds. Pair that with the bank's LLM serving prompts, such as Design GPU Inference Serving System.

Our take: the decision rule follows from the table, with the all-roles caveat above. At Meta, Google or Uber, add statistics and experiment design; at Amazon, ByteDance or Microsoft, add ML fundamentals drills; at an AI lab, add LLM and inference-serving design. In every case, keep the algorithm slot as it is.

Worked example: a senior backend engineer targeting an MLE role at Meta

Start from the Meta row. The coding block stays graph-, string- and hash-heavy, so the daily algorithm slot is unchanged. Object-oriented design is small at Meta, so it drops to one evening. Statistics sits just behind SQL among Meta's non-coding subtypes, so it gets the largest new ML-specific block. For design, prepare Reels / Short Video Recommendation as the ranking prompt and one experiment design, since those are Meta's two leading design families, and Reels is a Meta question in the ranking family. Then add ML coding on Debug a Transformer and Convert It to a Classifier, the most-linked of the ML-skewed questions in the role split above.

How has the format changed with LLMs and AI-assisted coding?

AI-assisted coding already takes a larger share for ML candidates than for software engineers in the table above, and one LLM question shows the same tilt: "Agents / Coding with LLMs" is linked from 8 ML-candidate write-ups and 4 software-engineer write-ups. If your target is an AI lab or a team shipping LLM features, plan for a round where using or reasoning about a model is part of the task.

Recent AI-assisted coding examples include Maze Solver at a Meta onsite in 2026-09. On the behavioral side, "GenAI Usage (How / Failure / Tradeoff)" is linked from 29 candidate write-ups, all at Amazon. Across every role, the coding share rose to 51% of links in 2026-Q3, so do not read that rise as an ML-specific trend.

Our take: practise one AI-assisted coding session where you narrate what you accept from the model and what you verify, and prepare one story about a model output you rejected and why. Both are short to prepare and both are now reported often enough to plan for. Rehearse with Agents / Coding with LLMs.

What changes at senior and staff level?

Design carries the level signal. Across all write-ups, system design is linked 678 times by senior-or-above candidates and 132 times by junior-or-below candidates, based on the levels candidates reported for themselves. In our view, that skew makes the ML design round the one an experienced switcher should treat as deciding the level.

The ads, recommendation and ranking ML family is one of the most senior-skewed design families, with 107 senior-or-above links against 10 junior-or-below. Design GPU Inference Serving System is linked only by senior-or-above candidates (22 write-ups, 2 of them staff-plus or manager). Behavioral and knowledge links also lean senior, 798 against 477. Questions linked only from senior-or-above write-ups include "Describe your most impactful project" (18) and "Design an Ads Frequency Cap System" (13).

Our take: at senior level, the interviewer wants you to name the trade-off before being asked: the freshness cost of a feature, the latency cost of a larger batch, the risk of shipping a model without a rollback gate. At staff level, add scope: who owns the training data, how two teams share one ranking model, and what you would refuse to launch without an offline-to-online metric check.

Down-leveling: which rounds carry the level decision

In our view, the level decision for an ML switcher rides on the ML system design round, the project deep dive and behavioral scope, while coding mostly decides pass or fail. The risk specific to switchers is a down-level that reflects thin ML evidence rather than thin engineering depth, so make the deep dive about data and evaluation decisions you made. If the recruiter signals a level below your current one, ask which round drove it, and rework that round first.

How we counted

Counts come from TrueInterview's question bank as of 2026-10-16, which holds 3432 practice questions reported at 25 big-tech companies. Role splits use the role on each write-up: software engineers contribute 4289 links and machine learning engineers 596, with backend engineers, data scientists and research scientists adding more. The comparison groups in the first table pool roles, so the ML side adds AI, research and data-science candidates to machine learning engineers, and the software-engineer side counts more links than the single role label. They are candidate-reported questions reconstructed for practice, not any company's official question list. Shares are of write-up links, which measure what candidates reported and linked, not how often a company asks a round, and a link count is not a count of distinct write-ups.

FAQ

Do ML engineer candidates still need LeetCode?

Yes. The algorithm screen comes first in the loop Aced's guide describes, which opens with a recruiter screen and one coding screen before a final loop of four to six rounds. Keep your coding practice running daily through the whole plan, and use graph and hash-map problems as the core, since those lead the bank's coding reports as shown above.

What is the difference between an ML coding round and a DSA round?

A DSA round asks for an algorithm with the right complexity. An ML coding round asks you to implement, vectorize or debug model code: a forward pass in numpy, a nearest-neighbour search without loops, or a broken transformer. The table of ML-only questions above lists the exercises candidates report, each with a practice page, so rehearse the form your recruiter names.

How much math and statistics does a software engineer need for MLE interviews?

Enough to defend choices: bias and variance, regularization, metric choice, splits and leakage, and the statistics behind an A/B test. The moderndescartes.com author lists implementing and analyzing ML methods via statistics, calculus and linear algebra as one skill an ML interview should measure. Spend more on statistics if you target Meta, Google or Uber, where it is a top-three non-coding subtype.

Is ML system design a different discipline from system design?

Less than it sounds. The moderndescartes.com author found that some ML design interviews were regular system design with ML terms added. What is new is the lifecycle: training data, evaluation, retraining gates and monitoring. Prepare one ranking design, one LLM serving design and one experiment design.

How long does it take to prepare for an MLE loop as a software engineer?

Our estimate, for an experienced engineer working full time whose coding prep is already in shape, is about three weeks, because the new material is narrow: a few ML-only drills, three design families and one deep-dive story. It varies with your ML background and target company. If your algorithm practice has lapsed, restore that first and extend the plan rather than cutting coding.

Your practice plan

A three-week plan for someone working full time, built on the SWE prep you already have.

1. Every weekday for all three weeks: keep a single algorithm problem as your daily slot, led by graph and hash-map problems such as Course Schedule. Do not let ML study displace it.
2. Week one: ask your recruiter whether the coding round is algorithms, numpy or PyTorch layers. Then do Vectorized nearest neighbour and forward pass without Python loops, and Transformer debugging with shape assertions at each layer.
3. Week one: cut your object-oriented design block to one refresher evening, and move those hours to the model debugging drill and quick-fire fundamentals.
4. Week two: work through label quality on Classifier with Noisy Annotators, then take one shipped system of yours and name its split, leakage check and metric.
5. Week two: rehearse one ranking design such as Design an Ads Frequency Cap System and one serving design such as Design GPU Inference Serving System, drawing the training and serving paths separately with a rollback gate.
6. Week three: add the company layer from the table above. For Meta, Google or Uber, prepare one experiment design and a statistics set; for Amazon, ByteDance or Microsoft, finish the transformer and regularization drill; for an AI lab, deepen the inference-serving design.
7. Week three: write your project deep dive as one page that pairs a system you shipped with the split, leakage check and metric behind it, and rehearse it on Project Deep Dive (Resume Drill).

For more prompts by company, browse TrueInterview's question bank.

Sources

• TrueInterview question bank — big-tech interview at big-tech companies — counted 2026-10-16
• Machine Learning Interview Prep (2026 Guide) - Aced (formerly Exponent) — checked 2026-10-16
• Software Engineer to Machine Learning Engineer: Interview Gaps to Close | PracHub Knowledge Hub — checked 2026-10-16
• Interviewing for ML/AI Engineers — checked 2026-10-16
• Medium — checked 2026-10-16

Last reviewed: 2026-10-16.