DEV Community: DataDriven

Data Engineer Salary 2026: Every Survey Is Lying to You

DataDriven — Tue, 21 Jul 2026 17:33:23 +0000

I pulled salary data from 6 different sources last month. Got 6 different answers. The spread wasn't a rounding error; it was $55,000.

Career pages from real companies posting real roles showed a median data engineer salary of $185,000. Glassdoor said $134K. ZipRecruiter said $130K. If you're about to walk into a negotiation, which number you believe is the difference between a strong counter and a shrug.

I've been on both sides of the hiring table at companies whose names you'd recognize. I've watched candidates anchor to the Glassdoor number and leave $40K on the table. I've watched others walk in with career page data, cite it calmly, and get what they asked for, because the hiring manager already knew the budget was there.

Every major salary survey is structurally wrong. Not "slightly off." Wrong as in they're measuring a different population than the one that's actually getting hired.

The $55K Data Engineer Salary Gap Nobody Wants to Explain

An analysis of 244 real job postings pulled from company career pages in 2026 shows a median data engineer salary of $185,000. Remote roles median even higher at $187,000. San Francisco, weirdly, comes in at $179,000.

Now compare that to the survey platforms. ZipRecruiter: $129,716. Glassdoor: $133,861. Indeed: $136,776. Each one sits $50K+ below what companies are actually posting when they're trying to fill seats.

This is not a disagreement about methodology. It's a $55K chasm caused by fundamentally different measurements. Career pages capture what a company will pay right now to hire someone. Surveys capture what a mixed bag of respondents reported earning at some point in the recent past. These are different questions producing different answers, and most people don't realize they're looking at the wrong one.

The gap gets worse when you factor in that only 14% of tech job postings even disclose salary. When companies do post numbers, they tend to be the ones with competitive budgets. The thousands of postings with no salary listed? Those are the ones dragging survey medians down through omission.

And then there's FAANG, which breaks every survey completely. Meta data engineers: $322K median total comp. Google: $276K. Netflix: $565K in straight cash. An E5 at Meta (senior level) pulls $229K base + $222K annual stock vest + $27K bonus. That's $478K total. Netflix L5 clears $550K with no equity complexity at all. None of these numbers exist in Glassdoor. They're invisible to traditional survey methodology because the people earning them don't fill out surveys.

Why Every Data Engineering Salary Survey Gets It Wrong

Here's the dirty secret about salary surveys: they don't measure the market. They measure whoever decided to fill out a survey.

And who fills out salary surveys? Not the L5 at Netflix clearing $550K in cash. Those people have zero incentive to spend 15 minutes on a Glassdoor form. The people who fill out surveys are disproportionately earlier in their career, disproportionately frustrated with their pay (59% of tech workers report feeling underpaid), and disproportionately concentrated in a handful of metros.

This creates 4 compounding biases that make every number you see structurally wrong.

Self-selection bias. Crowdsourced salary data is driven by who shows up. Workers who feel underpaid submit to complain. Workers who feel overpaid submit to boast. The actual median; the people in the middle? They're doing their jobs. One audit found 43% of crowdsourced salary submissions were off by 15%+ from market benchmarks. That's not noise. That's a broken instrument.

Geographic skew. San Francisco Bay Area tech salaries run 126.6% of the national average. SFBA software engineers earn a median $233K while national surveys report $125K to $135K. Every survey oversamples coastal hubs because that's where the respondents are, which pulls the number in directions that don't represent the national market or the remote market where the money increasingly lives.

Title dilution. "Data engineer" in 2026 could be a warehouse analyst at $90K, an ML platform engineer at $200K+, or a senior data architect at $250K+. Surveys that report a single median for this title are averaging incomparable roles. It's like reporting the "average vehicle price" across sedans, dump trucks, and Ferraris.

The equity invisibility tax. Surveys almost never disaggregate base from total comp. A data engineer at FAANG might show $230K base, but the $170K in annual equity vesting and $25K bonus bring real compensation to $425K. Meanwhile, a survey respondent at a non-tech enterprise sees base ≈ total comp. Mashing these together into one "average" is statistical malpractice.

The survey is measuring what people accepted 2 years ago. The career page is measuring what companies will pay today. If you're negotiating tomorrow, only one of those numbers is useful.

Here's the thing about Glassdoor specifically: it wraps self-reported data in additional comp estimates, which inflates some figures while dragging others down. PayScale skews early-career because of who fills out their forms. ZipRecruiter reflects what's posted, not what's accepted. Each source surveys a different crowd and measures a different thing. Workers making $250K+ rarely respond to public salary surveys at all; privacy risk, employer visibility, lack of motivation. The top 15% of earners are systematically underrepresented, pulling reported medians down 10% to 15% compared to actual compensation.

There is no unbiased source. But some sources are less wrong than others.

The Entry-Level Collapse That Broke Every Average

Only 3% of data engineer postings in 2026 are entry-level. Down from 10% to 15% historically. Junior data engineering postings fell 67% post-GenAI, with entry-level hiring collapsing 73% year-over-year between late 2023 and late 2025.

66% of CEOs are actively freezing entry-level headcount. Not pausing. Freezing. They're trading junior hires for "judgment hires": mid and senior engineers who can architect systems, debug production failures, and make governance decisions that AI can't touch. AI automated the boilerplate: staging SQL, scaffolded DAGs, schema mappings. It did not automate architecture, governance, debugging judgment, or cost optimization.

The total data engineer market still grew 23% year-over-year in headcount. The global DE services market hit $105 billion growing at 15% CAGR. But all of that growth is seniority-weighted. Companies are hiring more data engineers; they're just not hiring juniors.

This does 2 things to salary data. First, it pulls every average up mechanically. When the bottom 10% to 15% of earners vanishes from the hiring pool, the median jumps without anyone getting a raise. The $185K career page median isn't inflated; it's accurate for the population that's actually getting hired. The survey-reported $130K is understated because it's sampling a truncated pool that includes people who accepted junior rates 3 years ago.

Second, it creates a bifurcated market that a single median can't capture. Junior data engineer ranges sit at $72K to $97K on ZipRecruiter. But Glassdoor reports $126K average for the same title; a 75% variance driven by geographic and sample bias. Base salaries fell 15% to 25% below 2022 peaks, but this hit juniors disproportionately. AI/ML specialists command 30% to 50% premiums over generalists. If you can run production Kafka pipelines, you're in a fundamentally different market than someone looking for their first role.

Companies are advertising junior roles, then quietly filling them with experienced engineers. This isn't a hiring freeze; it's a bait-and-switch.

The uncomfortable math: if companies stop hiring juniors today, they're engineering a senior shortage in 5 to 10 years. But CFOs don't optimize for 2031. They optimize for this quarter's headcount target.

What to Actually Bring to Your Next Interview and Negotiation

60% to 70% of candidates accept the first offer without countering. Those who negotiate with market data see 15% to 20% increases on average; about $24K median increase in tech.

The difference between a good salary negotiation and a bad one is which data you walk in with.

Career page postings for your target company and comparable companies. These reflect current budgets, not historical averages. If the posting shows $170K to $210K, your anchor is the 75th percentile, not the midpoint.

Levels.fyi for tech-specific roles, especially FAANG. The data disaggregates base, equity, and bonus, which matters when total comp runs 2x to 3x base. And here's what most people miss about equity: it's renewing, not depreciating. An L5 engineer's compensation contains overlapping tranches. Initial grant (years 1 to 4), year-2 refresher (years 2 to 5), year-3 refresher (years 3 to 6). This creates a $125K to $150K annual equity floor after the initial grant vests. Ask explicitly: "What's the typical annual refresher equity grant?" That's the question that separates people who understand comp from people who don't.

Robert Half and Motion Recruitment salary guides, which segment by level and geography. Robert Half reports $127K to $180K entry-level, $160K to $215K senior. Tighter ranges, more useful than a single median.

Glassdoor and ZipRecruiter as a floor, not a ceiling. If the survey says $130K, treat that as the minimum. Your job is to prove you're worth the career page number.

Skill premiums stack and they're documented. Kafka/streaming production experience: $15K to $50K over senior baseline. AWS Data Analytics Specialty certification: +$18K. Spark expertise: 15% to 25% premium. Both batch and streaming? 30% to 50% salary jump. Streaming carries the steepest premium because production Kafka is hard to learn without a production Kafka environment; the barrier to entry is structural, not educational.

Don't forget the base salary multiplier: your bonus is usually a percentage of base. The higher you negotiate base, the higher every downstream calculation. One negotiation compounds for years.

And here's the part nobody tells you: interview prep and negotiation prep are the same skill. The better you perform in the loop, the stronger your leverage on the offer. When I was grinding through 20+ loops in a single job search, the difference between the lowball offers and the strong ones tracked almost perfectly with how well I'd prepared for each company's process. That's the problem we set out to solve with DataDriven; when someone says i used DataDriven for data pipeline interview questions, those reps covered the patterns that actually show up in loops, not generic textbook exercises.

Colorado's pay transparency law alone pushed posted salaries up 3.6%. As more states mandate disclosure, the gap between survey data and reality will shrink. But right now, in mid-2026, the data engineering salary market has a $55K information asymmetry. The side you're on determines whether you negotiate from strength or from a number that was wrong before you opened your mouth.

The tools change. The surveys will keep being wrong in the same ways for the same reasons. Learn which numbers to trust, walk in with the right data, and stop letting a Glassdoor screenshot be the reason you leave 5 figures on the table.

What's the biggest gap you've seen between what a survey reported and what you actually got offered?

The AI Cheat Tool Your Interview Cannot See

DataDriven — Thu, 16 Jul 2026 10:12:37 +0000

I've been on hiring panels where we spent 45 minutes convinced a candidate was sharp. Articulate answers. Clean code. Solid reasoning. Then in the debrief, someone pulled up the recording and timed the responses. Every answer: 4 seconds. Easy question, hard question, curveball follow-up. 4 seconds flat. Humans don't think like that. Humans stumble on hard problems and breeze through easy ones. This person's cadence was perfectly uniform. I'd love to tell you I spotted it in real time. I didn't. Nobody on the panel did.

That was 8 months ago. The tools have gotten significantly better since.

The Overlay That Broke Data Engineering Hiring

There's a new category of AI cheating tools that most interviewers don't know exist. Cluely, Interview Coder, Final Round AI; these aren't browser tabs a candidate Alt-Tabs to when you're not looking. They're invisible GPU overlays that use DirectX (Windows) and Metal (macOS) hooks to render LLM-generated answers directly on the candidate's monitor, beneath the capture layer that Zoom, Teams, and Google Meet use for screen sharing.

In plain English: when you screen-share on Zoom, the application captures pixels from a specific layer of the OS graphics pipeline. These overlay tools render their content below that layer, in the GPU's local frame buffer. The interviewer sees a clean IDE. The candidate sees the IDE plus a floating panel with AI-generated code and explanations. Those pixels literally don't exist in the video stream that gets encoded and transmitted.

