Data Engineer Take-Home Tests Are Unpaid Work: Fight Back

One DE spent a full weekend building an end-to-end pipeline for a Series B startup’s data engineer take-home assignment. Ingestion layer, transformation logic, data quality checks, orchestration config, documentation. Roughly 14 hours. Submitted Sunday night. Monday morning, a form rejection. No feedback. No code review. No explanation. Three weeks later, a friend who worked there mentioned the team had shipped a pipeline that looked suspiciously similar. No proof the code was reused. Just that they kept it.

That story is years old. The pattern has gotten worse, not better.

The funnel: candidate passes a recruiter screen, passes a hiring manager chat, then gets “the assignment.” It is framed as a data engineering technical assessment to evaluate skills in a realistic setting. The prompt reads like a consulting engagement: build a data pipeline that ingests from these three sources, model the data for analytics, set up orchestration, handle error cases, write tests, document design decisions. “Should take about 4 hours.”

It never takes 4 hours. About 25% of companies still use take-home assessments lasting 2 to 8 hours. That is the claim. The reality is that time limit enforcement doesn’t work; candidates who put in more hours gain a competitive advantage, which means everyone ends up spending a weekend on it. The candidate isn’t being evaluated on a 4-hour effort. They are competing against people who spent 15.

The part nobody says out loud: the company keeps the code regardless of outcome. Every submission. Every architecture diagram. Every data model. Win or lose, they have the work.

The data engineer interview process in 2026 exists in a weird space. The market has shifted hard. Candidate-to-job ratios dropped from 10 candidates per open role to roughly 2.5. That should mean companies are competing for candidates. In some ways, they are. In other ways, they are squeezing harder because every hire matters more.

Enterprise time-to-hire for data engineers sits at 60 to 90 days. Not because companies are being thorough. Because they have stacked the process with multiple rounds, each one extracting more uncompensated work. The take-home is the most egregious layer, but rarely the only one. A loop might also include a system design round, a SQL assessment, a behavioral panel, and a “meet the team” that is actually another technical evaluation.

AI has made the take-home even more pointless as an evaluation tool. Take-home projects only show the candidate’s final output; interviewers have zero visibility into the candidate’s actual process. Did they struggle with the data modeling and work through it? Did they paste the whole thing into an LLM? Can’t tell. The hiring signal from take-home projects is degrading fastest under AI. Live interviews are more valuable now because they reveal how someone thinks and how they use tools in real time.

So the assessment doesn’t even do what it claims to do. It doesn’t reliably evaluate skill. What it does reliably produce is free, production-usable pipeline code.

Not every take-home is exploitative. Some are genuinely well-designed. The red flags are obvious from either side of the hiring table once they are named.

The assignment uses their actual data

A legitimate assessment uses synthetic data or a public dataset. When the company is handing over credentials to their staging environment, their real schemas, or sample data that is clearly from production, that is not an assessment. That is a work order. The candidate is solving their actual problem for free.

The scope is production-grade

When the prompt asks for error handling, retry logic, monitoring, documentation, and tests on top of the core pipeline, that is not a skills evaluation. That is a deliverable. A real assessment tests whether the candidate understands the concepts; it doesn’t need to be deployable. When the company wants it deployable, they intend to deploy it.

There's no defined rubric

Ask what the evaluation criteria are. If the recruiter can’t tell, or gives vague nonsense like “we want to see how you think,” that is a flag. A company that has built a fair process has a rubric. A company fishing for free work doesn’t need one because nobody is actually scoring the work.

The timeline is “flexible”

“Take as long as you need” sounds generous. It is not. It is an invitation to over-invest. Legitimate assessments are time-boxed because the company respects the candidate’s time. Flexible timelines are a feature of processes that benefit from candidates spending more hours.

No one reviews it with the candidate

The biggest tell. When submission is followed by a rejection (or silence), the company got what they wanted. A real evaluation includes a walkthrough where the candidate discusses their decisions. That is where the signal actually lives. Skipping that step means the code was the point, not the conversation.

A fair data engineering technical assessment has constraints that protect the candidate.

Time-boxed to 2 to 3 hours, maximum. Not “we recommend 3 hours but take your time.” Hard cap. When a company can’t evaluate a data engineer in 3 hours, the assessment is bad, not the candidate.

Scoped to a single concept. Data modeling. Pipeline architecture. SQL optimization. Not all three plus tests plus docs plus a presentation. One thing tested well, not everything tested poorly.

Uses synthetic or public data. A reasonable prompt looks like:

-- Assessment: Model this e-commerce event stream for analytics
-- Time limit: 2 hours
-- Dataset: Provided CSV with synthetic order events
-- Deliverable: SQL DDL for your proposed schema + 3 sample queries

-- Example: one of the three queries might be
-- "Calculate 7-day rolling revenue by product category"

SELECT
    order_date,
    product_category,
    SUM(order_total) OVER (
        PARTITION BY product_category
        ORDER BY order_date
        ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
    ) AS rolling_7d_revenue
FROM daily_category_totals
ORDER BY product_category, order_date;

