ML System Design

What is one row of your training data?

By Interview Clozo · Published 27 October 2026 · Last verified 26 October 2026 · 11 min read

One row of your training data is one labeled example: the features the model can see at prediction time, a label that records what happened, and the entity key and timestamp that tie them together. The follow-up that separates levels is what the label is when the answer has not arrived yet, because a late label is unknown, not negative.

In this article

Before you start
Why interviewers ask this
One row of training data from first principles
The Staff-level answer
The rubric
Three variants of this question
Common mistakes
Follow-up questions
Sources

Before you start

This page sits inside the machine learning (ML) system design interview guide, where the round is explained end to end.

Why interviewers ask this

A wrong row quietly ruins every later step: the model learns the wrong thing, and the metrics look fine anyway. Candidates report this question in ML design rounds at large tech companies, often phrased as "what is one row, what is the label, what are the negatives?" It usually arrives right after the objective is stated.

A weak answer lists columns: "user features, item features, a label." A strong answer says what one row represents, where its label comes from, and when each value was known. A Staff-level answer also says what the label is while the outcome is still pending, how the same features will exist at serving time, and how the data is split so the future never leaks into the past. The question is short because the answer is a whole design in miniature.

One row of training data from first principles

Training example: A training example is one record of a dataset that a model learns from, holding the input values the model sees plus, in supervised learning, the correct answer; it is the same thing as one row of a table.
Label: A label is the recorded answer for a training example, the value the model should predict, such as "fraud", "clicked" or "kilowatt hours used per year".

In plain words

Picture a spreadsheet. Each line is one case you have already seen. The first columns describe the case, and the last column holds what happened. Google's ML Crash Course says an example is "analogous to a single row in a spreadsheet". The analogy breaks in one place: a real spreadsheet cell is fixed, but a training value must be what you knew at one moment in time.

A feature is a value that a supervised model uses to predict the label. An example with both is a labeled example; an example with features only is unlabeled. At serving time you only ever have the unlabeled kind.

Step 1: Decide what one row represents

A row is one example, so the first decision is the unit: one house, one transaction, one post, or one impression of a post to one user. The sources define an example but do not tell you how to pick the unit, so this is reasoning, not a rule. Choose the unit at which you will make a prediction in production, because the model must score exactly that thing.

Google's intro exercise gives a clean case: the features are square footage, location and year built, and the label is kilowatt hours used per year. One illustrative row: 1,850 square feet, a downtown location, built in 1987, label 11,200 kilowatt hours.

In a feed or fraud system add two more columns: an entity key, such as a user or a transaction, and the event timestamp. Each row needs an entity key and an event timestamp. You now know the row's skeleton: key, time, features, label.

Step 2: The label is a decision, and a late label is unknown, not negative

The label records what happened, and deciding when and how it is known is a design choice. A negative is a row whose outcome you observed to be "no", for example a post users saw and ignored. A row whose outcome has not arrived is unknown, not negative.

Chapelle (2014) studied advertising conversions that can happen up to a month after the click. A naive method treats every click without a conversion as a negative, which creates fake negatives; the paper observes that you cannot tell a late conversion from none at all. You have three choices: wait out a maturation window, discard rows that are too young, or model the delay.

Illustrative fraud case: 100,000 transactions, 500 fraudulent, chargebacks arriving after an assumed average of 21 days. In a snapshot where every transaction is 10 days old, only 189 fraud labels exist and 311 are missing.¹ The naive recipe would call those 311 frauds "not fraud".

On an assumed 21-day average delay, 62.1% of fraud labels are still missing at day 10 and 5.7% at day 60.
Days since the transaction	Share of fraud labels still missing
7	71.7%
10	62.1%
14	51.3%
30	24.0%
60	5.7%

On an assumed 21-day average delay, most fraud labels are still missing in the first two weeks.CC BY 4.0 — source: What is one row of your training data?

Text description of the diagram

The share of fraud labels still missing is 62.1% at day 10 and 5.7% at day 60.
On an assumed 21-day average delay, most fraud labels are still missing in the first two weeks.

Step 3: Features must be values from the prediction moment

Each feature value in a row must be the value known when the prediction would have been made, not a later one. If you join today's account balance to a label from last March, the row contains the future, and your evaluation scores look better than production will ever deliver. The Feast documentation names the fix, the point-in-time join, which takes for each row the latest feature value at or before the row's timestamp.

The join also stops looking back after a limit. Feast scans backward from the row's timestamp up to a maximum set by the time to live (TTL), so a stale value is not used.

Event time is not availability time: a value backfilled or corrected later can carry an old event timestamp and still leak in. Feast's point-in-time join documentation adds a created-timestamp filter (filter_by_created_timestamp=True) so each row only sees values that were already available.

Illustrative case: a transaction labeled at 2026-03-15 14:30 may use a balance written at 14:29 on the same day. A balance written on 2026-03-16 is excluded. You now know the rule: a row's features are those of its own timestamp.

Step 4: Log what you served and split by time

Training-serving skew is a difference between how a model performs in training and how it performs in serving. The Rules of Machine Learning trace it to differences in how the two pipelines handle data, to data changing between the two, and to a feedback loop between your model and your algorithm.

The best defense in Rule #29 is to save the features used at serving time and use that log for training, so the row is what the model really saw. Serving logs only exist for features already in production, so a new feature still needs a point-in-time backfill.

Then split by time, not at random: train on rows before a date and evaluate on rows after it. A random split puts later rows in training and their near-duplicates in test, so the score borrows from the future. Keep a final window whose labels have matured, or the evaluation inherits the delay problem of Step 2.

A training row is built in four moves, and the label and feature timestamps decide whether it is honest.CC BY 4.0 — source: What is one row of your training data?

Step-by-step description

Choose the prediction unit, a key and a timestamp.
A late label is unknown, not negative.
Join values known at the timestamp.
Train on served features, split by time.

Each row needs an entity key and an event timestamp.
The label records what happened and may arrive late.
Feature values are taken as of the prediction time.
Log the features served and split train and test by time.

Knowing it is half the job. Saying it is the other half.

Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.