AI in Data Engineer Interviews: The 2026 Policy Divide

One DE got rejected from a data engineering interview last year for using Claude to scaffold a pipeline design. Three weeks later, the same engineer got dinged at a different company for not using AI tools during their coding screen. Both rejections came with the same generic email: “We’ve decided to move forward with other candidates.” No explanation. No indication that each company considered the same behavior a cardinal sin in opposite directions. The data engineer interview 2026 landscape lets a candidate do everything right and still lose by guessing wrong about an unwritten rule.

The pattern isn’t theoretical. It is happening right now to strong candidates at companies anyone would recognize. Nobody is talking about it publicly because companies have zero incentive to disclose their policies.

According to Karat’s 2026 engineering interview trends data, 62% of organizations still prohibit AI use in technical interviews. Roughly 4 in 10 companies now allow or encourage it. Those numbers sound manageable until factoring in that there is no public registry, no standard disclosure, and most recruiters either don’t know their company’s policy or won’t share it.

The split isn’t gradual. It is binary. A candidate walks into the Zoom and is either in a world where AI tools are cheating or a world where not using them is a red flag. Formation.dev documented a four-tier framework companies are quietly adopting: Level 1 (all AI prohibited) through Level 4 (full AI integration as a development standard). Most companies haven’t publicly declared which level they’re at. Candidates find out when they pass or fail.

For data engineers specifically, the policy ambiguity hits harder than for general SWEs. DE interviews heavily test SQL optimization, pipeline architecture, and system design, exactly the domains where AI coding assistants excel. Prepping for a data engineering technical interview without knowing which camp the target company falls into means preparing for the wrong test.

Specific companies with active bans, by name:

Amazon updated its technical interview guidelines requiring candidates to acknowledge they won’t use GenAI tools during assessments. Violations can result in do-not-hire status. Not “we’ll mark you down.” Do-not-hire. Permanently. Their internal messaging to recruiters reportedly framed AI use as intellectual dishonesty. The Amazon DE interview guide covers the policy and how it is enforced.

Anthropic (yes, the company that makes Claude) explicitly bans AI tools during hiring. Their pre-interview emails state: “Use of AI tools during this interview is not permitted.” The irony of the company building AI tools banning their use in interviews is not lost on anyone.

Goldman Sachs prohibits ChatGPT and external sources during interviews despite the firm’s substantial internal AI investments and recent AI platform launches.

Google reintroduced in-person interviews after discovering widespread AI-powered cheating during virtual technical assessments. A 21-year-old had created specialized overlay tools enabling real-time answer injection during coding screens. Google’s response wasn’t to embrace AI; it was to bring candidates back into the building.

Amazon reportedly disqualified an entire university’s recruiting pipeline after a single incident where eye-movement patterns suggested AI tool use. They announced they wouldn’t return to that campus for hiring. One person’s decision affected every candidate from that school.

Meta piloted AI-enabled coding interviews in October 2025, replacing one of two coding rounds with a 60-minute session where candidates have access to GPT-5, Claude, Gemini, and Llama 4 Maverick in a specialized CoderPad environment. AI use is “optional,” but not using it leaves signal on the table. The Meta DE interview guide breaks down the full loop.

Canva went further. They explicitly require Backend, ML, and Frontend engineering candidates to use Copilot, Cursor, and Claude during technical interviews. Not “allowed.” Required.

Zapier raised their AI fluency bar between V1 (May 2025) and V2 (March 2026). Clearing “Capable” now requires that candidates show AI embedded in core work, repeatable systems, and clear measurable impact. 100% of new hires must meet their AI fluency standard. Not a suggestion; a gate.

The companies banning AI in interviews are the same companies requiring it on the job. Google has publicly acknowledged its codebase now includes substantial AI-generated code. Amazon deploys AI tools across business workflows. Every data engineering job posting in 2026 lists tools like dbt, Airflow, and Python, all domains where AI code completion is standard practice.

