ML System Design vs System Design Interviews: What Changes

In practice, ML system design is the classic distributed-systems round with the data and model lifecycle drawn onto the whiteboard; the round's label follows your job family, while the prompt's content follows your target company and round. As of 2026-10-11, TrueInterview's bank files 125 of its 381 candidate-reported design questions as ML system design and 256 as distributed systems. The phone screen skews to ML-named families: of 112 design questions reported there, the top two families are LLM, RAG and AI infrastructure (15) and ads, recommendation and ranking ML (13). Our take: some companies scope ML design as its own MLE component, so confirm your loop, then choose what to prepare from the company and round.

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 do the two rounds compare side by side?

A classic round grades how you store, move and protect data under load; an ML round grades that plus how the system learns from its data and proves the model works. The rows mix TrueInterview's counts with named guides, and the two verdicts follow the table.

Verdict on distributed design: the safer default when you know nothing about the loop, since it is the larger pool in the bank. Verdict on ML design: prepare it whenever your target company's counts lead with an ML family, including on a SWE loop.

What carries over, and what does the ML round add?

The ML round adds three things to the classic primitives: a training path, one feature definition shared by training and serving, and an evaluation loop that runs before and after launch. Each one creates a failure that a classic answer never has to name.

The ML-specific failure is the one candidates under-rehearse. The mockingly.ai guide says training-serving skew is "one of the most common silent killers of production ML systems." Interview101's guide reports that Meta's engineering and recruiting documentation names training-serving consistency and model monitoring as MLE evaluation areas. So draw the feature computation once, show both the training job and the serving path reading from it, and say how you would detect drift between them.

Treat the model as a dependency that can be confidently wrong, slow or down. An interviewer quoted on deepengineering.net says strong candidates immediately ask what happens when the model is wrong, what the fallback is, and how they would know it is drifting. In a classic round the equivalent questions concern a replica or a downstream service; in an ML round they concern a prediction that is confidently wrong, and accuracy and drift monitoring catch what a liveness or latency check cannot.

Worked example: one skeleton, three constraint sets

Take two scheduling prompts from the bank. Design Job Scheduler is linked from 21 candidate write-ups, 16 from candidates who self-reported senior or above and 5 from junior, new-grad or intern candidates. Its ML-infrastructure sibling, Design GPU Scheduling Platform, has 19 senior-or-above and 3 junior-or-below write-ups. A third prompt, Design GPU Inference Serving System, is filed at Anthropic alone, linked from 22 write-ups, and was reported in an Anthropic phone screen last reported in 2026-07.

The skeleton is identical: a durable queue, a scheduler, workers with leases, retries and back-pressure. For the classic job scheduler, the interviewer pushes on execution semantics: at-least-once delivery with idempotent jobs, and what happens when a worker dies holding a lease. For GPU scheduling, the resource changes the argument. A distributed training job needs all of its GPUs at once, so the decisions are gang allocation, preemption with checkpoints, and fairness between teams against utilisation.

For GPU inference serving, the decisions are the batching policy against a latency target and what to shed when a burst arrives. An interviewer quoted on deepengineering.net says experienced candidates talk about "which requests actually need an expensive model vs which can be routed to cheaper classifiers," which is the per-dollar reasoning a classic round applies to storage and compute, applied here to which requests are worth an expensive model. Rehearse all three on one diagram, changing only the resource being scheduled and the constraint you argue about.

Who gets which round: SWE, MLE or applied scientist?

Your job family decides whether the round is called ML system design, and the company decides whether the prompt is a ranker, an inference service or a job scheduler. Interview101's guide says Google's interview preparation documentation describes ML system design as a distinct component for MLE candidates, covering data pipelines, training infrastructure, model serving and monitoring. A SWE candidate keeps the classic label, yet at ML-heavy companies the prompt itself is often an ML system.

MLE candidates can face a third variant. The yuan-meng.com post on ML infra interviews says "A handful of companies like Netflix, Snap, Reddit, Notion, and DoorDash have an ML infra system design round for MLE candidates". The same yuan-meng.com post says ML infra design covers "the offline + online pipelines that support an ML system". In our view, that round sits closer to the classic one than model design does. The same yuan-meng.com post lists components such as a feature store, real-time feature updates and distributed training, which a backend engineer can reach by extending storage and pipeline answers, provided the ML-specific parts are added.

The MLE loop also carries a round that SWE candidates rarely see. Interview101's guide lists three MLE question types, "coding with ML context, ML system design, and applied ML problem framing," and says SWE-background candidates prepare "almost not at all for the third." Patrickhalina.com's guide reports that "Some companies blended the questions with regular distributed systems designs while others focussed more on theoretical ML."

None of the sources here describes applied-scientist loops separately. Our take: if you are an applied scientist, expect the MLE format with more weight on problem framing and evaluation, and confirm it with the recruiter rather than guessing.

Which companies and rounds lean toward ML design?

The company shapes the prompt more than your title does, even though the round's label follows your job family. Meta's 52 filed design questions lead with ads, recommendation and ranking ML (12) and OpenAI's 40 with LLM, RAG and AI infrastructure (8), while Amazon's 40 lead with metrics, logging and data pipelines (6) and Uber's 27 with maps, ride-hailing and delivery (7).

