How to assess · For hiring teams
How to Assess Data Engineering Skills When Hiring
The test formats that actually work for Data Engineering, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.
The short answer
Assess Data Engineering with a task, not a conversation: design a pipeline with awkward requirements, debug a wrong number, ai-scored assessment (e.g. cohesyve) or modelling exercise. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.
- Designs pipelines that are idempotent, so a retry or backfill never duplicates or corrupts data
- Handles late, missing and malformed data explicitly rather than assuming clean inputs
- Models data at a deliberate grain and can explain what each table means and what one row represents
- Builds in data-quality checks and knows which failures should stop a pipeline and which should warn
Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.
Data engineering is where an organisation's data either becomes trustworthy or quietly does not. The job is pipelines that run every day without anyone watching, schemas that survive upstream changes, and data that arrives complete, on time and correct. None of that is visible in a conversation about tools. It shows when a candidate is asked to design a pipeline that must handle late data, or to diagnose why yesterday's numbers are wrong. This page covers how to assess data engineering for platform and analytics engineering roles: pipeline design, data modelling, reliability, data quality, and the operational judgement that keeps data trusted.
Why Data Engineering is worth testing
Bad data engineering is expensive and slow to surface. A pipeline that silently drops late records skews every report downstream; a model with the wrong grain double-counts revenue; a job with no idempotency duplicates data on every retry. By the time anyone notices, decisions have been made on wrong numbers. Testing shows whether a candidate designs for the failures that actually happen, and that predicts whether the data platform is an asset or a liability.
What strong Data Engineering looks like
- Designs pipelines that are idempotent, so a retry or backfill never duplicates or corrupts data
- Handles late, missing and malformed data explicitly rather than assuming clean inputs
- Models data at a deliberate grain and can explain what each table means and what one row represents
- Builds in data-quality checks and knows which failures should stop a pipeline and which should warn
- Chooses batch or streaming based on requirements, not fashion
- Makes pipelines observable: freshness, volume, and failure are monitored and alerted
- Optimises for cost and performance where it matters and can explain partitioning and file layout
Ways to assess Data Engineering
Design a pipeline with awkward requirements
Describe a source that delivers daily files with occasional late arrivals and duplicates, a target warehouse, and a requirement for accurate daily revenue. Ask for the pipeline design, handling of the awkward cases, and the checks. Sixty minutes.
Pros
Cons
Best for Mid and senior data engineers.
Debug a wrong number
Provide a small pipeline and a report where revenue is 8% too high. Ask the candidate to find the cause — a join that fans out, a retry that duplicated — and fix it.
Pros
Cons
Best for Any level; scale via subtlety.
AI-scored assessment (e.g. Cohesyve)
Generate a data engineering scenario from the job description — a pipeline design, a data-quality incident, a modelling question — with a rubric. Each candidate receives a different variant; reasoning is scored in writing.
Pros
Cons
Best for Screening a pool before technical rounds.
Modelling exercise
Give a business domain and ask for the warehouse tables, their grain and keys, and how a change in a dimension is handled over time.
Pros
Cons
Best for Analytics engineers and warehouse-focused roles.
Cohesyve
Run a Data Engineering assessment on your next opening
Cohesyve generates a unique Data Engineering task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.
What to test
Pipeline design and reliability
Whether pipelines survive real conditions.
Data modelling
Whether tables mean something and stay correct.
Data quality and observability
Whether problems are caught before users see them.
Performance and cost
Whether the platform is efficient.
Sample Data Engineering questions
What does it mean for a pipeline to be idempotent, and why does it matter?
EntryLook for Running twice gives the same result; retries and backfills are safe; discusses merge or delete-and-insert by partition.
Yesterday's revenue is 8% higher than the source system shows. Where do you look?
MidLook for Joins that fan out, duplicated loads, timezone and date boundaries, late data counted twice; validates against source.
Design a daily load that handles records arriving up to three days late.
MidLook for Reprocess a trailing window by partition, idempotent writes, watermarks, and what downstream sees during reprocessing.
When would you choose streaming over batch?
MidLook for Latency requirements that batch cannot meet; acknowledges cost and complexity; most analytics needs are batch.
A dimension attribute changes and history must be preserved. How do you model it?
SeniorLook for Slowly changing dimension with effective dates or versioning, surrogate keys, and how facts reference the right version.
Red flags
- Cannot explain idempotency
- Assumes source data is clean
- Cannot state the grain of a table they built
- Has no monitoring beyond "the job succeeded"
- Chooses streaming without a latency requirement
Scoring rubric
| Criterion | Weight | What strong looks like |
|---|---|---|
| Reliability design | 30% | Idempotent, handles late and bad data, safe to retry. |
| Modelling | 25% | Deliberate grain, correct keys, history handled. |
| Data quality | 20% | Checks exist and are calibrated. |
| Diagnostic method | 15% | Finds the cause of a wrong number systematically. |
| Efficiency | 10% | Partitioning, formats and cost are considered. |
Mistakes hiring teams make
- Testing tool trivia (Airflow syntax, Spark APIs) instead of design
- Not including a wrong-number diagnosis — the daily job
- Accepting a pipeline design with no retry story
- Skipping modelling because the role is "pipelines"
- Confusing familiarity with a stack for engineering judgement
Roles that need Data Engineering
Common questions
Should I test a specific orchestration or processing tool?
Only if the role requires it. Idempotency, grain, late data and quality checks are tool-independent and are where the judgement lives.
What is the best single data engineering question?
Ask them to design a daily load for a source with late arrivals and duplicates. It covers idempotency, windows and quality in one answer.
How is analytics engineering different from data engineering?
Analytics engineers focus on modelling and transformation in the warehouse; data engineers on ingestion, infrastructure and reliability. Assess accordingly, though the fundamentals overlap.
How long should a data engineering assessment take?
Sixty minutes for a design exercise; two hours capped for a small hands-on pipeline.
Cohesyve · Skill assessments for hiring
Test Data Engineering before the first interview
Generate a role-specific Data Engineering assessment from your job description and see who can do the work before you spend interview time on them.
1,500+
assessments completed
50%
faster time-to-hire
90%
completion rate
5 min
from JD to assessment
No credit card · 10 free candidates · Plans sized to your hiring volume
From the blog