Entry-Level Data Engineer Jobs: Stanford's 19% Gap vs BLS's 35%

2 numbers landed on my feed within a few weeks of each other this fall, and they look like they belong to 2 different industries.

The first says young workers in AI-exposed jobs are falling behind. The second says data science employment is about to grow 35% in a decade. If you're trying to land an entry-level data engineering job right now, you've probably seen both headlines and felt whiplash.

Here's my take after more interview loops than I'd like to admit, on both sides of the table: both numbers are mostly right, and they measure different things. Read together, they say the field is growing, the door into it got narrower, and the people getting through that door can do something specific. The rest of this piece covers what that is.

Stanford's 19% gap and entry-level data engineering

In August, Stanford's Digital Economy Lab reported that employment for workers aged 22 to 25 in highly AI-exposed occupations sits about 19% below where it would be if it had kept pace with same-age workers in less-exposed jobs. At the July 2025 data vintage, that gap was 15%. Experienced workers show no comparable gap.

That's a scary number. Before you panic, look at what it measures.

• It's a counterfactual gap. The 19% compares exposed young workers to a benchmark built from their less-exposed peers. It doesn't count jobs lost. In raw levels, employment for 22 to 25 year olds in the 2 most exposed quintiles fell about 11% from November 2022 to June 2026, while the 3 least-exposed quintiles grew about 10%.
• It comes from ADP payroll data, a balanced panel of 25,000 firms. Stanford says the sample represents neither the whole U.S. labor market nor every company that uses ADP.
• The authors won't call it causal. In their words, "These are descriptive patterns, not causal estimates of the effect of AI."
• The number has moved around. The original 2025 paper said 13%. A February 2026 note had fixed-effects estimates roughly 16%. Now it's 19%. Part of that is new data; part of it, as the authors admit, is that the estimates have become "more sensitive to specification choices."

I respect that last admission. I've spent enough years debugging pipelines to know that when the headline number changes every time someone touches the methodology, you treat it as a direction rather than a measurement.

The direction still matters, though. The release says the adjustment runs mainly through reduced hiring of young workers, not increased separations. The Dallas Fed and a Census Bureau working paper using administrative data found the same pattern: fewer people getting in, with no wave of layoffs pushing people out.

So juniors aren't losing jobs they already have. They're competing for fewer seats at the entrance, which means the thing to prepare for is the hiring process itself.

2 more caveats from Stanford's own release. The gap shrinks when you control for education. It also persists when you exclude tech firms and computer occupations entirely. That second point kills the "it's just Big Tech layoffs" explanation. Whatever's happening is broader than a few companies over-hiring in 2021.

The 19% says fewer juniors are getting hired into AI-exposed roles. It doesn't say the roles are disappearing. Plan for a narrower door into a room that keeps getting bigger.

BLS projects 35% growth for data scientists and never mentions data engineers

Now the optimistic number. The Bureau of Labor Statistics projects data scientist employment to grow 35% from 2025 to 2035, from 275,600 jobs to 371,000. Median pay was $120,230 in May 2025. They project about 24,800 openings per year.

For context, BLS projects total U.S. employment to grow 3.5% over the same period. Computer and mathematical occupations as a group grow 7.3%. Data scientists beat both by a mile.

The BLS data scientist page doesn't mention data engineers at all, either in the description or in the "similar occupations" list (which includes actuaries and survey researchers, but somehow not the people who build the tables the data scientists query). As far as the Occupational Outlook Handbook is concerned, the DE role sits somewhere between "data scientist" and "software developer," and you have to guess.

I've spent my whole career in a job title that the government's main career guide skips. Welcome to data engineering.

Do the math on the openings, too. 95,400 net new jobs over 10 years is about 9,500 a year. The other ~15,000 of those 24,800 annual openings come from replacement: people retiring, switching careers, or getting promoted out. Net growth explains only about 38% of annual openings.

That changes how you should read the headline. A big chunk of the opportunity is backfill, and backfill hiring managers want someone who can take over an existing system on week 2. Experienced people win that fight more often than juniors do.

The BLS projection also can't confirm or refute the Stanford gap, because it's an aggregate across all experience levels with no age breakdown. A field can grow 35% overall while hiring fewer 23 year olds; those 2 things coexist easily if the growth goes to people with 3+ years behind them.

Which is exactly what I'd expect, frankly. I've said for years that data engineering isn't an entry-level job. It combines business context, analytics, infrastructure, software engineering, and SRE work. Companies were already reluctant to hire juniors into that. AI handing them a plausible excuse to hire 1 senior instead of 2 juniors just made the reluctance louder.

Stack Overflow's SQL numbers and the debugging gap in AI-assisted juniors

The 2026 Stack Overflow Developer Survey is the source I find most useful here. It put SQL second among all languages at 58.4%, behind JavaScript at 62.0%, and SQL passed HTML/CSS for the number 2 spot. Among respondents with 16+ years of experience, SQL ranks first at 63.0%.

