Gets the data into a shape a model can actually use, reliably and repeatedly.
What separates them
The best data engineering looks boring; the worst looks identical until the day something breaks.
Ask these
01
Tell me about a data quality issue that went undetected for a while. How was it eventually found, and what changed afterward?
Tests real experience with the defining failure mode of this discipline, which is silent corruption rather than a visible crash.
A strong answer
Names a specific issue, such as a schema change or a drifting join key, how it was actually discovered, and a concrete process change made afterward.
The confident failure
Describes generic data validation checks without naming a specific instance of failure or how it was actually found.
02
How do you decide which data quality checks are worth building, given you cannot check everything?
Tests prioritisation judgement rather than a reflexive habit of checking everything equally.
A strong answer
Gives concrete criteria such as how much the business relies on a given field and where past failures have come from, and names a real example of a check they chose not to build.
The confident failure
Says they validate everything at ingestion, without acknowledging any trade-off or cost involved.
03
Tell me about a pipeline you inherited that looked fine but was not. What tipped you off?
Tests diagnostic instinct that goes beyond what a dashboard happens to show.
A strong answer
Names a specific technical smell, such as unexpected nulls or a stale timestamp, and describes the concrete investigation that followed.
The confident failure
Gives a vague answer about reviewing the code carefully, with no specific detail that actually tipped them off.
04
How do you handle a situation where the business wants data faster than you can guarantee it is correct?
Tests how they negotiate the trade-off between speed and correctness, which is common and often political.
A strong answer
Describes a concrete compromise, such as delivering a flagged partial result, and how that compromise was actually communicated.
The confident failure
Says they always insist on quality first, with no account of a real negotiation or trade-off ever having been made.
What we ask when assessing for the register
Harder, and answerable only by somebody who has done the work. Published because a question that stops working when it is known was never testing anything.
01
Describe a schema or contract change from an upstream system that broke something downstream. How did you find out, and how long did it take?
Tests real experience with the most common cause of silent pipeline failure.
A strong answer
Gives specific technical detail, the detection method, the time from break to fix, and a concrete contract or check put in place afterward.
The confident failure
Describes the general risk of upstream changes without naming an actual incident or the fix that followed it.
02
How would you validate that a data transformation is correct when there is no ground truth to compare it against?
Tests genuine technical depth on a problem that has no easy or standard answer.
A strong answer
Describes concrete techniques, such as reconciling against a known total or sampling records for manual check, with a real example.
The confident failure
Says they write unit tests for the transformation logic, as the complete answer, missing that unit tests do not catch data-specific errors.
Ask these whatever the discipline
Tell me about something you built that failed in production. What broke, how did you find out, and what did you change?
What would you refuse to do on this project, and what would you tell me instead?
How would you know, three months in, that this was not working?
What is the part of your own work that you are least confident about?