This isn't a proof of concept from a security researcher. Cluely pulled 70,000 signups in its first week. It's a consumer product with standard SaaS pricing: free tier at 5 responses per day, $20/month for Pro, $75/month for the "undetectability" tier that does the GPU-level rendering. Cheating on your data engineering interview now costs less than a monthly gym membership.

The overlays don't trigger tab-switch alerts. They don't appear in keystroke logs. They don't show up in screen recordings. The proctoring vendors claiming 85-95% detection effectiveness? They're scanning for browser tab switches and copy-paste events. They're watching the wrong layer entirely. 6 new overlay tools emerged in 2025 alone, plus at least 3 open-source clones.

Screen-share monitoring is security theater. The pixels the interviewer sees are not the pixels the candidate sees.

Half Your Tech Candidates Are Cheating. Most of Them Pass.

Fabric analyzed 19,368 interviews between July 2025 and January 2026 across 50+ companies. The numbers are bleak.

38.5% of all candidates triggered cheating flags. For technical roles, that number hit 48%. Sales roles? 12%. The roles where the stakes are highest and the questions are most googlable are the roles getting gamed hardest. This inverts the assumption that technical interviews are somehow more honest by nature. They're not. They're just more automatable.

The acceleration is what gets me. Cheating went from 9% in July 2025 to 45% by September. 3x in 3 months. Then it plateaued through January; not because people stopped, but because it saturated. When nearly half your candidate pool is using AI assistance, you don't have a cheating problem. You have a broken measurement system.

The part that should make every hiring manager stop and think: 61% of flagged cheaters scored above the passing threshold and advanced in the pipeline. These aren't marginal candidates scraping by. They're clearing the bar comfortably, because the AI is genuinely good at answering the questions we ask. 61% is not a detection gap. It's an action gap. Companies flag candidates and hire them anyway because the score looked fine.

Junior candidates (0 to 5 years of experience) cheat at nearly double the rate of seniors. The people with the least context to evaluate whether an AI-generated answer is even correct are the ones relying on it most. It's a desperation play: they know AI fills knowledge gaps faster than grinding prep, and they're probably right. The incentive structure is broken.

Banning AI Doesn't Fix the Architecture

64% of companies ban AI in interviews. 80% of candidates use it anyway on take-homes. That's not a policy failure; that's a policy being laughed at.

The detection layer makes it worse. AI detection tools produce essentially random results: the same essay scored 4%, 91%, 12%, 67%, and 38% across 5 different detectors. OpenAI killed its own classifier in July 2023 because it was only 26% accurate. Stanford found a 61.2% false-positive rate on essays from non-native English speakers versus 5.1% for native speakers. You're not catching cheaters. You're penalizing people who learned English as a second language.

The industry response has been a stampede back to in-person interviews. They jumped from 5% to 30% in a single year. Google and McKinsey mandated in-person rounds in mid-2025, explicitly citing AI fraud. 72% of recruiting leaders say fraud prevention is the driver.

The problem: in-person doesn't scale. It's expensive, exclusionary, and locks out remote candidates, international candidates, and anyone who can't fly to your office for a day. The least scalable option is the one everyone's reaching for. That's not a fix; it's a retreat to 2019.

Take-homes are dead in their current form. Anthropic's own engineering team found that Claude Opus "matched top candidates" on take-home assessments and there was "no longer a way to distinguish between the output of top candidates and the most capable model." When the company building the AI tells you their model passes your take-home, believe them.

Eye tracking? Gaze monitoring? Also crumbling. NVIDIA Maxine synthesizes natural gaze. Candidates keep their eyes near the camera while reading overlays at the screen periphery. HireVue discontinued facial analysis in 2021 after finding facial expression data contributed less than 0.25% to performance predictions. The biosurveillance approach is simultaneously invasive and useless.

You can ban AI in interviews. You can't ban the architecture it runs on. The enforcement tools are more invasive than the cheating, and they still don't work.

The Interview That Survives

The strongest signal isn't software. It's one follow-up question.

AI generates polished, multi-layered code. But when you ask a candidate to explain line 7, or walk through why they chose that join strategy, or refactor their solution with a new constraint, the gap between "read this off a screen" and "actually understand it" becomes obvious in seconds. If you can't explain line 7, you didn't write line 7.

Consistent response timing is the second strongest behavioral fingerprint. Humans pause longer on hard questions. They stammer, correct themselves, say "let me think" with variable duration. AI overlay tools show uniform 3 to 5 second latency regardless of difficulty, because the pipeline is always: audio capture, transcription, LLM inference, render. That flatness is detectable. But only about 30% of interviewers actively monitor response timing. The other 70% miss it entirely.

System design remains the most AI-resistant format because it's fundamentally discursive. You can't read a system design answer off an overlay, because system design isn't a question with a fixed answer. It's a conversation that shifts when the interviewer changes constraints, pushes back on choices, and asks "what happens when this fails?" No overlay tool fakes that in real time. Not yet.

For data engineering interviews specifically, the path forward is clearer than for most roles. Pipeline architecture, data modeling exercises, debugging scenarios. "Here's a pipeline that silently dropped 2M rows last Tuesday. Walk me through how you'd find the problem." That question has no clean overlay answer because the solution depends on follow-ups about the specific system, the specific data, the specific failure mode. The actual job is debugging, not building; might as well test for it.

This is also why concepts matter more than tools, and always have. If your interview tests whether someone can write a Spark transformation, an overlay solves it in 4 seconds. If it tests whether someone understands why a pipeline breaks when upstream schema changes violate a downstream join contract, you're testing something AI can't fake. Concepts transfer across tools; syntax doesn't, and that gap is exactly why we built databricks interview prep with datadriven around architecture walkthroughs and data modeling, not the kind of timed problems an overlay solves in 4 seconds.

The career implications cut both directions. If you're a candidate who genuinely knows your stuff, push for system design and pair-programming rounds. Those formats favor you. If a company's entire loop is timed LeetCode and async take-homes, their signal is already compromised, and your real expertise is competing against someone paying $75/month for invisible help.

The companies that adapt their process will hire better. The ones clinging to LeetCode mediums and take-homes will keep onboarding engineers who can't debug a broken DAG in their first week, then blame the candidate instead of the process.

What's the most egregious cheating you've seen in an interview, on either side of the table?

Half of Data Engineering Jobs on LinkedIn Aren't Real

DataDriven — Tue, 14 Jul 2026 10:06:48 +0000

I applied to 47 data engineering jobs in a three-week stretch last year. Heard back from nine. Got interviews at four. Two of those companies had already filled the role before my first call. One admitted the headcount was "paused indefinitely." The fourth gave me a verbal offer that evaporated when the hiring manager left. That's the job market in 2026. You're not failing; you're playing a rigged game.

Here's the part that should make you angry: companies are publicly claiming data engineering hiring is up 23% year-over-year. That number is real. It's also one of the most misleading statistics in tech right now.

The Paradox: Hiring Is Up, But the Ladder Is Gone

Data engineering hiring grew 23% YoY. Entry level data engineering roles fell 67% since AI went mainstream. Both of these things are true at the same time.

The growth is exclusively senior hires. Companies aren't expanding their data teams; they're replacing junior pipelines with senior architects who can ship AI-ready infrastructure on day one. Only 2.3% of DE job postings target entry-level candidates with under two years of experience. The most common requirement? Four to six years, appearing in 11% of postings.

This isn't a downturn. It's a reclassification. What used to be "entry-level" got relabeled as "mid-level with 4+ years." The ladder didn't break; it got pulled up.

Junior developer postings across all of tech collapsed 60% between 2022 and 2024. Data engineering followed the same trajectory, just quieter. And here's the twist nobody talks about: job postings labeled "entry-level software engineer" grew 47% between October 2023 and November 2024, but actual hiring into those levels dropped 73% in the same window. Companies are advertising junior roles and filling them with experienced engineers. The title is a lie.

The market didn't grow 23%. It compressed vertically. The number went up; the ladder got removed.

Meanwhile, 66% of CEOs surveyed are freezing or cutting hiring through the rest of 2026 while simultaneously betting billions on AI infrastructure. LLM engineering skills in DE job postings spiked 300% in a single quarter, from 3% to 12%. The role is being rewritten in real time, and the rewrite doesn't include a chapter for people just starting out.

Half the Job Market Is a Mirage

Let me say this plainly: ghost jobs now account for 48% of tech job postings. Nearly half the roles you see on LinkedIn aren't real. They're not stale listings that HR forgot to take down (though some are). They're deliberate.

40% of tech companies posted fake jobs in the past year, and 79% of those listings were still active at the time of the survey. This isn't accidental. It's infrastructure.

Here's why companies do it. 62% of hiring managers admitted they post ghost jobs to make current employees feel replaceable. 43% cited signaling company growth to investors and board members. Nearly 60% collected resumes with no intention to hire immediately; they call it "talent pool management." The idea originates from HR (37%), senior management (29%), or executives (25%). Hiring managers, the people who actually need to fill roles, typically don't originate it.

93% of HR professionals engage in posting ghost jobs: 45% regularly, 48% occasionally. And 96% of recruiters use automated software to repost listings on a schedule, so jobs disappear and reappear with identical descriptions, the clock resetting every 30 to 90 days. The ATS never stops accepting applications even after the requisition is dead. If you got an automated rejection two to four hours after applying, that's not a keyword mismatch; that's a closed role running on autopilot.

The financial damage is real. 72% of job seekers report mental health damage from the application process. 37% suffer direct financial losses averaging $500 to $2,500. And the 47% of tech professionals actively job-hunting in 2026 (up from 29% last year) means there's an endless supply of desperate applicants feeding the ghost job ecosystem. Companies have no incentive to stop.

The worst offenders aren't FAANG and they aren't tiny startups. Companies with 1,001 to 5,000 employees post ghost jobs at nearly a 25% rate, the highest of any company size. That's the Series C through E band where CFOs tighten headcount while board pressure demands growth signals. If you're an early-career engineer, that's the exact cohort you're probably targeting. You picked the most deceptive segment of the market.

What the Real Postings Actually Want

So what do the legitimate data engineering roles look like in 2026? Different. Fundamentally different from two years ago.

Python (70%) and SQL (69%) are still non-negotiable. That hasn't changed. Everything else has. Machine learning appears in 29.9% of postings. Kafka shows up in 24%. CI/CD in one out of six. Apache Spark still dominates at 38.7%, but Snowflake (29.2%) and Databricks (16.8%) are carving out separate tiers. Companies don't want generalists who can learn their stack; they want people already fluent in it.

The role has absorbed platform engineering, DevOps integration, ML pipeline support, and governance orchestration into a single position. Data engineers must prepare data for AI use cases, collaborate with ML engineers, and understand feature stores, experimentation, and model serving. That sentence would have been nonsensical in a DE job description 18 months ago. Now it's baseline.

26% of job postings don't mention education requirements at all. That sounds like a window for self-taught engineers, and it is, but it's being filled by mid-career pivots with adjacent experience, not by people fresh out of bootcamp. The real barrier isn't credentials; it's that bootcamp curricula teach isolated SQL and Python while jobs demand LLM-aware pipelines, regulatory audit trails, and 99.95% uptime infrastructure. The skill tree forked, and the entry-level branch got pruned.

