The Role Decoded & the Interview Loop
What ML platform and ML-data roles are actually accountable for, how the interview loop is assembled, what each round is scoring, and the four-level rubric that every drill in this guide is calibrated against.
What the role actually owns
Strip the job titles away and the accountability is the same everywhere: the data contract between the business and its models. A data scientist owns the model; a product engineer owns the application; this role owns everything in between — the systems that turn raw events and records into training sets and served features, and the guarantees on those systems. Concretely, at a senior level you are on the hook for:
- Training data as a product. Versioned, reproducible datasets with known provenance, built so the features a model trains on are exactly what it could have known at prediction time. When a model regresses, you are the person who can say whether the data changed.
- Feature infrastructure. Definitions, computation (batch and streaming), storage (offline and online), retrieval at serving time, backfills, and the consistency between offline and online values.
- Labels and feedback. How ground truth is collected, how long it takes to arrive, how it is stored, and how predictions are joined back to outcomes so the model can be evaluated and retrained honestly.
- Serving-side data. The online store, the entity lookups, embeddings and vector retrieval, the request-time assembly of model inputs, and its latency budget.
- Operating it. Validation gates, drift and skew monitoring, lineage, cost per training run and per prediction, and the privacy and retention rules that apply to data the moment it becomes training data.
"I make sure the model sees, in production, the same data it was trained on — and that we can prove it, rebuild it, and afford it." If your answers in the loop keep returning to that sentence, you are describing the role the way the people hiring for it describe it.
Three titles, one job
The same accountability hides under several titles, and the emphasis of the loop shifts with the title. Decode the posting before you prepare.
| Title | Centre of gravity | What the loop leans on | Watch for |
|---|---|---|---|
| ML Platform Engineer | Shared infrastructure for many teams — feature platform, training pipelines, model registry, serving | Platform design for multiple consumers; contracts; self-serve; cost allocation | Questions about tenancy, abstractions, and "how do 20 teams use this without you" |
| Data Engineer, ML / Applied ML | One model family (ranking, fraud, forecasting) and its data path end to end | Depth on point-in-time correctness, streaming features, the specific domain's labels | Domain probes: "what's the label for fraud, and when do you get it?" |
| Staff DE on an ML team / MLOps | Reliability and reproducibility of the whole loop: data → train → deploy → monitor | Lineage, validation gates, drift, incident stories, migration and governance | "Tell me about a time the data broke the model" — have two stories ready |
Whatever the title, expect one system-design round to be the deciding one. This guide is built for that round; the coding and behavioural rounds are covered in 10 only to the extent they differ from a standard senior loop.
How the loop is structured
A typical senior/staff loop for this role has four to five rounds. The shape below is the composite; individual companies rearrange it, but the scoring dimensions are stable.
| Round | Length | Format | What it's really scoring |
|---|---|---|---|
| ML data system design | 45–60 min | Whiteboard discussion: "design the data platform for our fraud model / ranking system / recommendations" | The five moves in 02. Time correctness, offline/online consistency, defended trade-offs, numbers. This is the deciding round. |
| Past-system deep dive | 45 min | You present a system you built; they interrogate it | Whether you owned the failure modes or just the happy path. Have the numbers (volumes, latencies, cost) and the incident. |
| Coding / SQL | 45–60 min | A point-in-time join in SQL, a dedup/windowing problem, a small pipeline in Python, sometimes a pandas/Spark transform | Correctness under time semantics; idempotency; whether you test edge cases without prompting |
| ML fundamentals (sometimes) | 30–45 min | Conversation with a scientist: leakage, evaluation, splits, feature importance, why a model degrades | Enough ML literacy to be a real partner — not to train the model, but to know what breaks it |
| Behavioural / values | 45 min | Cross-functional stories: scientists, product, infra | Whether you can hold a contract with people who don't report to you |
Recruiters will tell you the round list if you ask, and usually which round is the "ML data" one versus a generic system-design round. Ask. If the design round is generic ("design a data platform"), steer it toward ML consumers in your requirements phase — "the highest-stakes consumer here is the fraud model, so I'll design for its freshness and correctness bar and let BI ride along."
What graders reward
Interviewers for these roles have almost always been burned by a data problem that looked like a model problem. Their rubric, whether written or not, rewards the candidate who anticipates that class of failure.
- Leading with time. Do you raise point-in-time correctness, label delay and training/serving skew before being asked? This is the single strongest signal in the round.
- Numbers. Events per second, entities, features per entity, feature freshness, p99 retrieval latency, training-set size, cost per training run. Estimates turn opinions into designs.
- Two paths, one definition. Can you draw the offline and online paths and explain what keeps them consistent — a shared definition, a shared computation, or a reconciliation job?
- Defended forks. Batch vs streaming features; buy a feature store vs build on the warehouse; warehouse vs lakehouse; vector database vs pgvector. A decision, its cost, and the condition that would flip it.
- Operability and cost. Who runs this, what it costs at 10×, how a bad feature is rolled back, how a training set with PII is retained and deleted.
- Knowing what not to build. Staff-level candidates say "you don't need a feature store yet" when it's true, and can explain what they'd do instead.
The levelling model
Every drill ends with the answer at four levels. The definitions are constant, so you can locate yourself on any question and see exactly what the next level adds.
| Level | What it sounds like | What it lacks |
|---|---|---|
| L1 · Foundational | Names the components. "Features go in a feature store; we train on the warehouse." | No mechanism, no time semantics, no numbers. |
| L2 · Practitioner | Has shipped the happy path. Distinguishes offline from online; knows a training job needs a snapshot. | Discovers leakage, skew and backfills only when prompted; trade-offs are lists, not decisions. |
| L3 · Senior | Opens with the failure modes and designs around them. Point-in-time joins, event-time semantics, idempotent backfills, freshness SLAs with numbers. Decision sentences with flip conditions. | Designs for one model; less on multi-team contracts, cost allocation, governance. |
| L4 · Staff | Designs the platform for many models and teams: producer/consumer contracts, feature ownership, cost per prediction, PII lifecycle in training data, migration paths, and what to defer. | — |
Offers at senior are usually decided at the L2→L3 boundary; staff at L3→L4. The through-line from L2 to L3 is proactivity about correctness; from L3 to L4 it is designing for people you don't manage.
Tells of seniority
Small things that experienced interviewers hear as "has done this":
- Asking "when does the label arrive?" before designing anything — fraud labels come in weeks, churn in months, click labels in seconds.
- Saying "event time, not processing time" unprompted when a streaming feature comes up.
- Distinguishing a backfill (recompute history with a new definition) from a replay (reprocess the same definition after a bug), and knowing each needs to be idempotent.
- Treating the training set as a versioned artifact with a hash, not a query that "should give the same result".
- Quoting a latency budget end to end — "the model has 50 ms, feature retrieval gets 10 of that" — instead of "low latency".
- Naming the reconciliation job that compares logged online features to recomputed offline ones, and what threshold pages someone.
How candidates lose
- Modelling instead of plumbing. Spending ten minutes on which algorithm to use. Nobody asked; the round is about data.
- Tools before requirements. "Feast on Redis with Spark" in the first minute, before anyone has said how fresh the features need to be.
- A single path. Drawing training and never drawing serving — or the reverse — and being surprised when the interviewer asks how they agree.
- Timestamps as an afterthought. A training-set join with no "as of" — the leakage bug, live on the whiteboard.
- No numbers. "It scales" without an events-per-second, a feature count, or a p99.
- Cargo-culting the feature store. Recommending one for a team with three batch models and no online serving.
Avoid those and run the method. Next: the five moves that structure every ML data design question — 02 · The Method.
✓ Check yourself
Answer from memory before opening each one.
-
The recruiter says the design round is a generic "design a data platform" prompt. What do you do in the requirements phase, and why?
Show answer
Pick the highest-stakes ML consumer and design for its freshness and correctness bar, then let BI and reporting ride along. A generic prompt is scored the same way as an ML one, so you supply the ML consumer yourself. See how the loop is structured.
-
Two candidates draw the same offline and online paths. One opens with "when does the label arrive?" and the other draws first and learns about label delay when asked. Which level boundary separates them, and what is the through-line?
Show answer
The boundary is L2 to L3, and the through-line is proactivity about correctness. The L2 candidate has shipped the happy path and finds leakage, skew and backfill issues only when prompted. The L3 candidate designs around those failures from the first minute. See the levelling model.
-
A team has three nightly batch models and no online serving. A candidate proposes a feature store backed by Flink. How does a grader read that, and what does a staff-level answer say instead?
Show answer
It reads as cargo-culting: tools chosen before requirements, for a problem the team does not have. The staff answer says you do not need a feature store yet and describes what to do instead, for example versioned feature tables with strict point-in-time joins. See how candidates lose.
-
Compare the prep you would do for an ML Platform Engineer loop with the prep for a Staff DE on an MLOps team. Where do the probes differ?
Show answer
The platform loop leans on multiple consumers: contracts, tenancy, self-serve use and cost allocation. The MLOps loop leans on the whole data, train, deploy, monitor cycle: lineage, validation gates, drift, and incident stories, so have two data-broke-the-model stories ready. The accountability is the same; the weighting is not. See three titles, one job.
-
A bug in a feature definition is found after three months. Describe the difference between a backfill and a replay in this situation, and the property both need.
Show answer
Fixing the definition and recomputing the three months is a backfill: recompute history with a new definition. Reprocessing the same events with unchanged logic, for example after a crashed job, is a replay. Both must be idempotent, so that running them twice leaves the same result and no duplicated rows. See tells of seniority.
Takeaway
- The role owns the data contract between the business and its models: training data, feature infrastructure, labels, serving-side data, and the operation of all four.
- The job is the same under ML Platform, Applied ML DE and MLOps titles. The title changes which probes you get, not what you are accountable for.
- One system-design round decides the loop. Ask the recruiter which round it is, and steer a generic prompt toward its highest-stakes ML consumer.
- Graders reward raising time correctness unprompted, numbers, two paths with one definition, defended forks, operability and cost, and knowing what not to build.
- Senior offers turn on the L2 to L3 boundary, which is proactivity about correctness. Staff offers turn on L3 to L4, which is designing for people you do not manage.
- Candidates lose by modelling instead of plumbing, naming tools before requirements, drawing one path, adding timestamps late, skipping numbers, and recommending a feature store for three batch models.
Every one of those failures is cured by a fixed order of work. → The Method