A data engineering interview should test whether the candidate can trace a data problem across producers, transformations, and consumers. A query that runs successfully can still produce a misleading result.
Use a fictional packet with synthetic records and a clear consumer decision. This keeps the exercise practical without exposing company data.
Set up the fictional incident
A fictional operations dashboard suddenly shows fewer completed workflows. The application team reports no equivalent change in user behavior.
Provide a source event definition, a transformation sketch, a sample output, and a note that one upstream field recently changed. Include enough information to form hypotheses, but allow the candidate to ask for missing details.
Ask for an investigation sequence
The candidate should explain what they would inspect first and why. Useful areas include event meaning, source completeness, transformation logic, freshness, duplicate handling, and the consumer’s interpretation.
Do not require a specific vendor stack unless it is essential to the actual role.
Evaluate the response
| Area | Strong evidence |
|---|---|
| Definitions | Checks what “completed” means before changing code |
| Traceability | Follows the result back through its transformations |
| Hypotheses | Separates plausible causes and proposes discriminating checks |
| Recovery | Considers corrected history and affected consumers |
| Ownership | Identifies who can confirm or change the source contract |
| Prevention | Proposes useful checks and change communication |
Add an operational complication
Tell the candidate that a simple reprocessing job would overwrite data already used in another report. Ask how they would plan a safe correction and communicate uncertainty.
The point is not to find a single ideal answer. Look for awareness that fixing a pipeline changes what other people rely on.
Distinguish repair from prevention
An immediate patch may restore a report while leaving unclear ownership untouched. Ask what would make the same failure easier to detect and resolve next time.
Avoid rewarding a large monitoring proposal that does not explain what each check protects.
Close with a handoff
Ask for a short update to a nontechnical consumer: what is known, what is uncertain, what they should avoid concluding, and when to expect the next update.
Use the data engineer versus analyst guide and bounded work-sample guidance. Discuss a data engineering search with Refery.