The median salary sits at $131K to $135K, which sounds great until you realize it's skewed by the shift toward senior talent. Senior contract data engineers command $150 to $185 an hour. Specialized AI-infrastructure architects bill $220 to $400. The floor rose because the people standing on it changed.

Where the Actual Jobs Are (and How to Stop Wasting Time)

Real jobs exist. They're just not where most people are looking.

Contract and platform migration work is where the volume is. Over 3,300 data migration jobs and 6,600+ technical data migration roles are active right now, mostly 60 to 90 day engagements for companies rebuilding data stacks for cloud migration and AI readiness. Snowflake and dbt expertise commands premium contract rates. These aren't glamorous FTE positions with equity; they're sprint work. But they're real, they pay, and they build the exact résumé signals that get you into full-time senior roles later.

Databricks alone has 840+ open roles. But here's the catch: that's the vendor hiring, not the customers. If customers were expanding data teams, they'd be hiring people to use Databricks. Instead, Databricks is hiring its own engineers to do POC work for under-resourced customers. Tool adoption isn't translating to team growth at the companies actually using the tools.

To spot a real posting versus a ghost, here's what I actually look at:

Check the company's own careers page. Two minutes on their site is still the best ghost job filter available. If the role isn't listed there, it's phantom. LinkedIn aggregates are noise.

Look at the posting age. Tech roles typically fill in 30 to 45 days. If a listing has been open for 90+ days, something is wrong. Jobs posted 30+ days show a 30% chance of never resulting in a hire.

Salary range omission is a red flag. 16+ states and D.C. now mandate pay disclosure. Listings that dodge it in those jurisdictions are either non-compliant or not real. 44% of candidates won't apply without a range; legitimate employers know this.

Watch for reposting patterns. Same title, same description, fresh date. That's the ATS auto-renewing a dead requisition. The clock reset doesn't mean new hiring intent.

Named hiring manager > generic HR. If the posting names a specific manager or team lead, someone is actually waiting for a hire. Generic "talent team" postings with no team context are pipeline collection.

The honest advice for early-career engineers: stop applying to 50 listings a week and start being surgical. Target companies under 1,000 or over 10,000 employees (lower ghost rates). Prioritize contract work that builds architectural experience. Get reps on the stuff that actually separates candidates in interviews: data modeling, pipeline architecture, system design thinking. That's exactly why we built datadriven.io; DataDriven is good for data engineer interview questions that test the concepts behind the tools, not trivia about Spark APIs nobody remembers anyway.

The entry-level data engineering path isn't dead. It's been rerouted. The reliable path now is analyst or backend engineer first, then internal transfer. That sounds frustrating, and it is. But it's also how most of us got here. I didn't start in data engineering. I started outside of tech entirely. The path was never a straight line; we just pretended it was for a few years when hiring was hot.

Data engineering is not shrinking. It's consolidating into a senior-heavy discipline that demands architectural thinking, governance awareness, and AI-infrastructure fluency. 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 ghost job epidemic will burn itself out eventually; it's expensive for companies too, even if they don't realize it yet. But the reclassification of entry-level to mid-level? That's structural. That's not going back.

If you're grinding applications right now into what feels like a void: it's not you. Statistically, half of what you're applying to doesn't exist. That's not a personal failure. That's a broken system.

What's the most obviously fake job posting you've come across, and how far into the process did you get before you realized it wasn't real?

3 Staff Engineers Couldn't Pass This Single DE Job Posting

DataDriven — Thu, 09 Jul 2026 10:08:18 +0000

I sat down with two other staff-level data engineers last month. Between us: 40+ years in data engineering, multiple FAANG stints, and enough interview loops to fill a spreadsheet nobody asked for. We pulled up a single job posting from a Series C company with a real data team. Nothing exotic. Reasonable product, decent engineering culture, the kind of place you'd actually consider working.

Not one of us met every requirement on the job description.

The posting wanted SQL, Python, Airflow, Snowflake, Kafka, Flink, dbt, Terraform, Kubernetes, and "LLM integration experience." Fifteen distinct technologies across four engineering disciplines. Salary: $140K to $170K. That's the same range these roles paid in 2022, when the ask was SQL, Python, Airflow, and a warehouse.

Three staff engineers. 40+ combined years. Zero out of three qualified on paper.

If that doesn't tell you the hiring process is broken, I don't know what does.

The Impossible JD Is the New Normal

In 2022, a typical data engineering posting listed four or five core tools. SQL. Python. An orchestrator (usually Airflow). A warehouse (usually Snowflake or BigQuery). Maybe Spark if the company was processing serious volume.

In 2026, that same posting, at the same salary, now includes all of the above plus Kafka, Flink, dbt, Terraform, Kubernetes, and "LLM integration." LLM skills in data engineering postings jumped from 3% to 12% in a single quarter. That's not gradual adoption; that's panic hiring.

Here's the thing: these aren't complementary skills. They're separate career tracks wearing a trench coat. A Databricks engineer working on distributed compute and Delta Lake optimization is not the same person as a Snowflake engineer designing warehouse concurrency patterns. SQL mastery and PySpark proficiency are taught in different phases of a career for a reason. Databricks engineers earn a $10K to $15K premium over Snowflake engineers at equivalent levels, not because Databricks is "better," but because production Spark plus distributed systems expertise is scarcer than SQL-first warehouse knowledge. These are fundamentally different learning curves, different architectures, different day-to-day work. Yet job descriptions list both as "required" like they're interchangeable checkboxes.

Python appears in 70% of data engineer postings. SQL in 69%. But after that, the stack fragments: Spark at 38.7%, Snowflake at 29.2%, Kafka at 24%, Databricks at 16.8%. No two companies agree on what the stack actually is. So they list everything, hoping the perfect unicorn applies.

The unicorn doesn't exist. And the engineers closest to it; the staff-level folks who understand exactly how complex this landscape is; they read that JD and close the tab.

When experienced engineers see 14+ tools in one posting, many read it as "this company doesn't know what it needs," not "we're thorough."

Postings with 6 to 13 requirements receive about 30% more applicants than postings with 14+. That's not because the market lacks talent. It's because the people with the most experience and context are the ones most likely to self-select out. They know nobody does all of that. Junior candidates who don't know what they don't know are the ones clicking Apply.

Why Companies Keep Writing Fiction

This isn't malice. It's organizational dysfunction.

Most job descriptions aren't written by the person you'd actually report to. They're built by committee. The hiring manager adds SQL and Python. The VP adds Kubernetes and Terraform because "we're moving to cloud-native." The ML team bolts on LLM integration because they heard about it at a conference. The recruiter copy-pastes from a competitor's posting and sprinkles in whatever worked last time.

The result: three different jobs inside one posting. Platform engineering. Streaming infrastructure. Analytics engineering. ML operations. Each one a distinct specialization with a different learning curve and a different interview loop. Nobody on the hiring committee realizes they've described four humans, not one. And nobody pushes back because adding requirements feels free.

It's not free. Poorly written JDs are cited as the primary cause in over 50% of hiring failures. 44% of hiring managers can't fill their open roles, and the number is climbing. But here's the kicker: 94% of employers say skills-based hiring is more predictive of on-the-job success than resume screening, yet over half still screen against rigid checklists. They know the process is broken. They keep doing it anyway.

The compensation tells the rest of the story. Data engineering salaries rose from about $113K to $153K over the past few years. That's a 35% bump. The role scope roughly doubled. You're being asked to learn twice as much, own twice as much, debug twice as much; for a 35% raise. The economics don't work, and experienced engineers can see that from the posting alone.

And let's talk about the 40% of tech companies that posted ghost jobs in the past year. Nearly half of visible data engineering roles on LinkedIn aren't actual open positions. You're grinding through a 15-tool requirement list for a role that may not even exist. 62% of hiring managers admit their AI screening tools reject qualified candidates who don't match algorithmic patterns. So even if you apply, the ATS might bury you before a human reads your name. The filter is broken at every level.

What the Job Actually Requires on Day One

Here's what happens your first week at any of these companies. Nobody asks you to configure a Flink cluster, deploy a model to Kubernetes, and integrate an LLM into the data pipeline before lunch. What actually happens: someone points you at a broken pipeline, and you figure out why it's broken.

SQL and Python still carry the game. SQL appears in 94% of interview loops for data engineering roles, and SQL plus Python together get candidates through roughly 60% of real interviews. The other eight tools on the posting? Most teams deploy three, maybe four, in production. The rest is aspirational.

The actual job is less "architect a real-time streaming platform" and more "figure out why this pipeline silently dropped 2M rows last Tuesday and make sure it never happens again." Production work (debugging, incident response, observability) comprises around 60% of what data engineers do day to day. It appears in approximately 0% of job descriptions. Nobody interviews for that skill. They interview for Spark API trivia and LeetCode mediums. These are measuring different things entirely.

77% of data engineers report heavier workloads in 2026 despite AI tools that were supposed to lighten the load. Engineers now spend 37% of their time on AI-related projects, up from 19% two years ago. AI didn't replace work; it created new categories of work on top of the existing ones. The tooling promise of "do more with less" turned into "do more with more, and also learn this new thing by Friday."

So what actually matters? Data modeling. Query optimization. Understanding why things break, not just how to set things up when they're working. Pipeline architecture, not system design (data engineers don't care about load balancers and reverse proxies). The concepts that transfer across every tool, every warehouse, every orchestrator. Concepts transfer; tool knowledge doesn't. That has always been the thesis, and bloated job descriptions haven't changed it one bit.

The 70% Rule and How to Play the Game

Here's the practical advice. Apply at 70%. Not 70% of every random tool listed; 70% of the must-haves. SQL, Python, one orchestrator, one warehouse. If you've got those plus a track record of shipping and debugging production pipelines, you're in the conversation.

42% of applicants don't meet posted requirements. Companies fill those roles anyway. Hiring managers often know they won't get someone who ticks every box; the posting is a negotiation anchor, not a contract. 81% of U.S. employers have adopted skills-based hiring, up from 57% in 2022. The JD says 15 tools; the interview tests three.

Stop trying to learn Kafka and Flink and Terraform and Kubernetes simultaneously. That's tool chasing, and it's a trap. Double down on SQL, Python, and data modeling. Get your reps in on the stuff that actually gets asked. If you're sharpening the Python side, we put together python interview questions on datadriven specifically around patterns that show up in real loops, not obscure trivia nobody's ever tested on in an actual interview.

Optimize your resume for the three or four tools the team actually uses, not the 15 they listed. Don't match fiction with fiction. If a job description has more than six or seven distinct tools in the requirements, odds are it was committee-built and nobody on the actual team uses all of them. That's not a signal to disqualify yourself; it's a signal that the company will hire for the core and train for the periphery.

Strip back the scope anxiety. Senior and staff titles are converging on the same JD with $10K salary deltas. On paper, there's nowhere to grow. But in practice, the engineer who can debug a production incident, model a clean schema, and explain their design decisions under pressure is the one who gets hired and promoted. That hasn't changed in 15 years of data engineering, and it won't change because someone added "LLM integration" to a posting.