Meta is the clearest case of an ML family leading a large pool, and OpenAI is the clearest case of a mixed one. OpenAI's second family is payments, and its Payment / Coffee-Shop Ordering (read the prompt!) is linked from 16 write-ups and was reported in an OpenAI phone screen last reported in 2026-06. An OpenAI candidate who prepares only LLM serving is underprepared. A Design Gurus Substack post says Google is "increasingly weaving AI/ML system design questions into the loop". The bank does not show that tilt yet, so for Google keep classic design as the base.

Rounds point the same way. Onsite, where 292 questions were reported, ads and ranking ML leads (39), then LLM and AI infrastructure (27), booking (22) and metrics (21). Classic prompts still open loops too: Amazon's Design News Feed was reported in a phone screen last reported in 2026-07. Decision rule: if your loop includes OpenAI, Anthropic or Databricks, build the LLM and AI-infrastructure module first; for Meta or ByteDance, build ranking plus the company's other leading family; for Uber, maps and dispatch first, ranking second; for Amazon, start with pipelines. If you get one design round, prepare the family your target company leads with: ranking for Meta, LLM infrastructure for OpenAI, pipelines for Amazon, maps and dispatch for Uber.

How should your preparation differ?

Prepare the shared skeleton once, then spend the remaining hours on the half your background skips. Backend candidates usually lack the training path, the feature definition and the evaluation plan; MLE-track candidates usually lack the queues, partitioning and the cost argument. The mockingly.ai guide puts the MLE trap plainly: "Most candidates spend 80% of their prep on model architecture and almost nothing on the surrounding system."

Our take: model architecture is where most candidates put their preparation, and the bank points the other way. The two most-linked ML prompts in the worked example are scheduling and serving problems first, and the model barely appears in either. If you have one week to convert a classic preparation into an ML one, spend it on the data path, evaluation and compute cost, and skip lists of model trivia.

Is ML design growing relative to classic design?

The LLM and AI-infrastructure share has been the steadier line, while ads and ranking peaked and fell. By interview quarter, ads, recommendation and ranking took 16%, 22%, 10% and 7% of write-up links from 2025-Q4 to 2026-Q3, while LLM, RAG and AI infrastructure took 10%, 10%, 15% and 13%.

Read shares, not totals: the quarterly link totals mostly reflect how many write-ups were collected. The shift is still useful for planning. Ranking remains the largest ML family, but its share of write-up links fell from 22% in 2026-Q1 to 7% in 2026-Q3, so time-box it to loops whose counts lead with it. Keep a permanent LLM and AI-infrastructure module, because its questions are filed across Anthropic, Databricks and OpenAI rather than one employer. Techinterview.org lists modern system design problems as including "LLM serving, embedding stores, retrieval-augmented generation systems, ML training infrastructure, and AI inference at scale." None of this is a forecast, and no source here shows ML design replacing the classic round anywhere.

What changes at senior and staff level?

The ML families are where senior candidates concentrate. Across all design questions, write-ups link 635 times from candidates who self-reported senior, staff-plus or manager level and 126 times from junior, new-grad or intern candidates. Among the highest-volume families, the gap is widest in ads and ranking ML (94 vs 10) and LLM and AI infrastructure (87 vs 11), and narrower in maps and ride-hailing (24 vs 13).

Trading and market data also skews less senior, at 23 senior-or-above against 8 junior-or-below links. If you are junior, spend the ML hours on one ranking prompt and put the rest into maps, booking and trading designs. If you are senior or above, the ML-infrastructure deep dive is where the level is read.

Some prompts have no junior-or-below write-ups at all: Design GPU Inference Serving System (22, 2 of them staff-plus or manager), Design an Ads Frequency Cap System (13), Design Google News (11), Reels / Short Video Recommendation (6), Design A Feed Recommendation System (6) and L6 System Design (Staff Loop) (5). Staff-plus or manager write-ups also link Design Job Scheduler (2) and Design Distributed AI Model Downloader (1). A Design Gurus Substack post says Google gives L5 one mandatory design round and L6+ two to three of increasing complexity. The same Design Gurus Substack post says L6+ candidates "must demonstrate mastery of distributed consensus, operational concerns, and production reliability."

Our take: at staff level the topic list barely changes; what changes is who owns the constraint. A senior answer says you would put a queue between services. A staff answer says what the queue costs, what it drops and what happens when it backs up, and in an ML design the same argument is about compute, feature freshness and the cost of a wrong prediction. The deepengineering.net article quotes an interviewer: "a good engineer would design for performance, but a great engineer would design for performance per dollar".

Where experienced candidates get down-leveled

In our view, the level signal sits in three places. The design deep dive is the first: a devrimozcay1 Substack post says "What the interviewer can use is the deep dive." The project deep dive is the second, where an ML-infrastructure component you owned end to end carries more signal than a model you tuned. Behavioral scope is the third: a team-sized story reads as senior, a multi-team one as staff. If you are targeting staff, rehearse your deep dive with the cost and failure argument as hard as the design prompt.