Interview prep that emphasizes writing SQL by hand, from memory, under time pressure, prepares a candidate for a job where day one starts with setting up Copilot in the IDE. The interview is testing a skill the candidate will never use, while ignoring the skill they will use every day.

Three waves of “data engineering is getting automated away” have come and gone. The field is still here. The hypocrisy of testing one skill while expecting another on the job is new. Earlier interview formats at least pretended to test job-relevant skills.

A pipeline debugging scenario any DE would throw at Claude first on the job:

-- On the job: "Claude, why is this deduplication logic dropping valid records?"
-- You'd paste this and ask for the bug.

SELECT
    order_id,
    customer_id,
    order_total,
    ROW_NUMBER() OVER (
        PARTITION BY order_id
        ORDER BY updated_at DESC
    ) AS rn
FROM raw_orders
WHERE rn = 1  -- Bug: can't reference window function in WHERE

Any DE with six months of experience knows the fix: wrap it in a CTE or subquery. In a ban-enforcing interview, that fix has to come from memory. In an AI-enabled interview, the expectation is to prompt for the fix, then explain why it is wrong and verify the correction.

-- The fix: CTE wrapper so the window function resolves before filtering
WITH ranked_orders AS (
    SELECT
        order_id,
        customer_id,
        order_total,
        ROW_NUMBER() OVER (
            PARTITION BY order_id
            ORDER BY updated_at DESC
        ) AS rn
    FROM raw_orders
)
SELECT order_id, customer_id, order_total
FROM ranked_orders
WHERE rn = 1

Same knowledge. Two completely different demonstrations. The company decides which one counts, and they don’t tell the candidate in advance. The CTE practice problems drill exactly this scenario.

Detection is more sophisticated than candidates expect, and changes shape depending on which camp the company is in.

In the ban camp

Interview platforms now log keystroke patterns, monitor browser focus switching, and flag abnormal application switching. Linear keystroke patterns, complex algorithms appearing in short timeframes with nearly zero backspacing or syntax corrections, are the tell of pasted AI code. Normal human response latency is roughly 0.5 seconds; AI users average 2–3 seconds (generation time plus reading time), creating detectable behavioral signatures.

The unsettling result from a controlled CoderPad experiment: candidates using ChatGPT solved 73% of problems correctly, and human interviewers were unable to identify the AI usage post-interview. The detection tools are getting better, but humans still can’t tell. So companies are changing the questions instead.

The new counter-move is constraint variation. “What if you had 10x more data?” “How would this fail under late-arriving data?” “Walk me through what happens when an upstream schema changes.” AI’s initial output breaks under modification. Humans adapt reasoning. That is the primary detection mechanism now.

In the AI-enabled camp

Meta’s evaluation rubric scores four things: Problem Solving, Code Quality, Verification, and Communication. The emphasis on verification is the tell. They want the candidate to prompt, review, run, confirm, and move on. Not just generate code, but catch what AI gets wrong.

One quote from Meta’s internal guidance: “Should use AI, but need to show you understand the code. Explain the output. Test before using. Don’t prompt your way out of it.”

A useful frame: treat AI as an intern, not an oracle. An intern who is fast but occasionally hallucinates table names and invents JOIN conditions that don’t exist.

The answer to “can I use ChatGPT in a data engineer interview” is: it depends, and finding out before walking in is the candidate’s job. The diplomatic ask:

During the recruiter scheduling call:

“Can you clarify what tools are available during the technical screen? I want to prepare appropriately; some companies have specific policies on external resources.”

The framing is diligence, not suspicion. If the recruiter doesn’t know, follow up: “Who should I confirm this with before the interview?”

A role-relevant variant for data engineering specifically:

“In the role, we’d be using AI coding assistants for ETL development and pipeline work. I want to know if the interview evaluates how I’d actually work day-to-day.”

The question shifts from “can I cheat?” to “are you testing the real job?”

