My first SQL interview question was about finding the second-highest salary. It's 2026, I've sat on both sides of something like 20+ loops since then, and someone is still asking it.
What did change this month is the data. The Stack Overflow 2026 Developer Survey came out October 6, and SQL passed HTML/CSS for the number 2 spot. It sits level with Python at 58%. The same survey says AI coding tools are now a daily habit for most of the people who use them, while very few people trust those tools with production.
My thesis for anyone prepping a Data Engineer loop right now: AI writes the first draft, and the offer goes to whoever can read that draft, find what's wrong with it, and keep it alive in production. That means hand-written SQL, debugging and pipeline reasoning, so that's where your practice hours should go.
What the Stack Overflow survey says about SQL and Python
Let's be precise, because the headline numbers get mangled fast.
The survey's language usage table has JavaScript at 62.0%, SQL at 58.4%, HTML/CSS at 58.2%, and Python at 58.0%. Bash/Shell comes next at 51.3%. That question had about 14,099 respondents, which is a lot smaller than the "30,000+" in the headline. The survey drew 30,903 responses in total, but each question has its own base.
SQL "passing" HTML/CSS comes down to 0.2 points, and it's ahead of Python by 0.4. On a sample that size, the margin of error is somewhere near plus or minus 0.8 points. That's a 3-way tie. Anyone telling you SQL "beat" Python is selling a blog post.
The tie is still the interesting part, though, and 2 cuts of the same data make it more interesting:
- Among people with 16+ years of experience (n=5,296), SQL leads at 63.0% and Python drops to 53.2%, a 10-point gap in favor of SQL among the people who've been doing this the longest.
- Among languages used for AI work, SQL comes last at 29.8% and Python leads at 39.0%.
So the veterans are writing SQL, and the AI work is mostly happening somewhere else. My read, which the survey doesn't measure, is that SQL is the language people still write by hand and the language of the people who get paged when something breaks. Neither of those is going anywhere.
I'll admit this matches what I've seen, which is the kind of thing you should be suspicious of me saying. Every company I've worked at, from the shop with the 1,500-line stored proc to the companies everyone's heard of, ran on SQL. The orchestrator changed and the warehouse vendor changed. The language the business logic lived in never did.
One more caveat before you build a study plan on this. The survey measures breadth of use. It tells you nothing about hiring demand, interview weight, or skill depth. It doesn't even track Airflow, Snowflake, Databricks, or dbt as tools. Snowflake and Databricks only show up in an LLM-provider chart, which says nothing about warehouse adoption. If someone shows you this survey as proof of what a data engineering tool stack looks like, they didn't read it.
The 20% number and the Data Engineer job nobody interviews for
The survey's AI data tables break down how people use AI across tasks (n=12,547). Generating code in a familiar area: 69%. Debugging, troubleshooting, or refactoring code: 63.8%. Deploying, operating, or troubleshooting production systems: 19.9%.
The rest of that production row is worth reading too. 36.0% don't use AI there and don't plan to. 22.0% say it isn't part of their workflow at all. 23.3% expect to use it more.
At the same time, the blog reports that 73% of respondents who use AI coding assistants or agents use them daily. Look at the base: that's 73% of people who already use AI tools, which isn't the whole profession. It's still a lot of daily use.
Put those side by side. People are happy to have AI write code all day. Debugging code in an editor sits only roughly 5 points behind generation, so diagnosis inside a file is clearly fine too. Once the problem lives in a running system with real data, permissions, and a business waiting on it, usage drops to around 1 in 5.
AI writes the first draft. A human still owns the pipeline at 3am. Interview for the second skill, because the first one is free now.
I've been saying this for years, so the survey just gives me better ammunition. The actual Data Engineer job is less "write a DAG" and more "figure out why this pipeline silently dropped 2M rows last Tuesday." I once debugged a job that had been quietly dropping 40% of records for 6 months before anyone noticed. No autocomplete would have found it. What found it was someone who understood the grain of the source table, the join that fanned out upstream, and the dedupe step that was "fixing" it by throwing away good rows.
The production side of the job has always been the job. What changed is that the coding side got cheap, so the gap between the 2 is easier to see.
Part of that 19.9% is probably about access too. Production systems sit behind permissions, and plenty of orgs restrict who can point an agent at prod. That's my guess; the survey doesn't connect those dots. Either way, a candidate who can reason through a broken production pipeline is scarcer than one who can produce a working query, and scarcity is what gets you paid.
Splitting your Data Engineer interview practice time
Before the plan, a warning about the evidence. Almost everything published about SQL interview formats at specific companies comes from prep vendors and candidate anecdotes. I went looking for employer-documented round structures and found contradictions. One guide says a given company runs 60 minutes with 4 SQL and 4 Python questions, another says 50 minutes with about 6, and nobody links to anything official. So I won't pretend to know exactly what your loop looks like. Ask your recruiter; they'll usually tell you. I'd still split the time like this.
SQL, by hand, with the AI turned off
Make this the biggest block. Even at companies that allow AI in interviews, your SQL fluency shows in how fast you spot what's wrong with the generated query. At companies that don't allow it, you're writing it cold.
What to practice:
- Window functions, and why you'd pick
ROW_NUMBERoverRANKoverDENSE_RANK. Lots of candidates know these functions exist. Far fewer can say out loud when ties matter and what each one does with them, and interviewers notice that difference right away. - Top-N per group, running totals and deduplication. These patterns cover most of what the job asks for every day.
- Saying the grain out loud for every query: what does one row represent? Most bad joins I've seen in production came from someone who never asked that question.
- Solving the same problem twice, once with a self-join and once with a window function. Interviewers love asking for the second version once you've given the first.
Debugging and pipeline troubleshooting
This is the second block, and the 19.9% figure is why. If production troubleshooting is the area AI touches least, it's the area where you set yourself apart.
Practice with broken things. Take a working query and break it on purpose: add a join that fans out, add a NULL to a key column, shift a timestamp across a timezone boundary. Then find the bug from the output alone. Practice talking through late-arriving data, schema drift, and the upstream team that renamed a column without telling anyone. The tools change every 18 months and these problems never do.
Python, scoped to what Data Engineers actually do
Python sits level with SQL in the survey, and you'll get a coding round. Stick to mediums. Do 50 and you'll be solid; few companies ask hards consistently. Focus on the data-shaped stuff: parsing messy files, dicts and sets for dedupe and grouping, generators for large inputs. If you want somewhere to practice for python coding questions, try datadriven; we built it for that category, and the problems look like the job and not like a puzzle book. (I've never solved a bit manipulation question and have absolutely no idea what I'm talking about with those. Still employed.)
Practice both with and without AI
Policies vary and they're changing. Canva's engineering team wrote publicly that they expect candidates to use AI tools in interviews for some roles. Simon Newton argued there that the old questions got solved instantly by AI and that real engineering is more about reading and improving code than writing it from scratch. That post is from 2025 and doesn't cover data engineering, so it's one company's opinion and not a trend. I agree with the opinion, though.
If your loop allows AI, the skill being tested is review. Can you read generated SQL and catch the missing partition, the wrong join type, the aggregate at the wrong grain? Practice exactly that: have a tool generate a solution, then audit it like it's a PR from a new hire.
The skills that still decide Data Engineering offers
I've been on hiring panels where we passed on strong candidates for the dumbest reasons. I've also been the candidate who got rejected after the first half of an onsite. That one hurt. The interview is arbitrary, and you should play the game anyway. Still, the things that move a panel from "lean hire" to "strong hire" have stayed pretty consistent, and the survey data lines up with them.
Data modeling is the core skill, and it doesn't depend on any tool. If you get the model wrong upstream, everything downstream is pain. Keep fact tables at grain; you can always aggregate up and you can never disaggregate down. AI will happily write you a query on a bad model, and it'll run fine, which is the problem.
Then there's explaining tradeoffs under pressure. I've watched people with 10 YOE get downleveled because they couldn't articulate their design decisions in the room. "Why batch and not streaming?" (Batch covers 90% of what companies actually run; most of y'all don't need streaming.) "Why a wide table and not a star schema?" (Storage costs around 2 cents a GB a month; the engineering overhead of maintaining a star schema costs a lot more than that.) Have these answers ready and back them with economics. Economics wins arguments that "best practices" lose.
For pipeline architecture, skip the generic system-design material about load balancers and reverse proxies. Panels want to hear how you'd handle idempotency, backfills and late data, and how you'd know a job dropped rows before the business did.
Production instincts are the 19.9% skill. Tell them about the time something broke and what you did about it. A story about a silent failure you caught is worth more than any tool on your resume.
I've lived through 3 waves of "data engineering is getting automated away," and I'm still debugging the same categories of problems. This survey reads like the 4th wave with better numbers. Developers handed AI the keyboard, and they kept the pager themselves. The people who get hired are the ones the business trusts with it.
What's your loop doing right now: are they letting you use AI in the SQL round, or making you write it cold?
Top comments (0)