I did somewhere around 20 interview loops in a single job search. Some went well. Some went so poorly I still think about them in the shower. But here's the thing: at least I knew what I was prepping for. LeetCode mediums, maybe a SQL round, maybe a system design conversation. The format was predictable, even if it was stupid. That era is over, and what replaced it is somehow worse.

The data engineering community has been screaming for years that DSA doesn't belong in DE interviews. Binary tree traversals, dynamic programming, graph algorithms; none of this maps to the actual job. The actual job is debugging why a pipeline silently dropped 2M rows last Tuesday, not implementing Dijkstra's algorithm on a whiteboard. Reddit finally agreed. r/dataengineering blew up over it. The "NoMoreBigONotations" thread went viral. Companies listened. They dropped the algorithmic rounds.

And then they replaced them with absolute chaos.

Why DSA Never Fit Data Engineering in the First Place

Let's be clear about something: LeetCode was never a valid proxy for data engineering skill. It was a borrowed ritual from software engineering interviews that nobody bothered to adapt. Data engineers are rarely expected to write complex algorithms from scratch. We use pre-built libraries and frameworks. The daily work is SQL, pipeline architecture, data modeling, debugging, cost optimization, and dealing with upstream teams who break contracts without telling you.

The best data engineers I've worked with would struggle on a LeetCode hard. And the engineers who ace competitive programming challenges? They frequently struggle with data modeling, pipeline design, and the kind of real-world optimization that actually matters. It's an inverse correlation, and it's been staring us in the face for years.

DSA is a mechanism to rank candidates; not an indicator of data engineering experience. Accept it for the arbitrary IQ measuring stick that it is.

26% of data engineering job ads in 2026 don't even mention education requirements anymore. The industry is finally pivoting toward practical skill assessment. Hiring timelines now exceed 60 to 90 days for complex enterprise roles. Interview loops run 5 to 7 rounds. And yet, the most important question remains unanswered: what are we actually testing for?

Most candidates don't fail data engineering interviews because of SQL or Python. They fail because they can't connect everything together under pressure and communicate it clearly. That's a completely different skill than reversing a linked list.

The Replacement: Three Interviews, Zero Consensus

Here's where it gets ugly. Companies dropped DSA and replaced it with whatever their hiring manager felt like that quarter. There is no standard. There is no consensus. There is barely even a pattern.

Company A wants you to do a 60-minute Cursor-based live build where you implement a feature in a real codebase. Company B wants pure system design: vague, open-ended, no single correct answer, and every interviewer weights trade-offs differently. Company C sends you the interview rules 24 hours before the onsite, and those rules contradict what the recruiter told you two weeks ago. Company D gives you an 8-hour take-home that's definitely 15 hours of work and pays you nothing for it.

If you're running parallel loops (and you should be; it's the only sane strategy), you are now simultaneously prepping for three completely different skill sets with zero overlap. One company allows Cursor, one bans it, one grades on "cleverness," one grades on "correctness." This isn't a hiring process. It's a lottery where you don't know which ticket you bought.

Startups compress everything into 2 to 3 rounds focused on "can you ship on day one." Big Tech runs 4 to 6 standardized rounds emphasizing system design and scale. Mid-market companies? They interview data engineers like they're software engineers, because nobody told them not to. Candidates get blindsided. You prep like it's a data role and walk into SWE-level production-grade coding requirements with full test suites.

For the architecture-style rounds, datadriven.io lets you work through the pipeline-design and data-modeling drills end-to-end instead of just reading about them. That matters, because system design is actually harder to prepare for than LeetCode. At least with DSA, there's consensus on what a good answer looks like. System design? No rubric. No "correct" answer. And every interviewer has a different opinion on whether you should optimize for cost, latency, or data freshness. You're training for a ghost target.

AI Made It Worse, Not Better

Here's the part nobody wants to say out loud: AI didn't lower the interview bar. It raised it invisibly.

Canva replaced its "Computer Science Fundamentals" round with "AI-Assisted Coding" in mid-2025. Candidates now face vague, open-ended challenges like "design an aircraft takeoff and landing control system." 64% of companies still ban AI in interviews, but 80% of candidates use LLMs anyway on take-homes. Meanwhile, 67% of startups explicitly allow AI. Meta, Rippling, Google, Canva, and Shopify all permit AI use in live technical sessions. The policy landscape is a mess.