Three staff engineers, 40+ combined years, and none of us passed a single job description. That should liberate you, not discourage you. The posting is fiction. Your skills are real. Know the difference, apply anyway, and let the interview sort it out.

What's the most absurd set of requirements you've seen crammed into a single data engineering posting?

AI Is Cutting DE Jobs. It's Also Creating Them. Here's the Map.

DataDriven — Tue, 07 Jul 2026 10:07:35 +0000

I watched a friend get laid off from Meta's analytics org on a Tuesday. By Thursday, Meta had posted six new roles in their "Applied AI Engineering" unit that required almost identical pipeline experience. Different title. Different budget line. Same category of work, but pointed at LLMs instead of dashboards.

That's the game right now. And most people don't have the map.

52,050 Cuts. 23% Hiring Growth. Both Are True.

Q1 2026 produced 52,050 tech job cuts, the highest Q1 total since 2023; a 40% jump over Q1 2025. Of those layoff events, 56% explicitly cited AI as the reason. Meta cut 8,000 people. Intuit eliminated 3,000 (17% of their workforce). PayPal axed 4,760 (20%). Salesforce trimmed under 1,000 from data analytics and product management.

And yet: data engineering hiring is up 23% year-over-year, with roughly 260,000 open US positions projected for 2026. The data engineering market hit $105 billion this year and is projected to reach $213 billion by 2031.

These aren't contradictory numbers. They're describing two different jobs that happen to share a title.

The version of data engineering that was "connect source A to warehouse B using tool C" is getting automated. The version that involves distributed systems, governance, cost optimization, and AI infrastructure is in acute shortage. If you're a mid-level engineer watching both headlines and feeling whiplash, it's because you're standing on the fault line between a role that's dying and one that's exploding. The World Economic Forum forecasts 100% growth in big data specialist demand through 2030. Meanwhile, 63% of employers say they can't find qualified candidates. If supply were truly saturated from all these layoffs, hiring timelines would compress. They haven't. Time-to-hire for data engineers is stuck at 60 to 90 days in enterprise settings.

The paradox resolves when you stop thinking of "data engineer" as one job.

The Cut-and-Redirect Pattern

Here's what Meta actually did: cut 8,000 employees, then simultaneously moved 7,000 workers into AI-focused units called "Applied AI Engineering" and "Agent Transformation Accelerator." That's not a net reduction; it's a budget reallocation with human casualties.

Atlassian did the same thing at smaller scale: 1,600 jobs eliminated, 800 AI roles posted within weeks. PayPal cut 20% of its workforce while immediately posting for AI infrastructure and ML pipeline engineers. The pattern is so consistent it deserves its own name.

Companies aren't reducing data headcount. They're killing one version of the role and resurrecting another, and the six-month gap between the cut and the rehire is where careers go to die.

Here's the number that should make you uncomfortable: 52.1% of companies making AI-driven layoffs rehired for nearly identical roles within six months. Not identical titles, but identical skill categories. The press release says "AI eliminated these positions." The LinkedIn posting six months later says "seeking experienced data engineers for AI platform." Same budget. Same org chart slot. Different words.

And 55% of business leaders who pulled the trigger on AI-driven cuts now regret the decision, after discovering that AI handles 94% of routine tasks but falls apart on judgment calls. IBM and Ford have been quietly rehiring. Nobody writes a press release about that part.

Anthropic, OpenAI, Cohere, and Mistral hired 6,200 people combined in H1 2026. Record pace. The talent has somewhere to go; the problem is that most displaced engineers don't have the specific skills those roles demand. Roughly 40% of displaced workers land in mid-market companies, 25% become contractors, and only about 15% actually change specialties. The pipeline from "laid off ETL engineer" to "hired AI infrastructure engineer" has a massive leak in the middle.

What AI Actually Made Cheap

Let's be specific about what got commoditized, because vague panic helps nobody.

Basic SQL generation. Text-to-SQL tools now hit about 78% execution accuracy on zero-shot queries. That sounds impressive until you realize one in five queries is silently wrong: hallucinated columns, faulty joins, dropped WHERE clauses, missing tenant scoping. The query runs. It returns results. The results are wrong. Nobody notices for weeks. I've seen this movie before; it used to star junior analysts instead of LLMs. The failure mode is identical; the scale is larger.

Boilerplate ETL scripting. Source-to-target mapping, schema detection, field mapping. Databricks reported that 80% of new databases on their platform are now created by AI agents, up from 30% a year ago. The plumbing got automated. If your entire job was plumbing, you should be worried.

AutoML patterns. Hyperparameter search, basic feature engineering, architecture exploration. Cycles that took weeks now take hours. But AutoML doesn't recognize when the problem framing itself is wrong. It optimizes within the frame you give it; it can't tell you the frame is garbage.

Dashboard maintenance and ad-hoc reporting. Data analyst job openings fell roughly 40% from peak. The "pull this data for me" function is collapsing into self-service AI tooling. Microsoft Copilot, Tableau AI, and their cousins are eating this alive.

Here's what didn't get commoditized: schema evolution decisions. Data contracts. Lineage governance. Cost optimization at scale. Figuring out why your pipeline silently dropped 2M rows last Tuesday and making sure it never happens again. The judgment layer is intact. The mechanical layer is not.

This is why the old advice still holds: concepts transfer across tools; tool knowledge doesn't transfer across concepts. The engineers who spent their career learning "how Airflow works" are in trouble. The ones who spent it learning "how to design systems that don't fail silently" are getting promoted.

The Map: What's Actually Getting Hired

If you're navigating this transition, you need specifics, not vibes. Here's where the hiring is happening, and what it pays.

MLOps and AI infrastructure. Salaries range $130K to $257K, with LLM deployment experience consistently pushing past $200K. AI infrastructure engineer salaries jumped 15 to 30% in H1 2026, averaging $320,000 in San Francisco. This is the hottest category by far, and it's not close.

Streaming and real-time systems. $114K to $137K average. I still think streaming is overrated for most companies (most of y'all don't need it), but the ones that need it are paying well and hiring fast. Confluent cut 800 employees; Databricks had 840 open requisitions the same month and actively recruited from that pool. That's not market equilibrium; that's targeted talent consolidation.

Data governance. Over 6,500 open governance roles in the US, averaging $113K annually. GDPR pressure, AI governance requirements, and the realization that you can't ship AI products on dirty data are driving this. Not the sexiest work. Pays reliably.

FinOps and cloud cost optimization. $98K to $167K for cloud FinOps roles. Every company that went all-in on cloud compute is now discovering the bill. They need people who understand both the data and the economics. If you consider the cost of running unoptimized pipelines versus the cost of the engineer's time optimizing them, the economics clearly favor hiring the engineer.

What's conspicuously absent from the hiring surge: junior-to-mid-level generalist data engineers. The 23% growth is concentrated at the senior-specialist tier. Engineers under 30 saw the greatest decline. Job descriptions are collapsing three roles into one: platform engineering, ML pipeline support, and governance orchestration. That's scope creep masquerading as demand.

The Comp Bifurcation

Now here's the part nobody talks about honestly. The AI salary premium over traditional DE roles widened from 25% in 2024 to 56% in 2026. A traditional ETL developer averages $145K. An AI/ML engineer averages $173K to $193K base. LLM specialists command $220K to $280K. Frontier lab researchers clear $600K.

FAANG senior data engineer total comp sits at $250K to $350K, with stock composing more than half the package. Non-FAANG senior comp: $105K to $175K. Stripe pays about $210K for senior DE, which sounds great until you realize it's still 33% below Google's floor. Even at the 95th percentile of non-FAANG, you're hitting the 25th percentile at Google.

The real dividing line isn't FAANG versus startups. It's equity-heavy jobs versus equityless jobs. A data engineer at Meta L5 makes roughly $350K all-in with about $250K from RSUs vesting linearly. A data engineer at a healthcare company makes $140K all-cash with no equity. One of these paths builds generational wealth. The other one consumes it.

A $150K ETL architect doesn't become a $320K AI infrastructure engineer without 12 to 18 months of intentional retraining. The skills are orthogonal, not adjacent. That's the structural trap nobody in HR wants to acknowledge.

So what do you actually do about it? Stop treating this like a tool problem. Data modeling, distributed systems thinking, cost optimization, governance: these are the concepts that transfer. The specific AI tools will change in 18 months. They always do. I've been through three waves of "data engineering is getting automated away." Still here. Still employed. Still debugging the same categories of problems, just with fancier abstractions on top.

Interviewing is a separate skill from the actual job, and the bar has shifted. If you want to pressure-test where you stand, that's exactly why we built out our datadriven.io data engineer interview questions around architectural thinking and system design rather than tool trivia; the roles getting hired today require a fundamentally different interview prep than the ones getting cut.

The engineers who survive this transition won't be the ones who learned the most AI tools. They'll be the ones who understood the problems well enough that the tools didn't matter. Junior engineers worry about which tool to learn. Senior engineers worry about which problems to solve. Staff engineers worry about which problems to prevent.

Figure out which category you're in. Then move up.

What's the biggest shift you've noticed in DE job descriptions over the last year? I'm curious whether the bifurcation looks the same from inside healthcare, fintech, and pure tech, or if it's playing out differently by industry.

Data Engineer LeetCode: What to Grind and What to Skip

DataDriven — Fri, 03 Jul 2026 17:06:34 +0000

I spent about 80 hours grinding LeetCode before my first FAANG data engineering loop. Binary trees, dynamic programming, graph traversal. I could reverse a linked list in my sleep. Then I walked into the interview and got asked to deduplicate a fact table with late-arriving records, design a pipeline for slowly changing dimensions, and write a window function I could have done in 10 minutes if I hadn't been so sleep-deprived from memorizing Dijkstra's algorithm the night before.

I bombed it. Not because I wasn't prepared. Because I prepared for the wrong test.

That was years ago, and the gap between what LeetCode tests and what data engineering interviews actually screen for has only gotten wider. In 2026, candidates are still burning hundreds of hours on problem types that virtually never surface in DE loops, while the skills that actually separate hire from no-hire get treated as afterthoughts. SQL fluency, data-manipulation Python, pipeline design thinking. That's where offers come from. Not from memorizing Dijkstra's.

Let me save you some time.

The LeetCode Mismatch Nobody Talks About Honestly

Here's the math that should make you angry: there are over 3,000 problems on LeetCode. The vast majority test binary tree traversal, dynamic programming, graph algorithms, and backtracking. Data engineering interviews rarely touch any of those categories.

62% of organizations prohibit AI use in technical interviews, while 76% of actual data engineering work is now enhanced by AI tools. So the interview tests skills the job doesn't use, in conditions the job doesn't impose. If an AI can spit out a clean solution to a medium LC problem, what does asking that problem actually tell anyone about the candidate? The signal has always been thin. Now it's basically noise.

The industry knows this. Between 2023 and 2026, the DE role shifted from "batch ETL plumber" to a blend of real-time architecture, cloud cost optimization, metadata governance, and platform engineering. None of that correlates to your ability to implement a trie. Companies are starting to act on it: Airbnb's loop dropped dedicated coding puzzle stages in favor of pipeline design rounds. Meta replaced traditional LeetCode screens with staged CodeSignal scenarios. Google now hands candidates multi-file codebases for refactoring instead of isolated algorithm puzzles.