The more senior the developer, the more likely they're writing SQL. The language people kept calling "legacy" for 15 years is what the veterans use most.

My inference (the survey doesn't say this, I do): SQL demand isn't what's squeezing juniors. If anything, SQL's standing comes from experienced people who use it to understand data, debug it, and explain it. That's the skill gap. Juniors usually can write a query; the hard part is reasoning about what the query returned and why it's wrong.

The same survey shows AI usage is everywhere: 73% of developers who use AI coding tools use them daily. But trust is conditional. In Stack Overflow's May pulse survey, 60% of respondents said they block agents from making unapproved system changes. Developers let AI write code in familiar territory and keep it on a short leash near production.

Now combine that with one study I keep thinking about. Anthropic ran a randomized trial with 52 engineers, mostly junior, learning an unfamiliar Python library. The AI-assisted group averaged 50% on comprehension quizzes versus 67% for the group that coded by hand, and the biggest gap was on debugging questions. The speed advantage from AI was roughly 2 minutes and wasn't statistically significant.

Within the AI group, how people used it mattered most. Participants who delegated code generation to the AI scored below 40%, while participants who used it to ask conceptual questions scored 65% or higher.

That study measured learning a library, not interview performance, so applying it to hiring is my own reading. It lines up uncomfortably well with what I see in interviews, though. The candidate who can't explain why their join fanned out to 3x the expected rows used to be rare. Now I see a version of them every week.

The actual job is less "write a DAG" and more "figure out why this pipeline silently dropped 2M rows last Tuesday." AI can generate the DAG. It's much worse at telling you that the upstream team changed a timestamp from UTC to local time and your incremental load has been skipping a window every night since. That takes someone who understands the data, the grain, and the business.

So when a hiring manager has budget for 1 seat and AI can handle the boilerplate, they want the person who's good at the part AI is bad at. Juniors who prove they can debug and explain get hired. Juniors who can only produce code are competing with a tool that produces code for free.

The interview side has the same problem. I've argued that AI makes classic coding interviews nearly useless for evaluating skill: if a model can solve a medium problem on demand, solving it in front of me tells me very little. Some companies are adapting; Meta was reported in 2025 to be testing AI-enabled coding interviews. Most aren't adapting yet, so you'll still get the leetcode-style round and you should prepare for it. But expect the SQL and debugging rounds to carry more weight in the final decision, because those are the rounds where an interviewer still learns something a model can't fake for you.

Put junior practice time into SQL and debugging first

I did somewhere roughly 20 interview loops in a single job search once. I got rejected after the first half of an onsite. I did 8 rounds at one company, was told I'd passed, and then the headcount vanished. I'm telling you this so you'll believe me about the next part: none of the loops I lost came down to not knowing a tool. They came down to not explaining my reasoning clearly under pressure.

If you're early-career and staring at that 19%, here's where I'd put your time.

Learn SQL past the syntax. Window functions, handling NULLs in joins, deduplication when there's no clean key, grain mismatches, late-arriving data. Every interviewer I've sat with eventually asks some version of "this number looks wrong, why?" We built the sql coding questions on datadriven.io for exactly that kind of problem; they push you past "does it run" into "is it right."

Practice debugging out loud. Take a query that returns the wrong count and narrate the diagnosis as you check the grain, then duplicates on the join key, then the filters. Interviewers score the process more than the answer; a candidate who systematically narrows the problem beats one who guesses right.

Use AI, but be able to explain what it helped you build. Everybody uses it, and pretending otherwise is silly. Use it the way the high scorers in the Anthropic study did: ask it conceptual questions, then write and own the code yourself. If you can't explain every line of a project on your resume, an interviewer will find the line you can't explain.

Learn data modeling before you go shopping for tools. Which orchestrator you pick matters much less than whether you keep fact tables at grain, understand why you'd go wide and denormalized, and know what happens when a dimension changes, because that knowledge carries over to any company on any stack.

For the DS&A round, do mediums and then stop. Around 50 of them and you'll be solid, since few companies consistently ask hards. Spend the rest of your time on the SQL, debugging and modeling work above.

And a word on mindset, because the data can mess with your head. The Stanford gap is about hiring volume. It says nothing about your ceiling once you're in. Experienced workers show no comparable gap, which tells you the people who get through the door and build 2 or 3 years of real production experience are doing fine. The field is still growing, and the narrow part is the entrance.

Treat prep like a job. I'm not the smartest engineer I know; I just outworked the version of myself that wanted to quit after the 6th rejection. Give yourself a week to feel bad about the headlines, then get back to it.

The juniors who come out of this stretch well will be the ones who can open a broken query at 2am and say why it's broken. That skill paid well before AI, and I expect it to pay even better now.

So here's my question for the folks hiring right now: when you passed on a junior DE candidate this year, was it the coding, the SQL, or their inability to explain what they'd built?