How we counted

These are candidate-reported questions reconstructed for practice, not any company's official question list. Each question's family is assigned from its title, so families can cross the ML and distributed subtypes, and 28 titles match no family. A question can be reported in more than one round, and 347 of the 381 were last reported within the 12 months before 2026-10-11. Write-up link counts show how many candidate write-ups mention a question, not how often a company asks it, and levels are what candidates reported about themselves. TrueInterview says engineers who have worked at companies that run these loops review each question by hand before it is filed.

FAQ

Do software engineers need to prepare ML system design?

If your target companies lead with an ML family, yes, even on a SWE loop. About one in three reported design questions is ML system design, and the phone screen is where it leads, so a SWE candidate can meet an ML prompt in a phone screen, before any onsite. Patrickhalina.com's guide says "it's very common for consumer big tech companies to ask questions about recommender systems in their system design". For that you need a training path, a feature definition shared with serving, an online test and a fallback ranking, rather than model theory.

Can a classic system design answer pass an ML prompt?

The queue-and-cache skeleton passes; a missing training path and evaluation plan fail it. Interview101's guide says that in a feed-ranking degradation scenario, "A candidate reasoning in SWE mode reaches for monitoring alerts and rollback mechanisms." Those are correct operational moves, but they do not explain why the model degraded or how you would know. Convert a classic answer by adding the training path, one shared feature definition, an offline and online evaluation plan, and the drift signal that triggers retraining. Rehearse the conversion on a prompt you already know well.

Is ML system design asked in phone screens or only onsite?

Both. In the bank, ML families lead the family counts in the phone screen and the onsite alike, and Anthropic's GPU inference serving prompt is a dated phone-screen example (see the worked example above). The difference is that a phone screen is short and gives no second chance, so prepare one ML prompt to the same depth as your best classic one before your first screen, rather than saving ML design for the onsite.

Is a machine learning system design PDF or GitHub list enough?

It is enough for the framework, not for choosing what to practise. Patrickhalina.com's guide, still widely linked, shows "Last Updated: Jan 17, 2021", before the LLM and GPU-serving prompts that now appear in phone screens. Use a book or list for the answer structure, then pick prompts from dated, round-labelled reports for your target companies, and give the infrastructure prompts at least as much time as the recommender ones.

Your practice plan

A three-week plan for someone working full time: two or three evening sessions a week, each one prompt drawn end to end and then defended aloud.

1. Day one: write down your target companies and your next round, find each company's row in the company table, and note its leading family. That family is your first ML module.
2. Week one, classic skeleton: rehearse Design Job Scheduler end to end. Say aloud how jobs execute at least once without side effects twice, and what happens when a worker dies holding a lease.
3. Week one, a classic prompt from your companies' pools: for OpenAI, whose second family is payments, practise Design Payment System with idempotency keys and a double-entry ledger; for Amazon or Meta, practise Design News Feed with the fan-out decision.
4. Week two, convert the scheduler: take the same skeleton into Design GPU Scheduling Platform, and argue gang allocation, preemption with checkpoints and team fairness against utilisation.
5. Week two, serving: rehearse Design GPU Inference Serving System with a batching policy tied to a latency target, a load-shedding order and a cheaper fallback model.
6. Week three, ranking: practise Design an Ads Frequency Cap System, deciding how exact the per-user counters must be and how they stay consistent across regions at serving time. Then add the training path, labels and an online test to any ranking design.
7. Week three, a timed mock: run one full interview slot with an ML checklist next to the classic one: framing, data and labels, training-serving consistency, evaluation, monitoring, and the compute you asked for.
8. If you are senior or above: prepare a deep dive on one component you owned, with the trade-off you made, the option you rejected and the cost of running it.

Sources

• TrueInterview question bank — system design at big-tech companies — counted 2026-10-11
• Machine Learning System Design Interview: Complete Prep Guide — checked 2026-10-11
• What Interviewers Actually Score in System Design Rounds — checked 2026-10-11
• MLE Interviews Are Not SWE Interviews With ML Questions Appended — Here Is What Evaluators Are Actually Measuring — checked 2026-10-11
• Google L5 System Design Interview — What Is Scored — checked 2026-10-11
• System Design Hiring Is Really a Judgment Test — checked 2026-10-11
• Preparing for ML Infra System Design Interviews | Yuan Meng — checked 2026-10-11
• ML Systems Design Interview Guide · Patrick Halina — checked 2026-10-11
• Google System Design Interview: What Changed, What They Ask, and How to Pass — checked 2026-10-11
• Nailing the Machine Learning Design Interview | Towards Data Science — checked 2026-10-11
• AI in System Design Interviews: How the Round Changed in 2026 – techinterview — checked 2026-10-11
• The Deep-Dive Tape: How I Filled 22 Minutes of a Senior System Design Round With the Decisions That Got the Offer — checked 2026-10-11
• Interview prep compared: your application, end to end · TrueInterview — checked 2026-10-11

Last reviewed: 2026-10-11.