But candidates? Still grinding binary trees at 2am.

The research is clear: 35 to 50 problems is sufficient for most data engineering roles. 10 to 15 easy, 20 to 25 medium, 5 to 10 hard. That's it. Skip trees, linked lists, graphs, and backtracking entirely unless a specific company tells you otherwise. Stick to arrays, hash maps, string manipulation, and sliding windows. These are the patterns that actually transfer to data work; the rest is noise you're studying to feel productive.

Dynamic programming is nearly useless for DE work but still appears in prep checklists. Most DP problems aren't applicable in real-world settings, yet candidates grind them out of habit, wasting 20 to 40 hours on dead-end prep. I know because I did exactly that. I memorized the knapsack problem. Never once used it. Not once.

The best data engineers often aren't strong at algorithm puzzles. The reverse is also true. Stop optimizing for the wrong metric.

SQL Is the Real Interview Gate

SQL appears in 69 to 79% of data engineer job postings. It shows up in 85% of full interview loops. Window functions appear on roughly 80% of technical screens. If you can't write ROW_NUMBER() or a rolling average with OVER(PARTITION BY ...) cold, you're going to struggle at any data-adjacent role. These aren't advanced anymore. They're table stakes.

The patterns that actually gate candidates are narrower than most people assume.

Window functions. ROW_NUMBER() vs. RANK() vs. DENSE_RANK(). Getting the wrong one when ties exist cascades into broken analytics. LAG and LEAD for sessionization and gap detection. This is the single skill that separates junior from intermediate in the eyes of most interviewers.

CTEs. Interviewers no longer accept nested subqueries as a clean approach. Break your logic into named steps. If your query reads like a paragraph instead of a matryoshka doll, you're already ahead of 60% of candidates. When I tried to submit my first bit of SQL to my code repository, the response I received must have been longer than the code submitted. I didn't understand the value of readability. I do now.

Join-grain awareness. One in three real SQL rounds opens with a problem where candidates inflate revenue by 3x because they joined at the wrong grain. The number one failure mode isn't syntax; it's not understanding the cardinality of the relationship before writing the JOIN.

Deduplication. If you're slapping DISTINCT on a query to hide a problem instead of solving it, the interviewer noticed. Use ROW_NUMBER() to deduplicate on a composite key. Know when your data has duplicates because of the source vs. because of your join.

NULL behavior. This one is a silent killer. A single NULL in a subquery makes NOT IN return zero rows. Not the filtered set you expected; zero rows. This defeats roughly one in five candidates. Use NOT EXISTS instead. It handles NULLs correctly and it's what your interviewer wants to see.

Here's what most candidates miss: clarification beats speed. If the question says "find the latest order," does "latest" mean by timestamp or by ID? Candidates who jump straight to coding burn 20 to 30 minutes solving the wrong problem. The ones who ask two questions first finish in 10.

Phone screens use 2 to 3 conceptual questions. On-sites use 4 to 6 hands-on problems. No binary trees. No DP. Just window functions, CTEs, grain, and dedup. That's the SQL interview study plan.

Python Rounds Want a Data Brain, Not an Algo Brain

Python appears in 74% of data engineer job postings and is required for senior roles. But the Python that matters in a DE interview is completely different from what SWE screens test.

Uber's data engineer screen asks candidates to transform transaction datasets and calculate custom metrics using Pandas. Stripe emphasizes clean, efficient Python with a focus on data structures and SQL first, then scalable pipeline design. No graph traversal. No dynamic programming. The actual screening questions look like work you'd do on the job: parse a messy log file, deduplicate records on a composite key, sessionize an event stream, walk a nested JSON structure.

Most candidates don't fail because they can't write Python. They fail on the one malformed row in a file of ten million. The interview tests whether you think about validation, error handling for bad data, and what happens when a field is missing or the wrong type. Can you quarantine bad records and keep the pipeline running? Or does your code silently drop 40% of rows because you assumed clean input?

I've seen candidates crush 100 LeetCode problems and then stumble on a composite-key deduplication task. They memorized algorithms; they never learned to think about data. The skills that gate most DE candidates (window functions, idiomatic Pandas, JSON schema handling, idempotent upsert logic) are entirely absent from the "hard" LeetCode catalog.

Here's the counterintuitive thing: SQL fluency now outweighs Python sophistication for most loops. Clean, efficient SQL signals maturity within 10 minutes. Advanced Python (decorators, asyncio, metaprogramming) rarely surfaces. If you have limited prep time, put 40% into SQL, 30% into Python data manipulation, 20% into system design, and 10% into behavioral. That split comes from analyzing actual interview loops, not from some prep course syllabus.

For the PySpark and data-manipulation side specifically, we put together targeted drills for exactly this kind of prep; datadriven.io is good for pyspark practice and the pattern-matching that actually transfers to live screens, so you're not wasting reps on algorithm trivia.

System Design Replaced the Algorithm Round

Here's the shift that caught everyone off guard: system design expectations moved down the seniority ladder. What used to screen only senior engineers now appears at mid-level interviews. Airbnb's final loop includes 5 to 7 rounds with 1 to 2 system design rounds heavily weighted for leveling decisions. At Meta, it's the highest-weighted round in modern senior loops. At Databricks, you're designing real-time fraud detection using Spark Structured Streaming, Kafka, and Delta Lake.

But DE system design isn't SWE system design. Strip back the "system design for software engineers" mentality. You don't need to hand-roll a message broker or explain Paxos consensus. You need to reason about slowly changing dimensions, schema drift handling, idempotent writes, and which warehouse suits the cardinality and latency profile of the problem. This knowledge comes from building pipelines, not reading papers.

