Data Engineer interview scorecard template
A structured scorecard for interviewing a Data Engineer: six weighted competencies, what a 1 and a 5 actually look like, and questions that surface evidence instead of opinions. Print it, or copy it into your ATS.
The Data Engineer scorecard
| Competency | Weight | Score 1 — what it looks like | Score 5 — what it looks like |
|---|---|---|---|
| Pipeline reliability and recovery What happens when a scheduled job fails at night, which determines whether the business finds out from an alert or from a wrong report. | 20% | Reruns failed jobs manually in the morning and cannot say how a partial load is prevented from being read as complete. | Describes idempotent reruns, how partial output is quarantined, the alert that fires, and a failure caught before any consumer saw the data. |
| Data modeling for downstream consumers Whether tables are designed around the questions people ask, or mirror whatever shape the source system happened to produce. | 18% | Copies source tables into the warehouse unchanged and leaves every join and business rule to each analyst who queries them. | Explains the grain of a table they designed, why they denormalized where they did, and the reporting confusion that modeling choice removed. |
| Data quality checks and contracts Whether bad data is stopped at the boundary with tests, or discovered weeks later by whoever built a dashboard on top of it. | 18% | Relies on downstream users to report anomalies and describes quality as a shared responsibility with no test in the pipeline. | Names the checks that block a load — row counts, nulls, referential breaks — and a silent corruption those tests caught upstream. |
| Schema evolution without breaking consumers How a column change or a backfill is rolled out, which decides whether an upstream change quietly breaks reports across the company. | 16% | Changes schemas in place and finds out about breakage when someone reports that a dashboard is empty. | Describes versioning or a dual-write window, how consumers were notified, and a backfill they ran without producing double-counted rows. |
| Processing cost and performance Whether the candidate knows what their jobs cost to run and can reduce it, since warehouse spend grows silently until someone reads the bill. | 16% | Has no idea what a pipeline costs per run and treats slow queries as a platform problem to be solved with more compute. | Names a job they made cheaper or faster, the change — partitioning, incremental load, file layout — and the before-and-after number. |
| Orchestration and dependency management Whether job dependencies are explicit and recoverable, or held together by scheduled times that happen to line up most days. | 12% | Chains jobs by starting them at fixed times and treats a late upstream load as bad luck when the downstream job reads stale data. | Describes declared dependencies, what happens when an upstream task is late, and a dependency bug they found before it corrupted a report. |
Weights sum to 100. Agree them before the first interview, not after — adjusting weights once you have scores is how a panel rationalises a favourite.
Questions that surface evidence
Each one asks for something that already happened, in enough detail to verify. Hypotheticals reward rehearsal, not track record.
- Tell me about a pipeline that failed in production. How did you find out, what did the consumers see, and what did you change so it could not repeat?
- Describe a table you designed. What is its grain, why did you model it that way, and what reporting problem did that choice solve?
- What quality check of yours has blocked a load? What was wrong with the data, and what would have happened if the check had not been there?
- Walk me through a schema change or backfill you shipped. How did you avoid double counting, and how did downstream consumers find out?
- Which job did you make cheaper or faster? What did it cost or take before, what did you change, and what was it afterward?
Red flags
- Has never had a pipeline deliver wrong data to a consumer, in any job, in any year.
- Cannot name who uses the tables they built or what decisions those tables support.
- Lists platforms and tools fluently but cannot explain the grain of a table they designed.
- Treats data quality as the responsibility of whoever produces the source system.
How to use this scorecard
- Agree the weights with the panel before anyone interviews, and write them down.
- Every interviewer scores every competency independently, adding a note that quotes what the candidate actually said.
- Compare scores before discussing them. Discussing first anchors the panel on whoever speaks loudest.
Build a custom scorecard → · Boolean string to source a Data Engineer →
Frequently asked questions
What should a data engineer interview scorecard include?
Weighted competencies that reflect what breaks in production: pipeline reliability and recovery, data modeling for consumers, quality checks and contracts, schema evolution, processing cost, and orchestration. Weight reliability and modeling highest, because a pipeline that fails silently costs more than one that is slow. Anchors keep the score attached to what a candidate actually built rather than the stack they can name.
What is the difference between a data engineer and a data analyst in hiring?
A data engineer is accountable for the data arriving correct, on time and at a known cost; an analyst is accountable for what the data means. They fail differently — a bad pipeline delivers wrong numbers everywhere, a bad analysis misleads one decision. Score them on different competencies, and be explicit about which failure you are hiring against.
How do you evaluate a data engineer without a take-home project?
Ask what went wrong and what it cost. A failed pipeline and how consumers found out, a backfill that risked double counting, a job they made cheaper with the before-and-after number. Engineers who ran production systems answer with specifics; those who only built things in a course move to describing tools instead.
When the stakes are a real hire, use evidence
These tools are quick heuristics. Verdict reads the CV against your job description and scores six dimensions with verbatim quotes as evidence — a hiring document you can defend.