When the recruiter won’t answer or doesn’t know, that itself is a signal. A company with unresolved Copilot interview policy ambiguity probably has broader issues with how it evaluates engineering talent. That is a data point for the candidate’s decision, not just the company’s.

Companies that score AI use aren’t measuring prompting speed. They are measuring engineering judgment. For a data engineer in an AI-enabled round designing an idempotent pipeline for late-arriving events, the interviewer watches whether the candidate can take Claude’s scaffold and identify what is missing:

# AI-generated scaffold. Looks clean. What's missing?
def process_events(spark, source_path, target_table):
    df = spark.read.parquet(source_path)

    # Deduplicate by event_id
    deduped = df.dropDuplicates(["event_id"])

    # Write to target
    deduped.write.mode("overwrite").saveAsTable(target_table)

A strong candidate spots at least three problems: mode("overwrite") destroys idempotency for partial failures, there is no handling for late-arriving data that should update existing records, and dropDuplicates without an ordering column is non-deterministic. The AI gave the candidate something that runs. The job is knowing why it will fail at 3am when finance needs the board deck numbers. That is the skill gap between generating code and engineering code. The idempotent pipeline design guide breaks down every pattern needed.

Zapier’s V2 framework makes this explicit. “Capable” requires AI embedded in core work, repeatable systems (not one-off prompts), and clear impact on quality, efficiency, or outcomes. For data engineers, that translates to: can the candidate articulate how AI fits into their pipeline development workflow, not just their interview performance?

Readiness for either camp means splitting prep time between two opposite skills.

Weeks 1–2: fundamentals without a net

Close the AI tools. Write SQL from scratch. Build practice problems without autocomplete. The goal isn’t to prove independence; it is to ensure every line of code is explainable. This is insurance against the ban camp.

Focus on the concepts interviewers probe when they suspect AI use: why a particular join strategy was chosen, how a query behaves at 10x scale, what happens when a partition key has high cardinality. Constraint variation is the detection mechanism. Surviving it requires actually understanding the code.

Weeks 3–4: AI as a pair programmer

Open the tools back up, with a different usage pattern. Practice the rhythm Meta’s interviewers look for: prompt, review, run, confirm, explain. Time the process not on how fast code gets generated, but on how quickly the candidate identifies what is wrong with the AI’s output.

Build a personal checklist: Does this handle nulls? Is this idempotent? What happens with late-arriving data? What is the implicit grain? Does this join create a fan-out? Those are DE-specific questions that AI consistently gets wrong and interviewers consistently ask about.

Throughout: ask every recruiter

Use the scripts from the ask-the-recruiter section. Every company, every loop. Track which camp each company falls into. Patterns emerge by industry, company size, and geography. Karat’s data shows Chinese companies are 2x more likely to allow AI in live interviews compared to US/Western companies for any international job search.

The honest question: if an AI can spit out a clean solution to a medium LeetCode problem, what does asking that problem actually tell the interviewer? That the candidate memorized something a machine produces on demand? Hiring panels have interviewed data engineers for years and the signal was always thin. Now it is basically noise.

The companies that adapted (Meta, Canva, Zapier) test something real: can the candidate think critically about code they didn’t write, catch errors a machine made, and explain trade-offs under pressure? That is closer to the actual job than anything earlier formats measured. The actual job is less “write a DAG” and more “figure out why this pipeline silently dropped 2M rows last Tuesday.”

The companies still banning AI aren’t wrong to want fundamentals. They are wrong to pretend 2024 interview formats still measure anything meaningful when 80% of candidates are suspected to use LLMs on top-of-funnel tests despite explicit bans. The bans aren’t working. Everyone knows it. Nobody is saying it.

65% of HR professionals believe companies should disclose AI use policies to candidates. Most don’t. Until they do, a binary bet attaches to every coding screen. The good news is the candidate can ask. The better news is preparation can cover both. The best news is the core skill is the same either way: understand the data, understand the system, know why things break. Concepts transfer. Tools don’t. That hasn’t changed.