How to Pass a Data Engineering Take-Home Assignment
A data engineering take-home assignment is not a test of whether you can build the thing. Almost every candidate who reaches this stage can build the thing.
It’s a test of judgment under constraint. The reviewer opens your repository with maybe twenty minutes to spend, and they’re answering one question: would I want this person’s decisions on my team?
That reframing explains the strangest pattern in take-home outcomes experienced engineers fail these more often than they should, and they fail for the opposite reason juniors do. Juniors under-deliver on the unglamorous parts. Senior candidates over-build, spend eighteen hours, and submit something that signals poor prioritization rather than deep skill.
Key Points
- Scope discipline is graded more heavily than technical ambition.
- The README is the deliverable; unread code scores nothing.
- Stating what you deliberately skipped scores better than silently skipping it.
- Handling bad input data is the most commonly missed requirement.
- If a follow-up call exists, build only what you can defend in depth.
Quick summary: Reviewers are reading for reasoning, not cleverness. A simple solution with clear documentation, sensible error handling, and an honest tradeoffs section beats an elaborate one they can’t evaluate in the time they have.
Key takeaway: Decide your scope before you write code, timebox it, and spend the last hour on the README. That sequence wins more take-homes than any technical decision inside it.
Quick promise: This guide covers what reviewers actually grade, how to scope the work, what to include and skip, how to write a README that gets read, how to handle the follow-up conversation, and when a take-home is unreasonable enough to decline.
What’s Actually Being Graded
1. The reviewer’s twenty minutes
Your submission is being reviewed by an engineer who has their own deliverables this week. They clone the repo, open the README, try to run it, skim the structure, read a file or two closely, and form an opinion.
That’s the whole process at most companies. Which means anything requiring effort to discover doesn’t count. Elegant handling of an edge case, buried in a file nobody opens, contributes nothing to your score.
One engineer who reviews these regularly put it well: the submitted task reflects a candidate’s thinking more directly than a résumé or profile does. It’s unmediated evidence which cuts both ways.
2. The real question
Reviewers are calibrating four things:
- Judgment. Did you build what was asked, or what you found interesting?
- Production instincts. Does it handle failure, bad data, and reruns?
- Communication. Can you explain a decision in writing?
- Standards. Tests, structure, naming, version control hygiene.
Notice that raw technical ability appears in none of them directly. It’s assumed. You’re being assessed on everything that surrounds it.
3. Why experienced candidates over-build
If you’ve been doing this for a decade, a simple prompt feels like an insult. You know how to do it properly, so you do it properly: orchestration, streaming, a containerized stack, a dashboard, the works.
The reviewer sees something different. They asked for a pipeline that loads three CSVs and computes a metric, and they received a system they can’t run without reading configuration for twenty minutes. The signal they take is not “this person is skilled” it’s “this person doesn’t scope, and I’ll have to manage that.”
Scope discipline is the senior signal. Building less than you could, deliberately, and explaining why, is the strongest thing you can demonstrate.
Before You Write Any Code
4. Read the prompt for the rubric
Most prompts state their grading criteria, and most candidates skim past it. Phrases like “we care about code quality,” “we’re interested in your approach,” or “explain your assumptions” are not filler. They’re the rubric.
Make a literal checklist of every requirement in the prompt. At the end, verify each one. A surprising number of rejections come from candidates who built something impressive and missed a stated requirement.
Note the stated time expectation too. “This should take about four hours” is both a permission and a constraint you may stop at four hours, and going far past it will show.
5. Ask clarifying questions
You’re allowed to email the recruiter with questions, and doing it well scores points before you write a line.
Good questions are specific: “The data contains duplicate order IDs with different timestamps, should I treat the latest as authoritative, or is that part of what you want me to decide?” That demonstrates you’ve examined the data and are thinking about correctness.
If you get no answer, document the assumption in your README instead. Either way, ambiguity gets addressed rather than guessed at silently.
6. Set a time budget before you start
Decide your total hours in advance and split them roughly:
- 15% – reading the prompt, exploring the data, planning
- 55% – building the core requirements
- 15% – tests and error handling
- 15% – README and cleanup
That last 30% is what most people sacrifice when they run late, and it’s the 30% the reviewer sees first. Protect it by building less, not by documenting less.
What to Include and What to Skip
| Include | Skip |
| Working code that runs from clean setup instructions | Orchestration tooling unless requested |
| Handling for malformed, missing, and duplicate records | Streaming when the prompt describes batch |
| Idempotency reruns don’t duplicate data | A UI or dashboard nobody asked for |
| A few meaningful tests, including one for bad input | Cloud deployment |
| Clear project structure and readable naming | Premature optimization for scale not in the prompt |
| Logging that shows what happened | Multiple alternative implementations |
| A README with reasoning | Custom frameworks or abstractions |
Two things deserve emphasis.
Bad data handling is the most commonly missed requirement. Take-home datasets almost always contain deliberate problems nulls where they shouldn’t be, duplicate keys, inconsistent date formats, a malformed row somewhere in the middle. These are planted. A submission that crashes on row 4,000 has failed the actual test, regardless of how good the first 3,999 rows looked.
Before writing any pipeline code, profile the data. Look for nulls, duplicates, type inconsistencies, and outliers. What you find is usually a map of what’s being tested.
Idempotency is the senior signal. Run your solution twice. If the output doubles, you’ve demonstrated that you don’t think about reruns which in data engineering is a substantial mark against you.
Say what you skipped
Here’s the move that separates strong submissions: deliberately omit things and state that you omitted them.
“I’ve implemented this as a batch process. If this needed sub-minute freshness I’d move to a streaming ingestion with Kafka, but the requirements describe daily reporting, so batch is simpler and cheaper to operate.”
That single sentence demonstrates you know streaming, you understand the tradeoff, and you chose appropriately. It scores higher than actually building the streaming version, and it costs three minutes instead of six hours.
The README Is the Deliverable
Your README is the first thing opened and the main thing your evaluation is based on. Treat it as the product and the code as its supporting evidence.
A structure that works:
1. What this does – two sentences, plain language.
2. How to run it – exact commands, from a clean checkout. Test this on a fresh clone; setup instructions that don’t work are a fatal error, because the reviewer stops there.
3. Approach – a short walkthrough of the pipeline stages and why they’re arranged that way.
4. Assumptions – every ambiguity in the prompt and how you resolved it. This is where you convert guesswork into demonstrated thinking.
5. Data quality findings – what was wrong with the input and how you handled it. This section tells the reviewer you actually looked.
6. Tradeoffs and what I’d do with more time – the highest-scoring section in the whole submission.
That last one deserves its own paragraph. It’s where you show the judgment that the code alone can’t convey: what you deliberately left out, what you’d add for production, where the solution would break at ten times the volume, and what you’d monitor. Reviewers read this section closely because it’s the closest thing to a design conversation they get before meeting you.
If you want the fuller version of presenting technical work, structuring a repository so it gets read applies directly here.
The Follow-Up Conversation
Many take-homes are followed by a review call. This changes your building strategy in one important way: never submit something you can’t explain in depth.
Copying a pattern you don’t fully understand is the fastest route to failing the follow-up, and the follow-up carries more weight than the code.
Prepare three depths of explanation, the same way you would for explaining any pipeline in an interview:
- One sentence: what it does.
- Five minutes: the architecture, stage by stage.
- Deep: why each decision, and what the alternatives were.
Questions you should expect:
- Why did you choose this structure over the obvious alternative?
- What happens if the input file doubles in size? Or grows a hundred times?
- How would you deploy and monitor this?
- What would you do differently with a week?
- Where would this break first?
Have an honest answer to the last one. Candidates who claim their solution has no weaknesses score badly; candidates who name the weakest point unprompted score well.
The Mistakes That Sink Submissions
In rough order of frequency:
It doesn’t run. Setup instructions that fail on a clean machine end the review immediately. Always test from a fresh clone in a clean environment.
It crashes on the bad rows. The dataset was seeded with problems and you didn’t look.
Over-engineering. Six hours of infrastructure for a two-hour problem.
No README, or a generated one. A default template with no reasoning tells the reviewer you didn’t consider them.
Ignoring a stated requirement. Usually because it was in the last paragraph of the prompt.
A single enormous commit. A commit history that shows incremental, logical progress reads as professional practice. One commit titled “solution” reads as a rushed job or a copied one.
No tests at all. Two or three meaningful tests are enough. Zero is a statement.
Silence about limitations. A submission that implies everything is production-ready reads as naive.
When to Push Back or Decline
An honest word about the practice itself, since not all take-homes are reasonable.
A four-to-six hour assignment is standard and defensible. Something demanding twenty-plus unpaid hours is a different matter, and it tells you something about how the company values people’s time the kind of signal worth weighing alongside the other red flags in an interview process.
You have more room than you think:
- Ask about scope. “How many hours do you expect this to take?” is a completely normal question, and the answer becomes your permission to stop.
- Negotiate the format. Offering to walk through an existing project or do a live pair session instead is often accepted, especially for senior roles.
- Timebox and disclose. “I spent four hours on this, as suggested. Here’s what I’d add next” is a legitimate and well-received submission.
- Decline when the ask is disproportionate. An unpaid multi-day assignment early in a process is a reasonable thing to walk away from.
Be alert to prompts that resemble actual production work building something oddly specific to their business with their real data. That’s uncommon, but it happens.
Essential Terms
- Idempotency: Rerunning a job produces the same result rather than duplicates.
- Data profiling: Examining a dataset for nulls, duplicates, types, and anomalies before processing.
- Dead-letter handling: Routing unprocessable records aside instead of failing the whole job.
- Unit test: A test covering one function or component in isolation.
- Data quality test: A check on the data itself completeness, uniqueness, validity.
- Reproducibility: The ability for someone else to run your code and get your results.
- Scope discipline: Deliberately limiting what you build to what was asked.
Final Thoughts
The instinct that ruins take-homes is treating them as a chance to demonstrate everything you know. The reviewer isn’t measuring the ceiling of your ability. They’re measuring how you behave when given an open-ended task and limited time which is exactly what the job is.
So build the simple thing well. Handle the messy data. Make it rerunnable. Write two or three tests. Then spend the last hour explaining your reasoning, your assumptions, and what you left out on purpose.
A modest solution with excellent reasoning beats an ambitious one nobody can evaluate. That’s true of take-homes, and it stays true for the rest of the career.
Frequently Asked Questions
How long should I actually spend?
Whatever the prompt says, plus a small buffer for documentation. If no time is stated, ask. Four to six hours is typical. Going dramatically over is visible in the submission and doesn’t help you.
Should I use a framework like Airflow or dbt?
Only if the prompt asks, or if the task genuinely warrants it. Adding orchestration to a small script makes the reviewer’s job harder and signals poor scoping. Mention in the README that you’d orchestrate it in production, and why.
Can I use AI assistance to write it?
Most companies now assume some AI use and care more about whether you understand what you submitted. The risk isn’t using it it’s submitting code you can’t defend in the follow-up call. Review every line as if you’ll be asked why it’s there, because you will.
What if I can’t finish everything?
Submit what works, and use the README to explain what’s incomplete and how you’d finish it. A working partial solution with clear reasoning beats a broken complete one. Never submit something that doesn’t run.
Should I make the repository public?
Private with reviewer access is safer, since public repositories of well-known take-homes get found by other candidates and companies notice. If the company specifies a format, follow it.
How much testing is enough?
Two to five meaningful tests: the core transformation, one edge case, and one bad-input case. Full coverage isn’t expected in a few hours, and reviewers know it. Zero tests is the only wrong answer.
What if the prompt is genuinely ambiguous?
Ask first. If you can’t get an answer, pick the interpretation you can justify and document it under assumptions. Reviewers are usually more interested in your reasoning than in which interpretation you chose.
Do take-homes actually convert to offers?
More reliably than most stages, because reaching one usually means the resume and screen have already passed. If you’re consistently losing at this stage specifically, that’s a useful diagnostic it points to execution rather than positioning, and knowing which stage is leaking tells you what to fix.
P.S. Before you submit anything, run this three-minute check. Clone your own repository into a fresh directory, follow your own README exactly as written, and run it twice. Most failed take-homes fail one of those three steps the clean clone reveals a missing file, the README reveals a step you forgot you did manually, and the second run reveals that your output doubled. Reviewers do exactly this, and they do it first.
