Section D · Execution

Day-Of Tactics & Your 30-60-90

The last thing to read before the loop: how to spend the minutes, how to lay out the board, the sentences that make you sound like an owner, how to recover when you take a wrong turn — and the plan you'll be asked for once the offer lands.

Timing the session

Most ML data design rounds are 45 or 60 minutes with a few minutes of intro and a few for your questions, which leaves roughly 35 or 50 minutes of design. The five moves from 02 · The Method map onto that clock. The failure pattern is spending twenty minutes on requirements and never reaching the online path, or the reverse — drawing boxes in minute two and being asked "wait, what's the label?" in minute twenty.

Move	45-minute round	60-minute round	You are done when
1 · Requirements & signal	5 min	7 min	You've said the prediction, the freshness, the latency budget, the label delay, and two estimated numbers out loud.
2 · Sources & labels	5 min	7 min	Every source has a shape and a cadence; the label has a definition and a delay; leakage is named.
3 · Offline path	8 min	12 min	Training set is point-in-time correct and versioned; features have one definition; there is a validation gate.
4 · Online path	8 min	12 min	The feature vector assembles inside the latency budget; skew is addressed; a fallback exists.
5 · Operate	5 min	7 min	Monitoring by layer, an owner per alert, reproduction from logs, cost drivers named.
Deep dives / their pulls	4 min	5 min	You've offered two forks and taken the one they chose.

The clock trick

Say the plan out loud in the first minute: "I'll spend a few minutes on requirements and the label, then the offline path, then the online path, then how we'd operate it — stop me anywhere you want depth." You've just told the interviewer you have a method, and given yourself permission to move on.

The whiteboard layout

Draw it the same way every time so your hands know the shape while your head works the problem. The layout below is what the drills in this guide all reduce to.

board-layout.txt

┌─ REQUIREMENTS ──────────────────────────────────────────────────────────────────────┐
│ predict: ___   freshness: ___   p99 budget: ___   label delay: ___   scale: ___/day │
└─────────────────────────────────────────────────────────────────────────────────────┘
 OFFLINE (top half)                                       versions: chunker/feature/model
 sources ─▶ ingest ─▶ features (PIT) ─▶ training set ─▶ gate ─▶ train ─▶ registry
    ◆ batch/stream          ◆ feature store?     ◆ dataset versioning
                                  │  one definition, both stores
 ONLINE (bottom half)             ▼
 request ─▶ online features ─▶ model ─▶ decision ─▶ log features-as-scored
               ◆ store choice          fallback: ___
 OPERATE (band across the bottom)
 contracts · freshness · drift · skew · labels   |  owner + runbook per alert  |  cost: ___

Requirements box first, always. The five blanks are what you fill from the clarifying questions; everything below points back to them.
Offline above, online below. The vertical arrow between them is the feature definition shared by both — draw it and name it; it's the training/serving skew story in one line.
◆ marks a decision. Put a diamond where a real fork lives (batch vs stream, build vs buy, store choice). Diamonds are the deep dives you've prepared in 08.
Operate is a band, not a box. Monitoring, ownership and cost span the whole system; drawing them underneath says so without a speech.
Leave the right third empty. You'll need it for a latency budget, a sizing calculation or a decision matrix when they pull a thread.

Phrases that signal seniority

The interviewer is listening for evidence you've operated one of these. These sentences carry that evidence compactly — use the ones that are true for you.

"Let me pin the label before I draw anything — it decides half the design."
"Every feature is computed as of the prediction time, not as of now."
"One definition, materialised to both stores — that's the skew story."
"I'd log the features as scored; without that, incidents are unreproducible."
"The index is a derived artifact of the table and a model version; we rebuild and cut over, never mutate."
"Let me size it — [number] — so this is a one-node problem, not a cluster problem."
"Drift tells me a layer moved; the response is fix, retrain or investigate — not automatically retrain."
"I'd default to batch and stream only what decays in minutes; I'd revisit when a measured lift pays for the ops."
"That's the boundary of this decision — if [condition] changes, I'd choose differently."
"Who owns that upstream table? The alert has to route to someone who can fix it."

The decision sentence

Given [requirement], I'd choose [option] over [alternative] because [reason]; the cost is [downside], acceptable because [context]; I'd revisit if [flip condition]. One pattern, every fork.

Recovering from a wrong turn

You will take one. Senior candidates are graded partly on how they take it back. The moves, in the order to try them:

Name it yourself before they do. "Actually, I've been computing that feature from current state — that leaks. Let me redo it as of the prediction time." Self-correction is scored higher than never erring.
Return to the requirements box. If you're lost, read the five blanks aloud and ask which one the current thread serves. It re-anchors you and looks like method, not panic.
Trade scope for depth explicitly. "I could sketch the streaming path fully or go deep on the skew detector — which is more useful to you?" Turns a time problem into a choice they own.
Update on pushback, then commit. "Fair — if freshness matters more than I assumed, that flips me to streaming for those features." Change your mind out loud, once, and then defend the new position.
When you don't know, bound it. "I haven't run Bigtable at that scale; my expectation from DynamoDB is X, and the thing I'd verify first is bulk-load cost." Honest bounds beat bluffing every time.
Silence is fine for ten seconds. Say "let me think" and think. Filling the air with tool names is the tell they're watching for.

Questions to ask them

Up-front clarifying questions are part of the score; questions at the end are how you decide whether to take the job. Keep a few of each ready.

