I did somewhere around 20 interview loops in a single job search. Phone screens, take-homes, onsites, "culture fits," system design rounds, and yes, the inevitable LeetCode gauntlet. Some went well. Some went laughably poorly. One company had me do eight rounds, told me I passed, said the offer was sent, never sent it, then a new recruiter said I'd declined the offer I never saw. I did four more rounds. Passed again. Headcount was closed.
That was a few years ago. It's gotten worse.
The data engineering interview process in 2026 is broken in ways that would be funny if people's livelihoods weren't on the line. Experienced engineers are failing screens designed for new grads. Take-home projects have ballooned into unpaid consulting gigs. And the disconnect between what companies test for and what the job actually requires has never been wider. I'm not speculating; I've been on both sides of the table, and the view is ugly from everywhere.
The LeetCode Gauntlet Has Nothing to Do With the Job
Let me describe what I do on an average Tuesday: I debug a pipeline that's silently deduplicating records because an upstream team changed a column type without telling anyone. I trace lineage through four layers of transformations to figure out why finance's board deck numbers don't match the dashboard. I write SQL. I write more SQL. I model data. I argue with product about grain.
You know what I don't do? Reverse a linked list. Implement a binary search tree. Solve dynamic programming problems on a whiteboard while someone watches me sweat.
And yet, that's what most hiring loops still test. Companies slap a LeetCode medium (or hard, if they're feeling spicy) in front of a data engineer candidate and call it a technical screen. It's a mechanism to rank candidates; not an indicator of data engineering experience. I've said this before and I'll keep saying it until the industry listens or I retire, whichever comes first.
DS&A is an arbitrary IQ measuring stick. Accept it for what it is. But let's stop pretending it tells you anything about whether someone can debug a Spark job that's been silently dropping 40% of records for six months.
The defense I always hear: "It tests problem-solving ability." Sure. So does figuring out why your Airflow DAG succeeded but wrote zero rows to the target table. One of those scenarios actually happens at work. The other is a party trick.
And here's the part that really gets me: AI can solve a medium LC problem faster than most humans now. If your screening mechanism can be defeated by a tool every candidate has access to, what exactly are you measuring? You're not testing engineering skill. You're testing whether someone spent 200 hours on a grinding site. That's not a career signal; that's a compliance signal.
The Flooded Market Gave Companies Permission to Be Absurd
The last couple of years hit tech hard. Layoffs stacked up. Bootcamps kept pumping out graduates. And suddenly, every mid-level data engineering role had hundreds of applicants. Companies that used to hire based on a SQL assessment and a system design conversation started adding rounds like they were collecting Infinity Stones.
When you have 500 applicants for one role, you don't need a good filter. You need any filter. LeetCode hards become a convenient way to reject 490 people without anyone in HR having to think too hard about it. The bar didn't get raised because the work got harder. The bar got raised because companies could get away with it.
This is the part that kills me: the actual job hasn't changed. You're still modeling data. Still writing pipelines. Still debugging why the daily load failed at 3am because someone deployed a schema change to prod on a Friday (don't deploy on Fridays, please, I'm begging). The problems are eternal: schema drift, late-arriving data, upstream teams breaking contracts without telling you. These haven't evolved. The interview has just drifted further from reality.
And salary compression is making it worse. Companies know candidates are desperate. They know the market is flooded. So they add more hoops, offer less money, and frame it as "maintaining a high bar." Nah. You're exploiting leverage. There's a difference.
Senior Engineers Are Failing Junior Screens
This one makes my blood pressure spike. I've watched engineers with 10+ years of experience, people who've built entire data platforms from scratch, get bounced in a first-round automated screen because they didn't solve a string manipulation problem in 20 minutes.
Let me be clear about something: interviewing is a skill. It's separate from the actual job. I've always said that. But the gap between "interview skill" and "job skill" has become a canyon. A staff-level engineer who's maintained production systems serving hundreds of millions of rows per day shouldn't be failing a screen that a CS sophomore could pass after a weekend of cramming.
The problem is structural. Automated filters don't care about your experience. They care about your score on a timed coding challenge. Recruiters scanning resumes don't know the difference between "built a real-time ingestion layer processing 2TB daily" and "experience with data pipelines." Both get the same keyword match. One of those people has actually done the thing; the other wrote a convincing sentence about it.
I've been on hiring panels where we passed on strong candidates for the dumbest reasons. "They took too long on the coding challenge." The challenge was implementing a graph traversal. The role was building dbt models. Make it make sense.
The interview is a different skill than the job. That's always been true. But in 2026, it's not even the same sport.
Take-Homes Have Become Unpaid Consulting
I want to talk about take-home projects because they've crossed a line. A few years ago, a take-home was a reasonable ask: build a small pipeline, write some SQL, show your thinking. Two, maybe three hours. Fair.
Now? I'm hearing about take-homes that take 10, 15, 20 hours. Full pipeline implementations. Data modeling exercises with multiple data sources. Documentation requirements. Testing requirements. "Present your solution to the team" follow-ups. For a job you haven't been offered. At a company that might ghost you after you submit.
That's not an interview. That's a free proof of concept.
And the kicker: these companies often don't provide meaningful feedback when they reject you. You spent a weekend building something real, and you get a templated "we've decided to move forward with other candidates" email. No notes. No explanation. Just silence and your lost weekend.
If you're a hiring manager reading this: your take-home should be completable in under 4 hours. If it takes longer, you're either poorly scoping the project or you're trying to get free work. Neither is a good look. And for the love of everything, give feedback. The candidate spent hours on your assignment. You can spend 10 minutes writing a paragraph about why they didn't move forward.
What Actually Works (It's Not Complicated)
Good data engineering interviews exist. I've been part of them. They share a few traits:
SQL deep-dives that reflect real work. Give candidates a messy dataset and ask them to answer business questions. Window functions, CTEs, handling nulls and dupes. This is what they'll do on day one. Test for it.
Pipeline architecture discussions. Not "design Twitter" system design. Pipeline architecture. "Here's a data source that updates irregularly with late-arriving records and schema changes. How do you get it into the warehouse reliably?" That's the job. That's the interview.
Data modeling exercises. Hand someone a business domain and ask them to model it. Watch how they think about grain, how they handle slowly changing dimensions, whether they understand the tradeoffs between normalization and denormalization. This is the core skill. If you're not testing for it, you're testing for the wrong things.
Debugging scenarios. Give them a broken pipeline. Let them trace the issue. The actual job is less "write a DAG" and more "figure out why this pipeline silently dropped 2M rows last Tuesday." Test for the thing you need.
None of this requires LeetCode. None of this requires a 15-hour take-home. It requires interviewers who understand the role and have done the work themselves. Which, I realize, is a bigger ask than it should be.
The tools change every 18 months. The problems don't change. Your interview process should test for understanding of the problems, not fluency in the tool of the moment. Concepts transfer across tools; tool knowledge doesn't transfer across concepts. If your loop is filtering for people who memorized Spark APIs instead of people who understand why data pipelines fail, you're building a team that'll look great on paper and struggle in production.
I've been through three waves of "data engineering is getting automated away." Still here. Still employed. Still debugging the same categories of problems. The role isn't going anywhere; it's evolving. But the hiring process needs to evolve with it, and right now it's stuck in 2018 with a LeetCode subscription and a God complex.
So here's my question for anyone who's been through the loop recently: what's the most absurd interview experience you've had for a data engineering role? Because I have a feeling the stories are going to be wild, and honestly, we could all use the catharsis.
Top comments (0)