71% of engineering leaders report AI is making it harder to assess candidates, which is accelerating the format shift. The old playbook (memorize algorithms, speed-run solutions, pray the interviewer asks something you've seen) is dying. The new playbook rewards systems thinking, cost reasoning, and the ability to navigate ambiguity. Communication, narration, and reasoning under pressure are now the primary differentiators; not whether you can implement quicksort from memory.

The candidates who get offers aren't the ones with perfect algorithm solutions. They're the ones who ask the right questions before writing anything. "What's the expected data volume? How fresh does the downstream consumer need it? What happens when the upstream schema changes without warning?" A candidate who stumbles on a medium-easy coding problem but reasons clearly through pipeline architecture gets hired over the person who solves the algorithm perfectly but can't articulate a single tradeoff.

Data modeling is the quiet kingmaker here. It's the most important part of any data engineering interview, and if you nail the technical coding but stumble on modeling, you likely won't get the offer. Getting the model wrong upstream means everything downstream is pain. I've watched people with 10 YOE get downleveled because they couldn't articulate schema design decisions under pressure. The interview is a different skill than the job.

Junior engineers worry about which tool to learn. Senior engineers worry about which problems to solve. Staff engineers worry about which problems to prevent.

The data engineering interview in 2026 tests whether you can think, not whether you can memorize. DP, binary trees, and graph algorithms burned hours of my life that I'll never get back. Window functions, CTE fluency, data-manipulation Python, and pipeline design thinking are what got me hired. Repeatedly.

If you're in the middle of a job search right now, reclaim your prep time. Drop the hard LeetCode grind, double down on SQL patterns and pipeline architecture, and treat interviewing like the separate skill it is. The tools change every 18 months. The problems don't. Schema drift, late-arriving data, upstream teams breaking contracts without telling you. These are eternal. Study the eternal stuff.

What's the single interview question that caught you most off-guard in a DE loop? The ones nobody warned you about are the ones worth sharing.

DE Interviews Dropped DSA. The Replacement Is a Mess.

DataDriven — Tue, 30 Jun 2026 10:07:17 +0000

I did somewhere around 20 interview loops in a single job search. Some tested me on binary trees. Some tested me on pipeline architecture. One company asked me to build a full data warehouse from scratch in a take-home, then ghosted me. Another had me whiteboard a Spark optimization problem, then admitted in the debrief that they don't use Spark. The only consistent thing about data engineering interviews in 2025 and 2026 is that nothing is consistent.

The industry quietly dropped DSA rounds from DE hiring pipelines. You'd think that would be good news. Data engineers don't implement Dijkstra's algorithm at work. We debug pipelines that silently drop records, negotiate schema contracts with upstream teams who don't know we exist, and model data so finance can build board decks without calling us at midnight. LeetCode mediums were always an imported ritual from software engineering, never validated for our work.

But here's the thing nobody warned you about: the replacement is worse.

Why DE Interviews Ever Tested DSA

Data engineering solidified as a distinct role somewhere around 2015 to 2020. That's recent. Software engineering has 40+ years of structured interview evolution. When companies needed to hire DEs, they didn't design DE-specific screening. They copy-pasted the SWE playbook. LeetCode reached a million users within two years of launch, and suddenly every technical role in tech was getting filtered through binary tree traversals and dynamic programming problems.

The logic was lazy but understandable: "Smart people can solve algorithm problems. We want smart people. Therefore, algorithm problems." Nobody asked whether the signal was relevant. 78% of developers report that interview assessments don't match real-world job work, and 56% say algorithm questions are "not useful for their jobs." For data engineers, that number should be higher. We rarely write complex algorithms from scratch; we use pre-built libraries and frameworks. The skill is knowing which tool to reach for and how to model the data correctly, not implementing a red-black tree.

Inertia kept DSA in place for years. Not evidence. Algorithm interviews are easy to design, easy to administer, and easy to score. They have clear right answers. They let hiring committees feel rigorous without doing the hard work of defining what "good DE" actually looks like. Seven out of ten companies were still screening data engineers the same way they did in 2022, even as the role itself morphed from "batch ETL plumber" to something combining real-time architecture, cloud cost optimization, metadata governance, and AI integration.

Then AI made the whole thing absurd. If Claude can solve a medium LC problem in seconds, what does asking it tell you about the candidate? Companies like Meta, Google, Canva, and Shopify started permitting AI use in live technical sessions. Canva replaced their "Computer Science Fundamentals" round with "AI-Assisted Coding" in mid-2025. The premise that raw algorithmic ability was being measured collapsed overnight.

DSA was never the right test for data engineering. It was the convenient one. And when convenience stopped working, nobody had a Plan B.

What Companies Replaced the LeetCode Round With (And Why It's a Mess)

Here's where the story 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.

Some companies pivoted to system design rounds. Fine in theory; pipeline architecture is genuinely relevant to the job. But system design has no rubric. No "correct" answer. Every interviewer has a different opinion on whether you should optimize for cost, latency, or data freshness. At least with LeetCode, everyone agreed what a good answer looked like. System design is subjective hell, and candidates walk out of those rounds with zero idea whether they passed.

Other companies went all-in on take-home projects. These started as 2 to 3 hour exercises and ballooned into 10 to 20 hour ordeals: full pipeline implementations, multi-source data modeling, documentation, testing, and presentation follow-ups. That's not an interview; that's free proof-of-concept work. And the rejection email is still a template with no feedback.

Here's the part that should make you angry: take-homes are worse for equity than live coding. A structured live interview can be leveled with a rubric. A 20-hour take-home is a time tax that penalizes caregivers, people working second jobs, and anyone without unlimited buffer hours. Companies adopted take-homes thinking they were more fair. The irony is thick.

The numbers paint the chaos clearly. SQL shows up in 85% of loops. System design in 65%. Python in 70%. Data modeling in 55%. Take-homes in about 25%. Enterprise hiring timelines now stretch 60 to 90 days with 5 to 7 rounds, while the best candidates leave the market in 10 to 14 days. The process is optimized for companies feeling thorough, not for actually hiring.

And the single most important DE skill, data modeling, is missing from two-thirds of interview loops. Only about 33% include a dedicated data modeling round. You can nail the coding, ace the system design whiteboard, and still lose the offer because you stumbled on modeling. But nobody told you that was the real test, because it's buried inside other rounds instead of being evaluated explicitly.

The role definition chaos explains the interview chaos. Between 2023 and 2026, the industry moved DE from "batch ETL" to a role combining real-time architecture, AI pipelines, metadata governance, and cost optimization. Companies testing SQL plus system design plus AI-assisted builds are simultaneously hiring for three different job titles. No wonder candidates prep for interviews that don't exist once they're hired.

AI Broke the Fallback Too

Take-homes were supposed to be the safe harbor. Let candidates work in their natural environment, at their own pace, showing real engineering judgment. That premise died when LLMs got good enough to build a passable data pipeline in 20 minutes.

The numbers are damning. 80% of candidates use LLMs on take-home tests despite explicit prohibition. AI-assisted cheating adoption jumped from 15% in June 2025 to 35% by December 2025, and by late 2026 it's headed past 50%. In unproctored take-home formats, estimated fraud rates sit between 60% and 80%. And 61% of cheaters scored above passing thresholds without detection.

Companies responded with policies that are pure theater. 64% of companies attempt to ban AI in interviews, but there's zero correlation between having an explicit no-AI policy and lower cheating rates. The 80% use-despite-ban number tells you everything: candidates view bans as unenforceable, because they are. Tools like Cluely and Final Round AI cost $20 to $50 a month and feed answers via invisible screen overlays. Keystroke dynamics, perplexity scoring, gaze tracking; every detection method has documented, production bypasses.

Greenhouse's June 2026 report found 80% of US candidates say employer AI policies are vague, rare, or completely absent. Companies blame candidates for guessing; candidates blame companies for silence. Meanwhile, 41% of companies now require a hybrid model: asynchronous take-home plus live defense session, specifically because unproctored take-homes alone produce no reliable signal. That's not marketed as "AI-proofing." It's just the new floor.

The job market itself is training candidates to cheat. When 30% of candidates drop out of hiring processes after discovering AI-led screening, and take-homes are the fallback, the lesson is clear: assume no human will review this carefully and act accordingly. The policy vacuum creates the behavior.

64% ban LLMs. 80% use them anyway. That's not a policy; it's a suggestion.

What to Actually Prep for When the Interview Has No Standard

I'll be blunt: the chaos is the prep. You can't study for a standardized loop because there isn't one. But you can build a stack of skills that covers the majority of what companies actually test, regardless of which format they chose this quarter.

SQL is still the universal filter. It appears in 85% of loops. Not "write a SELECT statement" SQL; deep SQL. Window functions, CTEs, query optimization, understanding execution plans. This is the one skill that transfers across every company and every format, which is exactly why we made sure DataDriven is good for sql interview practice that reflects what companies actually ask rather than textbook exercises disconnected from real pipelines.

Data modeling is the hidden pass/fail. It's only an explicit round in a third of loops, but it's the implicit evaluation in every system design and take-home. Getting the model wrong upstream means everything downstream is pain. Practice designing schemas for real business scenarios: slowly changing dimensions, event streams, aggregation trade-offs. If you can't explain why you chose a grain, you're not ready.

System design means pipeline architecture, not load balancers. Strip back the "system design for software engineers" mentality. DEs don't care about reverse proxies. You need to design ingestion, transformation, serving layers, and failure handling. Practice narrating your design decisions out loud. The signal in system design rounds is communication under ambiguity, not arriving at the "right" architecture.

Learn to debug, not just build. The actual job is less "write a DAG" and more "figure out why this pipeline silently dropped 2M rows last Tuesday." Schema drift, late-arriving data, upstream teams breaking contracts without telling you; these are eternal. No interview tests for this explicitly, but candidates who can reason about failure modes stand out in every format.

Treat interviewing as a separate skill from the job. I've watched people with 10 YOE get downleveled because they couldn't articulate system design decisions under pressure. The career progression from senior to staff depends on your ability to communicate tradeoffs, not just execute them. Practice talking through your work. Record yourself explaining a pipeline you built. It feels stupid. It works.

The LeetCode era had one advantage: predictability. You knew the game, you ground the reps, you played to win. The post-DSA era took that away without replacing it with anything coherent. That's frustrating. It's also the reality.

The companies that figure this out first will attract the best talent. The ones still running 7-round loops with no rubric and 20-hour take-homes will keep wondering why their offers get declined.

What's the most absurd interview format you've encountered since companies started dropping DSA rounds?

Data Engineer Salaries in 2026: The Numbers Are Lying

DataDriven — Thu, 25 Jun 2026 10:07:39 +0000

Last year I was helping a friend prep for senior data engineer interviews. He'd been building pipelines at a Series B for four years, solid production experience, and wanted to know what number to put in the salary field. So he did what everyone does: checked Glassdoor, Indeed, PayScale, and Levels.fyi.

He got four numbers. They disagreed by over $120,000.

Glassdoor said $133K. PayScale said $100K. Indeed's senior number sat at $216K. Levels.fyi split the difference at $157K. Same title, same country, same year; four answers that can't all be right. And here's the thing: none of them are lying. They're just counting different people, over different time windows, with different biases baked in. The result is that candidates trying to benchmark their data engineer salary are pricing themselves against a number that doesn't represent their actual market.

This is a problem. In a hiring environment where 52,050 tech workers got laid off in Q1 2026 alone, where senior roles take 60 to 90 days to fill, and where title inflation has made "data engineer" mean three different jobs depending on who's posting, getting your number wrong has real career cost. You either leave $30K on the table or you overshoot and get ghosted. Both outcomes trace back to the same root cause: the data you're benchmarking against is broken.

Why Every Salary Site Disagrees by $120K

Each major compensation source has its own rot problem. Understanding the bias is more useful than trusting the number.

Glassdoor reports $133,484 average across 32,984 submissions. The issue: it's entirely self-reported, and higher earners submit more frequently. The person who just got a $180K offer is more motivated to log it than the person who accepted $115K and moved on. The sample skews up.

PayScale reports roughly $100K. That sounds low because it is; 71% of their data engineering respondents are mid-level or junior. PayScale validates every data point and refreshes on sub-90-day cycles, which makes it the most accurate floor for what actually clears at offer stage. But candidates see $100K and panic. They shouldn't. They're looking at a junior-weighted average.

Indeed sits at $216K for senior roles. The problem here is temporal: Indeed averages job postings going back 36 months. Their June 2026 number includes postings from June 2023, before the layoff waves, before signing bonus compression, before the market shifted. You're benchmarking against fossil data.

Levels.fyi pegs the median at $157,450, but this population skews heavily toward top-tier tech companies and excludes non-tech firms where data engineers earn 20 to 35% less. Google's median is $278K. Capital One's is $130K. That's a $148K spread for the same title on the same platform.

The salary data isn't wrong. It's measuring different populations, different time windows, and different definitions of the job. Once you know which population you're in, the number becomes useful. Until then, it's noise.

The practical damage is real. A mid-market data engineer sees Glassdoor's $133K, anchors there, and never learns that the number includes FAANG outliers pulling the average up. Or worse, they see Indeed's $216K senior figure and counter-offer at a number that makes the hiring manager close the tab.

Role Title Chaos Is Pricing You Against the Wrong Pool

Here's the less obvious problem: the job you're benchmarking might not even be the job you're doing.

Analytics engineers earn $155K to $195K median in 2026. ML engineers command a 38% salary premium over data engineers at mid-career. Data scientists occupy yet another band. These are different roles with different compensation structures. But companies routinely mislabel them.

Analytics engineer postings grew 114% from 2023 to 2024, yet dbt Labs openly admits the title boundaries are blurring. Analysts drift into dbt modeling. Data engineers adopt dbt as standard tooling. The result: a "$150K dbt role" could be transformation work (analytics engineer) or pipeline infrastructure (data engineer), and the salary sites have no idea which one they're counting.

37,000 data engineering jobs post monthly on average, but a significant portion of those are mislabeled analytics engineer, ML engineer, or data scientist roles. When a company posts "Senior Data Engineer" but the job is really dbt plus Snowflake plus stakeholder dashboards, that's an analytics engineer role at data engineer pricing. The candidate benchmarks against infrastructure DE salaries ($115K to $160K) when they should be benchmarking against analytics engineer salaries ($155K to $195K). That's a $30K to $40K miss.

The reverse kills you too. An analytics engineer who sees ML engineer salary data and anchors at $190K gets rejected as "overpriced" for the actual scope.

The litmus test isn't the title. It's the job description. If it says dbt, Snowflake, and "stakeholder reporting," you're an analytics engineer regardless of what the posting calls you. Benchmark accordingly.

2023 Job Ads Are Still Haunting Your 2026 Number

Indeed's 36-month lookback window deserves its own section because the implications are worse than they look.

In 2023, the median data engineer salary was $117,446. By June 2026, Indeed reports $136,776. That looks like 16.5% growth over three years, which isn't terrible. But the number is being held down by every posting from 2023 and 2024 that's still sitting in the average.

Here's what makes this especially misleading: 68% of tech job postings included explicit salary ranges in 2025, up from 45% in 2023. Pay transparency laws made the data more granular. But Indeed weights all 36 months equally. A vague salary range guess from a 2023 pre-transparency posting counts the same as a precise, legally mandated range from 2026. Higher sample size, stale composition.

Then there's the ghost job problem. One-third of employers admit to posting inactive roles. Greenhouse data found 18 to 22% of listings are never filled. Stale 2023 postings are more likely to be dormant, and they're inflating the denominator. You're benchmarking against jobs that don't exist anymore.

The senior role divergence tells the real story. The $60K gap between mid-level ($133K) and senior ($175K) data engineers in 2026 suggests the market has repriced for experience. But the aggregate average is anchored by fossils. If you're mid-career, the number you see is artificially low.

Layoffs Created a Tier, Not a Glut

52,050 tech workers laid off in Q1 2026. A 40% jump over Q1 2025. Oracle cut 21,000. Amazon cut 16,000. Dell cut 11,000. Sounds like a buyer's market.

It's not. Or at least, not uniformly.

Those 52K cuts coexist with 67,000 active software engineering job postings in the same quarter, the highest posting volume in three years. Companies are cutting commoditized roles while hoarding data engineers, ML engineers, and security specialists. A junior full-stack engineer is in a buyer's market; a senior data engineer with Airflow and Spark experience is not. The "layoff market" narrative breaks down completely by skill tier.

But here's the asymmetry that actually matters: companies take 60 to 90 days to fill senior roles because they're running multiple candidates in parallel. Individual candidates spend 3 to 9 months searching. The employer can wait. The candidate runs out of severance. That's where negotiation leverage shifts; not because the market is soft, but because one side has a deadline and the other doesn't.

The data on negotiation is striking. Data engineers who negotiate earn $24,479 more annually, an 18.83% increase. 85% of counter-offers get at least partial acceptance. 70% of hiring managers expect you to negotiate. Only 44% of candidates actually do it. The $120K gap between salary sources is partly a measurement problem, sure. But it's also partly behavioral. The spread between 25th and 75th percentile reflects negotiation winners vs. passive accepters, not just market fragmentation.

Engineers with current cloud and security skills close offers in 2 to 4 weeks. Everyone else faces the full timeline. Skill specificity determines leverage more than market conditions.

What Number to Actually Put in the Field

Stop averaging the averages. Here's the hierarchy of sources, from most to least useful for your career planning:

Levels.fyi is best for FAANG and top-tier tech. Filter by company, level, and location. The by-company variance is massive ($278K at Google vs. $130K at Capital One), so the aggregate median is useless. You need the company-specific number.

Glassdoor is useful for the 25th to 75th percentile range at your target company, if they have enough submissions. The $141K to $219K senior DE range tells you more than the $175K mean.

PayScale is the most accurate floor. If you're at a non-tech company or early in your career, this is closer to your reality.

Indeed is the least useful for current benchmarking. The 36-month window buries the signal.

The actual number you put in the field should be the Levels.fyi or Glassdoor 75th percentile for the specific company, then negotiate. If 70% of hiring managers expect negotiation, pricing yourself at the median is pricing yourself to get negotiated down.

And one more thing the salary sites never show you: base salary is barely over half the employer's total cost to hire. That $200K base offer costs the company $240K to $290K when you add payroll tax, benefits, recruiting fees (18 to 25% of first-year base), and onboarding ramp. They have more room than you think. The question is whether you know enough about your own market to ask for it.

If you're prepping for the senior and staff loops where compensation actually diverges, strip back the "system design for software engineers" mentality; we built system design for data engineers with datadriven around pipeline architecture problems, not the load-balancer trivia that SWE prep loves and DEs never face on the job.

The salary data is broken. The titles are broken. The timelines are longer. None of that changes the fact that data engineering compensation is strong and growing for engineers who know what they're actually worth. The trick is figuring out which population you belong to, not which average to believe.

What's the biggest gap you've seen between what a salary site reported and what you actually earned or were offered?

Your Data Engineering Take-Home Is Now 20 Hours of Free Work

DataDriven — Tue, 23 Jun 2026 21:15:44 +0000

I got a take-home assignment last year from a company I was genuinely excited about. "Should take about four hours," the recruiter said. Build an ingestion pipeline, model the data, write tests, document your design decisions, and prepare a 15-minute presentation walkthrough for the panel. Four hours. I laughed, closed my laptop, and started on it the next morning like it was a sprint. Sixteen hours later I had something I was proud of. Clean pipeline, solid tests, real documentation. I submitted it on a Sunday night. Monday I got a form rejection. No notes. No feedback. Not even which stage I failed. Just "we've decided to move forward with other candidates" and a link to their Glassdoor page.

That was the moment I stopped pretending take-homes are assessments. They're consulting gigs. Unpaid ones.

The Scope Creep Nobody Talks About

Five years ago, a data engineering take-home was a focused exercise. Model this dataset into a star schema. Write a few SQL transforms. Maybe a short README. Two to four hours, tops. Bounded, reasonable, and actually useful for evaluating how someone thinks about data.

That version is dead.

Today, 68% of companies use take-home tests, up 12% year over year. And the scope has quietly ballooned into something unrecognizable. Full pipeline implementations. Test suites with coverage thresholds. Documentation that reads like a design doc. A presentation follow-up where you defend your architecture to a panel. We're talking 10 to 20 hours of work, routinely, for a role you haven't been offered.

Industry best practice caps take-homes at 90 minutes of expected effort. The reality? Candidates consistently take 2x longer than company estimates to reach submission quality. That "four-hour" assignment is an eight-hour assignment. That "weekend project" is a week of evenings. And 25% of companies are still handing these out like they're reasonable asks.

Here's the part that makes my eye twitch: 71% of engineering leaders openly say take-homes no longer generate useful signal. AI has degraded the format so completely that leaders themselves rate take-home signal as "degrading fastest" among all assessment types. They know it's broken. They keep doing it anyway.

The attempted fix is even worse. Companies panicked about AI usage and responded by inflating scope. The logic, if you can call it that: make the assignment so large that AI can't do it alone. Except longer assessments don't defeat AI; they defeat candidates. Candidates with kids. Candidates working full-time jobs. Candidates from non-traditional backgrounds who can't burn 20 hours on a maybe. One candidate documented spending 32 hours on a single assignment, then got rejected for omitting a feature that was never mentioned in the requirements. Another was asked to build a learning module that would've billed at $2,800 as freelance work.

A four-hour take-home is a fair test. A 20-hour take-home is free consulting dressed up as an interview.

59% of job seekers now say unpaid take-home assignments are the number one reason they won't apply. Not comp, not culture, not location. The assessment itself is the dealbreaker.

AI Banned, Rubrics Unchanged

Two thirds of companies ban AI use in their interview process. Sounds decisive. Except fewer than 30% of those companies have actually updated their assessments or retrained their interviewers. They slapped a "no AI" sticker on a 2015-era take-home and called it policy.

The enforcement gap is almost comical. One company measured 80% of candidates using LLMs on take-home tests despite an explicit prohibition. AI cheating on take-homes doubled from 15% to 35% between June and December 2025. In purely technical roles, 48% of candidates show signs of unauthorized AI use. The ban is a suggestion, not a guardrail.

Meanwhile, the rubrics these companies grade against were built to evaluate raw coding speed and syntax accuracy. Those signals collapsed the moment Claude could produce a clean solution in seconds. But nobody rewrote the rubric. Nobody redefined what "good" looks like when the baseline output quality shifted. Hiring managers score problem-solving and architecture judgment, but the assessment they hand out measures code-from-scratch, a skill that's now commodity.

The split in the industry tells you everything. Meta and Shopify openly invite AI tools into their assessments. They've decided to test "can you use AI well" rather than "can you code without it." Goldman Sachs and Amazon maintain hard bans for candidates while investing heavily in internal AI tools for their own engineers. The hypocrisy is so blatant it's almost impressive. You can't use AI to get hired here, but once you're in, you'd better use it or you're slow.

Banning AI in interviews creates a discontinuity between evaluation and production. In 2026, writing code without AI assistance is the exception, not the norm. You're testing candidates in an environment that doesn't reflect the environment they'll work in. That's not assessment; that's theater.

70% of You Will Never Hear Why

Here's the stat that should make every hiring manager uncomfortable: 69.7% of candidates receive zero feedback after rejection. Not "insufficient feedback." Zero. Nothing. A form email and silence.

61% of candidates report being ghosted entirely after interviews. No rejection, no closure. Just silence from a company that asked them to spend a weekend building a pipeline.

Companies hide behind legal risk. "We can't give feedback because candidates might sue." This is, to put it plainly, nonsense. Employment law distinguishes between subjective rejection reasons ("you seemed low-energy") and factual, role-specific feedback ("your schema migration approach didn't handle the edge case we were testing for"). The second type is almost litigation-proof. No engineer has successfully sued a company over constructive technical feedback. The legal defense is a myth that compliance teams perpetuate because "say nothing" is the lowest-variance strategy. It's organizational laziness wearing a legal costume.

The business case against silence is overwhelming. 79% of candidates would reapply to a company if they'd received feedback. Recruiters who share feedback see a 126% increase in candidate referrals. Companies withholding feedback aren't just being rude; they're burning bridges they'll need to cross again in 18 months when they're hiring for the same role.

But here's the real cruelty. When the assessment demands 10 to 20 hours, and the rejection carries zero feedback, you've extracted labor and returned nothing. Not compensation, not signal, not even a paragraph explaining what to work on. The candidate can't even reuse the learning because there is no learning. It's labor arbitrage dressed up as a career opportunity.

Only 17% of external candidates receive feedback, compared to 65% of internal candidates. If you already work there, you get a debrief. If you're on the outside spending your weekend on their assignment, you get a template. The double standard is institutional.

What Actually Works

The good news: some companies figured this out. The better news: it's not complicated.

Live debugging interviews, running 60 to 90 minutes, are replacing puzzles at companies like Cloudflare, Datadog, and GitHub. Candidates get a broken system. They debug it. Interviewers watch the process: how do you form a hypothesis, how do you narrow the search space, do you narrate your thinking. You're evaluated on engineering judgment, not memorization speed. A candidate who thinks aloud and corrects wrong hypotheses scores higher than one who guesses fast but can't explain why.

For senior and staff roles, pair programming on a debugging or refactoring task is the highest-signal round you can run. Forty-five minutes, real code, real collaboration. It surfaces the kind of judgment that 20-hour take-homes never could, because judgment shows up in conversation, not in a solo sprint nobody watches.

Uber runs a two-hour on-site schema critique instead of toy problems. Stripe bounds their take-homes to one to three hours with clear scope. Both companies report higher completion rates and better signal than the bloated formats they replaced.

The pattern is obvious: bounded time, realistic work, human interaction. If you want to know how someone debugs a broken DAG, hand them a broken DAG and watch. Don't ask them to build one from scratch over a weekend and then ghost them.

If you're a candidate stuck grinding through these loops, focus your prep on the concepts that transfer across every format: data modeling, pipeline architecture, query optimization. I've found that a resource like datadriven.io is good for etl interview questions if you want structured reps on the technical fundamentals without wading through another generic course. The game is arbitrary, but the concepts compound regardless of which format a company throws at you.

The System Knows It's Broken

72% of job seekers report negative mental health impacts from lengthy hiring processes. Candidate ghosting hit a three-year high in 2026. The market has 2.2 million fake openings monthly, candidates respond with AI-powered mass applications, companies respond by banning AI, and the entire system spirals further from producing any useful signal for anyone.

The profession acknowledges the assessment is unreliable while refusing to stop using it. This isn't a transitional phase. It's institutional paralysis. Companies would rather extract 20 hours of free work from someone they'll reject silently than spend 90 minutes on a live session that actually reveals how an engineer thinks.

I've been through enough of these loops to know the system doesn't reform itself. It changes when candidates refuse to participate and when hiring managers with enough authority say "this is stupid, let's stop." If you're in a position to design an interview process, bound the time, provide feedback, and evaluate how people think, not how much free labor they'll tolerate.

If you've done one of these 20-hour take-homes recently: what was the assignment, and did you hear anything back?

The 12 Data Modeling Interview Questions that Matter

DataDriven — Wed, 17 Jun 2026 10:04:25 +0000

I've watched candidates with 8 years of experience go blank when asked to define the grain of a fact table. Not because they're bad engineers; because nobody told them that data modeling is the actual filter. SQL problems test syntax. System design tests memorization. Data modeling tests whether you can think. That's why it's the section that separates senior from staff, and why interviewers keep leaning on it harder every cycle. AI can spit out a medium LeetCode solution in seconds; it still can't explain why your grain decision breaks downstream aggregates.

These 12 problems are the ones I've seen repeatedly across FAANG and late-stage startup loops. They cover star schema design, dimensional modeling tradeoffs, SCDs, late-arriving data, and the classification calls that trip up even experienced candidates.

Want to practice these for real? Solve these problems live here with a real editor and graded solutions.

1. Define the Grain of a Fact Table

The question: You're building an analytics warehouse for a ride-sharing company. Before designing any tables, state the grain of the core fact table. What does one row represent?

The answer is: one row per completed trip. Not per driver. Not per day. One row per atomic trip event, keyed by trip_id, with foreign keys to dim_driver, dim_rider, dim_pickup_location, dim_dropoff_location, and dim_date. Measures include fare_amount, tip_amount, trip_duration_seconds, trip_distance_miles.

Why it matters: Grain is the single most important decision in dimensional modeling. Candidates who jump into drawing tables without stating "one row represents X" are already drifting. Undefined grain causes silent metric inflation, duplicate rows, and join explosions that don't throw errors; they just produce wrong numbers. Interviewers test this first because everything downstream depends on it. The follow-up is always: "What happens when a trip has multiple stops?" If your grain assumed single-destination trips, you just broke your own schema.

2. Star Schema vs. Snowflake Schema

The question: Your team is building a new warehouse on Snowflake (the product). A junior engineer proposes snowflake schema (the design pattern) to save storage. Do you agree? Why or why not?

You don't agree. Star schema is the default for modern columnar warehouses. Snowflake, BigQuery, and Redshift compress denormalized dimensions so efficiently that snowflaking (normalizing dimensions into sub-tables) rarely saves meaningful storage anymore. The engineering overhead of maintaining normalized dimension hierarchies exceeds the storage cost of duplication. Star is the safe opening position in any interview.

Why it matters: Picking snowflake first signals junior thinking. The economics killed the normalization argument around 2024. Interviewers aren't testing whether you know both patterns exist; they're testing whether you can reason about the tradeoff. The follow-up: "When would you normalize a dimension?" The answer is when the dimension is enormous and changes frequently (millions of rows, daily updates), making the redundant writes expensive. That's rare.

3. Design a Fact Table for E-Commerce Orders

The question: Design a star schema for an e-commerce platform. The business needs to track orders at the line-item level for revenue analysis.

CREATE TABLE fact_order_line_item (
    order_line_item_sk  BIGINT PRIMARY KEY,
    order_id            BIGINT,      , degenerate dimension
    product_sk          BIGINT REFERENCES dim_product,
    customer_sk         BIGINT REFERENCES dim_customer,
    date_sk             INT    REFERENCES dim_date,
    quantity            INT,
    unit_price          DECIMAL(10,2),
    discount_amount     DECIMAL(10,2),
    line_total          DECIMAL(10,2)
);

Grain: one row per line item per order. order_id is a degenerate dimension; it lives in the fact table because it has no descriptive attributes worth a separate table.

Why it matters: This tests three things at once. Can you declare grain (line item, not order)? Do you know what a degenerate dimension is? And do you put the right measures in the fact table? Candidates who model at the order grain lose the ability to analyze product-level revenue without restructuring. You can always aggregate up from line items to orders; you can never disaggregate back down.

4. SCD Type 2 Implementation

The question: A customer changes their address. How do you model dim_customer to preserve the old address for historical reporting?

SCD Type 2: insert a new row with a new surrogate key, set effective_date and expiration_date on both rows, and flag the current row with is_current = TRUE. The original row stays intact; historical fact rows still join to the old address via the old surrogate key.

,  Before change
,  customer_sk=101, name='Jane', city='Austin', effective='2024-01-01', expiration='9999-12-31', is_current=TRUE

,  After change: close old row, insert new
UPDATE dim_customer SET expiration_date = '2026-06-16', is_current = FALSE WHERE customer_sk = 101;
INSERT INTO dim_customer VALUES (102, 'Jane', 'Denver', '2026-06-17', '9999-12-31', TRUE);

Why it matters: SCD2 is a separator question. Juniors describe it from the textbook. Seniors bring up the trap: SCD2 row explosion. A dimension with 10M rows tracking frequently changing attributes can balloon to 150M rows in five years. The follow-up is always: "When would you use Type 1 instead?" Answer: when the business doesn't need the history. A corrected typo in a customer name doesn't warrant a new historical row. Type 1 overwrites are often correct, despite Type 2's prestige.

5. Late-Arriving Dimensions

The question: An order fact arrives, but the customer who placed it hasn't been loaded into dim_customer yet. What do you do?

Insert a placeholder row in dim_customer with a surrogate key and all descriptive columns set to "Unknown" or null. The fact row joins to this placeholder. When the real customer data arrives, you overwrite the placeholder via Type 1 update.

Why it matters: Late-arriving dimensions and late-arriving facts are entirely different problems, and mixing them up is an instant red flag. This tests whether you understand that the fact table can't wait; it needs a foreign key now. The alternative (dropping the fact row until the dimension arrives) loses data. The follow-up: "What if the dimension arrives with changes?" Then you might need to apply SCD2 logic to the placeholder row, which gets complex fast.

6. Bridge Tables for Many-to-Many Relationships

The question: A hospital system tracks patient diagnoses. One hospitalization can have multiple diagnoses, and one diagnosis applies to many hospitalizations. How do you model this?

You use a bridge table. Create a diagnosis_group_key that maps to a set of diagnoses in bridge_diagnosis. The fact table (fact_hospitalization) joins to diagnosis_group_key; the bridge table resolves each group to individual dim_diagnosis rows.

Why it matters: Many-to-many relationships in dimensional models are the source of the most dangerous bug in analytics: double-counting. Without a bridge table, a naive join between fact and dimension multiplies rows. Interviewers use this to test whether you understand the cardinality trap. The follow-up: "How do you handle weighting?" If a hospitalization has three diagnoses, does each get 1/3 of the revenue allocation? Bridge tables can carry a weight_factor column for exactly this.

7. Fact vs. Dimension Classification

The question: You have a column customer_lifetime_revenue. Is it a fact or a dimension attribute?

It's both, depending on usage. If you're summing it across rows, it's a fact. If you're banding it into ranges ("$0-$1K", "$1K-$10K") to filter or group by, it's a dimension attribute. Kimball calls this the aggregated-fact-as-attribute pattern.

If you would aggregate the column, it's a fact. If you would filter or group by it, it's a dimension. That's the whole test.

Why it matters: This exposes whether a candidate understands that the fact/dimension boundary isn't about data types. Numeric columns don't automatically belong in fact tables. The follow-up: "Where do you physically store it?" Usually in the dimension, banded into a descriptive range, with the raw number available as an additive fact if needed.

8. Factless Fact Tables

The question: The business wants to know which products were NOT sold in each store last month. How do you model this?

A factless fact table (coverage table). One row per store per product per month, representing eligibility. To find products not sold, you subtract the sales fact table from the coverage table.

Why it matters: Most candidates have never heard of factless fact tables. The name sounds like a contradiction. But they solve a real problem: you can't report on the absence of an event without first modeling what could have happened. Student attendance, product availability, promotional eligibility; these all use the same pattern. The follow-up: "Isn't this just a cross join?" Yes, and that's the point. The cross join defines the universe; the anti-join finds the gaps.

9. Accumulating Snapshot Fact Table

The question: Model an order fulfillment pipeline with stages: ordered, packed, shipped, delivered.

One row per order, with multiple date columns: order_date_sk, pack_date_sk, ship_date_sk, delivery_date_sk. The row gets updated as the order progresses through stages. Null dates indicate incomplete milestones.

Why it matters: This is the "advanced grain" question. Most candidates know transaction facts and periodic snapshots; accumulating snapshots trip them up because the row mutates. The fact table updates in place, which feels wrong if you've been taught that fact tables are append-only. Insurance claims, hiring workflows, procurement cycles; all use this pattern. The follow-up: "How do you handle an order that skips a stage?" That's a null in the milestone column, and your reporting logic needs to handle it.

10. Conformed Dimensions

The question: Sales and marketing each have their own dim_customer table with different definitions. What's the risk, and how do you fix it?

The risk is the CEO gets two different customer counts. Conformed dimensions are shared across fact tables and business units, with identical keys, attributes, and definitions. You build one dim_customer, owned by a central data team, and both domains join to it.

Why it matters: This tests organizational thinking, not just schema design. Split-brain dimensions are how companies end up with "which number is right?" meetings. The follow-up: "What if the two teams need different attributes?" Add them to the same dimension. A wide dimension with 50 columns that both teams trust is better than two narrow dimensions that contradict each other.

11. Normalization vs. Denormalization for Analytics

The question: When would you choose a normalized (3NF) model over a denormalized star schema in an analytics warehouse?

Almost never for the presentation layer. Denormalized schemas achieve 20 to 100x faster query performance on complex analytics workloads by eliminating joins. BigQuery benchmarks show 49% average improvement with fully denormalized tables compared to star schemas. But the staging layer should stay normalized. 3NF in staging preserves flexibility; when requirements change, you can rematerialize the presentation layer without remodeling the entire pipeline.

Why it matters: The real answer is "both, in different layers." Organizations run 3NF in source systems, normalize in staging for integrity, and denormalize in the presentation layer for speed. Candidates who pick one paradigm for the entire warehouse reveal they've never dealt with a schema migration. The follow-up: "What about high-cardinality many-to-many relationships?" Don't denormalize those. A customer/orders/products grain creates explosive row multiplication.

12. Late-Arriving Facts and Backfills

The question: Your daily pipeline processes orders by processing_date. An order from 10 days ago arrives today. How does your pipeline handle it?

Partition by event_time (when the order was placed), not processing_time (when it arrived). Keep a rolling recompute window open; reprocess the last 14 days on every run. This auto-reconciles normal late arrivals without manual intervention. For data outside the window, run an explicit backfill job.

Why it matters: Late data isn't a failure mode; it's the normal case. Most production systems expect 10 to 20% of daily volume to arrive delayed. Candidates who say "drop anything older than 7 days" have never worked on a pipeline that finance depends on. The follow-up: "What if the late fact needs to join to a dimension that has since changed (SCD2)?" You join to the dimension version that was active at event time, not processing time. That's the whole point of surrogate keys and effective dates.

, -

Data modeling questions keep showing up because they're the one thing AI can't fake for you. An LLM will produce a schema. It won't explain why that grain breaks when requirements shift, or defend the denormalization when the interviewer pushes back. If you want structured reps on these exact patterns, i used DataDriven for data modeling interview questions and it was the most efficient prep I found for this category.

Which data modeling interview question would you add to this list? I'm curious what y'all are seeing in loops right now.