One CTO told a candidate mid-interview to leave Cursor on. "We want to see how you solve this with AI." The problems got harder. When AI handles the boilerplate, the interviewer's expectations shift from "can you code?" to "can you architect while AI codes for you?" That's a completely different evaluation, and most candidates aren't ready for it.

The goal has evolved: interviewers want to understand how you evaluate, modify, and trust AI-generated answers. Seniors use AI to compress tedious work while maintaining design control. Staff engineers direct AI through complex tasks while monitoring quality. But here's the problem; nobody tells you which version of this test you're walking into. One company wants to see you pair-program with Cursor like it's a junior engineer on your team. The next company will disqualify you for opening ChatGPT.

Companies publicly mandate AI usage daily in production, then secretly ban it in interviews. That's not a hiring process. That's a credibility gap.

What Hiring Managers Say They Want (When They Bother to Say Anything)

I've been on hiring panels where we passed on strong candidates for the dumbest reasons. So let me tell you what actually separates the hires from the passes, at least at companies that have thought about it for more than five minutes.

They want problem-solving mindset over tool knowledge. If you walk into an architecture round and start listing tools instead of describing the problem you're solving, that's a concern. Concepts transfer across tools; tool knowledge doesn't transfer across concepts. This has always been true, and it's finally becoming the interview thesis at companies that are paying attention.

They want business literacy. A query that runs in 3 seconds instead of 30 might save a downstream BI team hours of waiting. Does the candidate connect technical decisions to business outcomes? If your pipeline is technically perfect but ignores downstream consumers or compliance, you're not a hire. You're a liability.

They want you to reason about boundaries. Don't propose a single-pattern solution. Describe the boundary between patterns and the contracts that flow across it. That's the senior signal. At staff level, they want to see you prevent problems, not just solve them.

The irony is thick: these are all reasonable things to test for. But about a third of interview loops include a dedicated data modeling round. A third. The single most important skill in data engineering, and two-thirds of companies don't even have a round for it. They'll spend 45 minutes on a LeetCode medium (or its chaotic replacement) and zero minutes on whether you understand grain, slowly normalized schemas, or why wide denormalized tables with complex types are eating star schema alive.

Cloud cost efficiency is now one of the highest-scored interview categories. Companies are tying bonus incentives to cloud cost optimizations. This makes sense. Storage is 2 cents per GB per month. Engineer time is $100 an hour. The economics killed star schema, and now they're killing the interview formats that don't test for economic reasoning.

The Real Problem Is Nobody Wants to Admit

The inconsistency isn't accidental. It's evidence that the role itself transformed faster than hiring practices could keep up.

Between 2023 and 2026, data engineering moved from "batch ETL plumber" to a role that combines real-time architecture, cloud cost optimization, metadata governance, platform engineering, and AI integration. Companies testing SQL plus system design plus Cursor builds aren't being random. They're testing for three different versions of the job simultaneously because they don't yet know which version matters most.

That's not an excuse. It's a diagnosis.

The community is furious not because DSA is gone, but because at least DSA was consistent. You could grind 50 mediums and be solid. Now? 97% of data engineers report burnout. 70% are likely to leave their jobs within 12 months. Hiring timelines stretch past 90 days. And at the end of that timeline, you might get an offer, be told it was sent, never receive it, do four more rounds, pass again, and have the headcount closed. I'm not making that up. That happened to me.

The interview process isn't designed for candidates. It's designed for companies to feel thorough. The data engineering community won the argument against DSA, and the prize was chaos.

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 tools change every 18 months. The problems don't change. Schema drift, late-arriving data, upstream teams breaking contracts without telling you. These are eternal. The interview formats will eventually stabilize around testing for these eternal problems.

Until then? Treat prep like a job. Accept that every loop will be different. Ask recruiters what types of questions to expect; and if you don't get good answers, look online and at the job description. Prep for system design, SQL fluency, data modeling, and yes, basic Python. Cover the surface area because nobody else is going to narrow it down for you.

What's the worst interview format you've encountered since companies started dropping DSA rounds? I genuinely want to know, because I thought my eight-round saga was bad, and I keep hearing stories that make it look quaint.