That query tests understanding of window functions, aggregation, and how to think about time-series analytics. It doesn’t produce anything the company can ship. That is the whole point.

Includes a review session. The 30-minute walkthrough after submission is where signal actually surfaces. Why was that grain chosen? What tradeoffs were considered? How would the candidate handle late-arriving data? The conversation tells a hiring manager more than 20 hours of unsupervised coding ever could.

The economics make the situation unambiguous.

A mid-level data engineer’s hourly rate (based on current DE salary data) is roughly $75 to $95/hour, all-in with benefits. Senior or staff engineers exceed $100. When a company assigns a 10-hour take-home to 20 candidates for one open role:

# The real cost of "free" take-home assessments
candidates = 20
hours_per_assessment = 10  # "should take 4 hours" (actual time)
hourly_rate = 85  # mid-level DE, conservative

total_candidate_hours = candidates * hours_per_assessment  # 200 hours
market_value = total_candidate_hours * hourly_rate  # $17,000

# What the company gets:
# - 20 different approaches to their actual pipeline problem
# - Production-grade code samples they retain
# - Architecture decisions from experienced engineers
# - Zero dollars paid

print(f"Free labor extracted: {total_candidate_hours} hours")
print(f"Market value: ${market_value:,}")

Two hundred hours of engineering work. Seventeen thousand dollars in market-rate labor. For free. That is one role. Multiplied across every open DE position at a company with 5 to 10 open headcount, the figure runs into six figures of unpaid data engineer work samples per quarter.

The candidates who don’t get the job aren’t “gaining interview experience.” They are donating consulting work to a company that will ghost them.

Top candidates with multiple offers already refuse take-home assessments when they can engage in less time-consuming processes. “No thanks” isn’t always an option when the candidate needs the job. The scope of the assignment can still be negotiated without torpedoing candidacy.

Ask for the rubric first

Before writing a line of code, email the recruiter: “Could you share the evaluation rubric so I can focus my time on what matters most to your team?” If they have one, great. If they don’t, the absence is its own data point.

Propose a time-boxed alternative

“I’d love to demonstrate my skills. Would your team be open to a 90-minute live session where I work through a similar problem? I find that gives both sides a better signal than async work.” Hard to refuse without admitting the company wants more than 90 minutes for free.

Set a boundary and communicate it

“I’ll be investing 3 hours in this assessment, which I think is sufficient to demonstrate my approach to pipeline architecture and data modeling. I’ll document what I’d do differently with more time.” Reframes the constraint as professionalism, not laziness.

Ask about IP

The nuclear option, used selectively: “Does your company retain candidate submissions, or are they deleted after evaluation?” Watch how they respond. A company with clean intentions will say they delete. A company that pauses or hedges just told the candidate everything.

When the assessment goes ahead, protect the work that ships to the company.

-- Add this header to every file you submit

-- CONFIDENTIAL CANDIDATE SUBMISSION
-- Author: [Your Name]
-- Date: [Submission Date]
-- Purpose: Technical assessment for [Company], [Role]
-- License: This work is submitted for evaluation purposes only.
-- Redistribution, modification, or production use without
-- written consent of the author is prohibited.
-- All intellectual property rights retained by author.

Will the header hold up in court? Maybe, maybe not. It establishes intent and creates a paper trail. It also signals to the hiring team that the candidate is not naive about what is happening. Companies acting in good faith won’t blink. Companies that planned to use the code will.

Also: keep the submission. Screenshot the email. Save the prompt. If the pipeline design shows up in their repo six months later, receipts matter.

Companies running bloated assessments don’t realize the candidates they actually want to hire aren’t completing them. With 2.5 candidates per open DE role (down from 10), the power dynamic has shifted. Senior and staff engineers with options simply don’t respond to assessment invites from companies they aren’t already excited about. They go to the company that does a 45-minute live technical interview instead.

That leaves companies relying on take-homes in a slow-motion hiring crisis. They are selecting for candidates who are either desperate enough to donate 15 hours or junior enough to not know the difference. Neither of those is the person building the pipeline that finance depends on for board decks.

The data engineering market isn’t shrinking. The role is expanding as companies realize they need people who can actually build and maintain data infrastructure, not just spin up dashboards. The interview process at a lot of these companies is stuck in 2022, when they could afford to waste candidate time because there were 10 people in line behind every candidate.

There aren’t 10 people in line anymore.

A take-home that takes more than 3 hours, uses real company data, has no rubric, has no review session, and produces deployable code isn’t an assessment. It is a consulting gig the candidate is not getting paid for.

Interviewing is already a skill separate from the actual job. The process is not designed for candidates. It is designed for companies to feel thorough. The take-home is the worst expression of that design because it costs the company nothing and costs the candidate a weekend.

Know the red flags. Set boundaries. Ask the uncomfortable questions. When a company ghosts after 15 hours on an assessment, the ghosting isn’t a reflection of the candidate’s skills. It is a preview of what working there would look like.

A bullet dodged is a weekend saved. Go prep for the companies that respect time.