Clarifying, in the room: what does the model predict and who acts on it; label definition and delay; freshness and latency budgets; scale per day; what exists already (warehouse, streams, a feature store, a registry); team shape and who owns the sources; regulatory constraints on the data.
For them, at the wrap: "What's the last ML incident that was really a data incident, and what changed after?" · "How many feature definitions exist for your most-used concept?" · "Can you reproduce a prediction from six months ago?" · "Where does the platform hurt most — cost, reliability, or time-to-first-model?" · "Who decides build vs buy, and how did the last one go?"

Their answers to the second list tell you which quarter of the 30-60-90 below will matter most.

Red flags to avoid

How strong engineers still lose this round

Tools before requirements. A feature store product in the first minute, before the label is defined.
No numbers. Skipping the sizing means every store choice is opinion, and it hides whether you know a small problem from a big one.
Current-state features. Any feature not explicitly "as of the prediction time" is a leak waiting to be found.
One path only. Designing the offline pipeline and forgetting how the model gets features at request time — or the reverse.
Monitoring as a dashboard. Metrics with no owner, no threshold rationale and no runbook.
Streaming everything. Reaching for Kafka and Flink for features that aggregate over weeks.
Ignoring deletes and privacy. Versioned datasets and erasure requests are in tension; not mentioning it is a miss at senior level.
Digging in. Defending a call after new information instead of updating and re-committing.

Your 30-60-90

Some loops ask for it directly; every offer conversation benefits from having it. The shape below assumes an ML data architecture role on an existing platform team; adjust the emphasis using what you learned from your wrap-up questions.

Window	Focus	Concrete outputs	The question you're answering
Days 1–30 · Map	Learn the models, the data, the people. Ship nothing structural.	An inventory: every production model, its features and where they're computed, its training-set provenance, its monitoring; a lineage sketch from sources to models; a list of the last five ML incidents with root causes; relationships with each model owner and each upstream data owner.	"Where does it actually hurt, measured — not where people say it hurts?"
Days 31–60 · Prove	One lighthouse improvement with a number attached.	Pick the worst measured pain (usually skew, reproducibility, or a duplicated feature definition) and fix it for one high-value model end to end: log features-as-scored, add the validation gate, or unify the definition. Publish the before/after. Draft the platform roadmap with the metrics you'll move.	"Can this person change the system, not just describe it?"
Days 61–90 · Generalise	Turn the lighthouse into a platform default.	The fix becomes the paved path: a feature registry with owners, the skew monitor on every model, dataset tagging tied to the registry, alert routing by layer. Agree the build-vs-buy position with leadership using the matrices in 08. Set the three metrics you'll report quarterly: time-to-first-model, feature reuse rate, data-caused incidents per model.	"What's different for every team, not just the one you helped?"

Say it in one breath

"First month I map the models, the data and the incidents and pick the worst measured pain. Second month I fix it end to end for one model that matters and publish the number. Third month I make that fix the default for everyone and set the three metrics we'll manage the platform by."

Reread the morning of

You have the method (02), five drilled designs (03–07), the matrices for every fork (08) and graded answers to the questions they actually ask (09). This page is the one to skim on the way in. When a thread goes deeper than the prep, the reference is the companion deep dive — start at ML Data Architecture · Start Here, or jump straight to the chapter behind the thread: features (04), serving (08), quality (10), cost (12).

Where to go from here

Back to the hub at the guide index, or to 00 · Start Here for the full reading order. Go get it.

✓ Check yourself

Answer from memory before opening each one.

In a 45-minute round, what must be true before you leave the offline path, and roughly how long should it have taken?

Show answer
About 8 minutes in, the training set is point-in-time correct and versioned, features have one definition, and a validation gate exists. If you cannot say all three, the move is not done, whatever the clock says. See timing the session.
On the board you draw a vertical arrow between the offline lane above and the online lane below, and name it. What does it stand for, and why draw it at all?

Show answer
It is the shared feature definition feeding both stores. Drawing it states the whole training-serving skew story in one line, instead of leaving the interviewer to ask how the two paths agree. See the whiteboard layout.
Why does the first 30 days of the plan ship nothing structural, and why must the second 30 days target the worst measured pain rather than the loudest?

Show answer
The first month builds the baseline: an inventory of models, features, provenance, monitoring and incidents. The lighthouse fix in the second month must come with a before-and-after number, and the loudest complaint is not always the worst measured problem. See your 30-60-90.
You ask a team whether they can reproduce a prediction from six months ago, and the answer is "not really". How does that change your plan?

Show answer
It points the second-month lighthouse at logging features as scored and linking each model to its dataset snapshot and code. The wrap-up questions exist so that answers like this tell you which quarter of the plan matters most. See questions to ask them and your 30-60-90.
Mid-design, the interviewer says freshness matters more than you assumed for some features. What changes in the design, and what stays the same?

Show answer
Those features whose freshness need is shorter than the batch cadence move to streaming, and the rest stay batch. You say it once and defend the new position. The consistency story is unchanged: one definition, features logged as scored, and a reconciliation job. See recovering from a wrong turn.

Takeaway

Say the plan aloud in the first minute and keep to the clock across the five moves, leaving a few minutes at the end for the interviewer's own pulls.
Draw the same board every time: a requirements box, offline above, online below, operations as a band, and a diamond at each real fork.
Phrases that signal seniority are evidence of operating a system: pin the label, compute as of the prediction time, one definition, log as scored, size it, name the flip condition.
Recover by naming the wrong turn yourself, returning to the requirements box, updating once on pushback, and bounding what you do not know.
Strong engineers lose with tools before requirements, no numbers, current-state features, one path, monitoring with no owner, and streaming everything.
The 30-60-90 is map the system, prove one fix with a number, then make that fix the default with three metrics.

For the full argument behind any thread that goes deeper than this prep, the companion guide is the reference. → ML Data Architecture