The pipeline succeeded. Is the data correct?
The domain's thesis. Whether the candidate knows that a task status reports on a process and not on rows, and whether they can name the checks that would say something about the rows.
The situation behind the question
Interviewers ask this because it happened to them.
Last night every task in the DAG exited zero, inside its timeout, with no retries. The dashboard renders a full set of numbers. The on-call engineer is deciding whether there is an incident.
A strong answer
Flags
Green flags
- Says no immediately and can explain the structural reason rather than listing anecdotes.
- Treats quality as engineering: named assertions with owners and consequences, not vigilance.
- Knows that reconciliation against the source is the check with the broadest coverage and the one most often skipped.
- Can name what each check still misses, rather than presenting a test suite as proof of correctness.
Red flags
- "The pipeline succeeded so the data is correct." This is the belief the discipline exists to break, and it survives because it is right most of the time.
- Proposes re-running the pipeline as the diagnosis. A deterministic pipeline over an unchanged input returns the same wrong answer.
- Lists data tests without being able to say what any of them fails to see.
- Believes freshness monitoring covers correctness, when almost every correctness fault leaves freshness green.
Follow-ups
Where the conversation goes if the first answer holds up.
- Which single check would you build first in a platform that has none, and what would you not be able to see with only that one?
- A check fails. Should the publish be blocked, or should it publish and alert? What decides?
- Two faults trip overlapping sets of checks. How do you tell them apart, and why does the first failing check not tell you enough?