Skills assessment
Data Engineer skills assessment
A data engineer's CV tells you which tools they have touched; it cannot tell you whether the numbers arriving in your warehouse are correct. Two candidates listing the same stack can differ enormously in how they reason about grain, idempotency, and where a bad value could have entered. A weak data engineer fails quietly — a nightly job double-counts on a retry, a metric drifts, and analysts slowly stop trusting the numbers. Screening on keywords and pedigree misses exactly the judgement that prevents that.
The goal is not a whiteboard SQL puzzle. It is a job-relevant sample of the real work: reconciling two sources that disagree, catching a data-quality trap in a dirty dataset, reasoning about a pipeline that must survive a reprocessed batch. H-Evaluate generates that assessment from your job description — per-job generation, so no candidate has rehearsed the questions — and scores every candidate against the same rubric.
What to assess
The competencies that predict performance in this role, mapped to the five hiring pillars.
Pipeline & querying in a live environment
Designing or debugging a real pipeline and writing SQL against a messy dataset — joining, filtering, and reasoning about idempotency — rather than answering trivia about syntax in the abstract.
Data modelling & SQL depth
Fluent, idiomatic SQL and modelling judgement — when to normalise, when to denormalise, and how to design a schema that stays honest about grain as requirements change.
Data-quality reasoning
The reflex to ask 'how would I know if this were wrong?' before trusting a result — spotting duplicate keys, timezone shifts, and silent drift, and reasoning about lineage from a number back to its origin.
Judgement under ambiguity
How a candidate handles realistic scenarios — a metric that silently dropped overnight, a backfill that must not corrupt history, a stakeholder wanting a shortcut that breaks lineage.
Collaboration with data consumers
How they explain trade-offs, admit what they do not know, and partner with the analysts and scientists who depend on the data they expose and would misuse a badly modelled schema.
AI fluency
Using AI assistants to scaffold transforms and SQL, but verifying the output — catching the plausible-but-wrong query that quietly double-counts before it reaches the warehouse.
How to structure the assessment
- 1Favour a role-specific work sample — reconcile two disagreeing sources, or debug a pipeline that produces subtly wrong numbers — over a whiteboard SQL puzzle.
- 2Build a data-quality trap into the sample on purpose: a duplicate key after a retry, a timezone shift, a silently changed enum, and see who catches it unprompted.
- 3Set difficulty and weighting to the level — a greenfield warehouse build and a mature-platform maintainer are different hires.
- 4Give candidates the tools they would use on the job, including AI assistants, and assess whether they verify the output.
- 5Score every candidate against the same rubric so grain, lineage, and quality reasoning are compared, not just whether the final query runs.
Signals that predict success
- +Interrogates the data before trusting it — checks counts, nulls, and grain unprompted
- +Reasons out loud about idempotency and what happens on a retry or backfill
- +Can trace a number end to end and explain why it is trustworthy
- +Uses AI tools but verifies their SQL and can say exactly why the output was wrong
Red flags to watch for
- –Accepts data or AI output at face value and jumps straight to writing queries
- –Treats pipelines as scripts — no thought for reruns, tests, or rollback
- –Lists tools fluently but cannot reason about grain or lineage
- –Confidently ships a query with a silent double-count and does not notice
Assessment vs. interview
An interview rewards a confident narrative about past pipelines; it rarely reveals whether someone actually interrogates a dataset before trusting it. A work sample shows it directly — you watch them catch the data-quality trap, or fail to. Use the assessment to gather that evidence, then use the interview for what a sample cannot easily show: how they reason about trade-offs, handle being wrong, and partner with the analysts who depend on them.
Skills assessment
Configure this assessment by role and seniority
Watch the emphasis shift in real time as you change the role and level — no signup.
Related reading
How to hire a data engineer: a skills-first guide for 2026
How to hire a data engineer without being fooled by a polished CV — a skills-first guide to work samples, pipelines, data-quality traps, and AI fluency.
Work Sample Tests: The Most Predictive Way to Hire
Work sample tests measure what a candidate can actually do and predict job performance better than résumés or interviews. How to design and score them well.
Domain skills assessment: can they do the job?
A domain skills assessment measures the work itself, not a proxy. How per-role, systematically generated questions test real job skill fairly across candidates.
Frequently asked questions
How do you assess a data engineer?
Give them the real work: a role-specific sample where they design or debug a pipeline, model a messy dataset, or catch a data-quality trap. Watch how they reason about schema, idempotency, and edge cases — not just whether the final answer is right. Reconciling two sources that disagree tells you far more than a whiteboard SQL puzzle or a keyword-matched CV.
What skills should a data engineer test cover?
Fluent SQL and genuine software-engineering discipline first, then data modelling, pipeline reliability and idempotency, and an almost obsessive instinct for data quality. Weight lineage reasoning heavily — someone who can tell you where a number came from and why you can trust it. Tool familiarity such as Spark, dbt, or Airflow matters less and is learnable on the job.
Is a SQL test enough to hire a data engineer?
No. SQL fluency is necessary but not sufficient. The harder, more predictive skill is data-quality judgement: noticing a duplicate key after a retry, questioning a metric that drifted, reasoning about grain. Assess both, and grade whether the candidate interrogates the data before trusting it, not just whether the query runs.
How do you test whether a data engineer uses AI well?
Run the assessment in an environment where AI assistants are actually available and watch how the candidate uses them. The risk is not that they use AI — it is that they trust it uncritically and ship a plausible-looking query that quietly double-counts. Weight discernment: can they catch the wrong output before it reaches the warehouse?