Cohesyve · Practice for candidates
Going for a Data Engineer role? Find out how you'd actually score.
Run a Data Engineer simulation built the same way employers build theirs, and get a full report showing exactly where you lost marks — before it counts.
5
free assessments a month
$0
no card required
Full
scored report every run
Every
question type included
5 free assessments a month · No card required · Pro from $16/mo
Overview
Data engineering assessments are built around messy inputs. You are typically given a dataset that violates its own documentation, a pipeline that silently drops records, or a model to design for a stated set of queries, and marked on whether your solution is correct when the data misbehaves. Elegant code that assumes clean input scores poorly. This page covers the formats, the marking, and how to prepare.
Why employers assess this role
Data defects are quiet. A pipeline that drops two per cent of rows or double-counts on a retry keeps running and reaches a dashboard someone makes decisions from, sometimes for months. Employers assess up front because the habits that prevent this — idempotency, explicit handling of nulls and duplicates, validation at the boundary — are habits rather than knowledge, and only show up in practical work.
What gets tested
The format
Duration
60–120 minutes
Question types
- SQL tasks against a supplied schema
- Design a pipeline or a model for a described requirement
- Debug a pipeline that produces wrong numbers
- Written reasoning about trade-offs and data quality
Levels
Entry · Mid · Senior
What you'll be asked to do
Write correct SQL against imperfect data
The most consistently present section. The supplied tables usually contain duplicates, nulls where the documentation promised none, and at least one join that fans out.
- •Produce a daily active count where the event table contains duplicate emissions
- •Attribute revenue to the correct period when timestamps arrive in mixed time zones
- •Join orders to line items without inflating the order-level totals
Model data for how it will be queried
Given the questions the business wants answered, design the tables. Grain, keys and slowly changing attributes are what get marked.
- •Design a fact and dimension model for a subscription business
- •Handle a customer attribute that changes over time without losing history
- •Choose and justify the grain of a fact table for a stated set of reports
Design a pipeline that can be re-run
The distinguishing area from mid level upwards. The naive pipeline works once and duplicates or loses data the moment it is retried or backfilled.
- •Make a daily load safe to re-run for the same date without duplicating rows
- •Handle events that arrive two days after the period they belong to
- •Decide what happens when an upstream file is delivered twice with different contents
Diagnose numbers that are wrong
You are told a figure does not reconcile and asked to find out why. The method of narrowing it down is scored as much as the answer.
- •A daily total is higher in the warehouse than in the source system
- •A metric dropped by a third overnight with no code change
- •Row counts match but a sum does not
Cohesyve for candidates
Practise a Data Engineer assessment before the real one
Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.
Sample tasks — and what strong looks like
Given an events table with duplicate emissions and an inconsistent user identifier, produce a daily count of distinct active users.
MidWhat strong looks like: Inspects the data before writing the final query, defines deduplication explicitly by a key and a timestamp, states how the identifier ambiguity was resolved, and handles days with no events rather than dropping them from the output. Weak answers apply a distinct count and never notice the identifier problem.
A nightly load is re-run after a failure and the downstream totals double. Explain the cause and redesign the load.
MidWhat strong looks like: Identifies the append-only write as the cause, replaces it with an idempotent pattern such as a partition overwrite or a merge on a natural key, and confirms that a second run produces an identical result. Weak answers delete the affected rows by hand and leave the pipeline unchanged.
Design the model for a reporting layer that must answer questions about subscriptions, plan changes and churn.
SeniorWhat strong looks like: States the grain of each table before designing it, handles plan changes as a history rather than an overwrite, defines churn precisely enough that two people would compute it identically, and names what the model deliberately does not support.
An upstream provider adds a column and changes a field from a string to a nested object without notice. Your pipeline is now failing. Decide what to do.
EntryWhat strong looks like: Separates the immediate restoration of the pipeline from the longer fix, quarantines rather than silently discards the records that cannot be parsed, and adds a validation step at the boundary so the next change is detected rather than absorbed. Weak answers coerce the field to text and move on.
How to prepare
- #1
Practise profiling a dataset before querying it, because assessors plant duplicates and nulls specifically to see who checks and who assumes.
- #2
Rehearse writing loads that are safe to re-run, since idempotency is the clearest line between an entry-level and a mid-level score.
- #3
Drill window functions and deduplication patterns until they are quick, as they appear in almost every SQL section and consume time when unfamiliar.
- #4
Get comfortable stating the grain of a table out loud before you design it, because unstated grain is the root of most weak modelling answers.
- #5
Practise reconciliation as a method — compare counts, then keys, then sums — so that a wrong-number question gets a systematic answer rather than a guess.
- #6
Run one full timed mock including the written section, as data assessments are longer than they look and the reasoning is heavily weighted.
Common mistakes
Trusting the documented schema instead of profiling the actual data first.
Writing a pipeline that appends, so any retry or backfill duplicates records.
Joining on a key that is not unique and inflating totals without noticing.
Silently dropping malformed records rather than quarantining and counting them.
Designing a model without stating its grain, then producing metrics nobody can reproduce.
Presenting a number without any check that it reconciles with the source.
How it's scored
| Criterion | What strong looks like |
|---|---|
| Correctness on messy input | Duplicates, nulls and boundary dates are handled deliberately, and the assumptions made about them are stated. |
| Idempotency | Re-running the same load for the same period produces the same result, and backfills are possible without manual cleanup. |
| Modelling judgement | The grain is explicit, keys are genuinely unique, and historical changes are preserved where the requirement needs them. |
| Data quality thinking | There are checks at the boundary, failures are visible rather than silent, and bad records are retained for inspection. |
| Communication of assumptions | Every definitional decision — what counts as active, which time zone, which date attribution — is written down rather than implied. |
Frequently Asked Questions
How much of the assessment is SQL?
Usually a substantial part, because it is the fastest way to see whether someone handles duplicates and joins correctly. Even pipeline-focused tasks tend to include at least one query where the data does not behave as documented.
Will I be tested on a specific warehouse or framework?
Sometimes, and it is normally stated. Where it is open, use what you are fastest in — the marking concentrates on correctness, grain and idempotency, which transfer across engines.
Should I write data quality checks if they are not requested?
Add at least one, such as a uniqueness or a row-count assertion. Unrequested checks are one of the cheapest ways to signal production experience, and their absence is frequently noted.
What if the requirement is ambiguous?
State the interpretation you chose and continue. Ambiguity about definitions is usually planted deliberately, and a written assumption scores far better than a silent one or a request to wait for clarification.
How can I test myself before a real assessment?
Sit a scored simulation first. Cohesyve offers five free assessments a month with a detailed report, which will tell you quickly whether you are losing marks on SQL correctness or on pipeline design.
Practise another role
Cohesyve · Practice for candidates
Practise a Data Engineer assessment now — free.
Five scored assessments a month, a full report on every run, and a learning pathway built from what you got wrong. No card required.
5
free assessments a month
$0
no card required
Full
scored report every run
Every
question type included
5 free assessments a month · No card required · Pro from $16/mo
For hiring teams
Hiring for a Data Engineer role? See how your applicants perform before you spend interview time.