AI in Data Engineer Interviews: Banned, Allowed, or Graded?

I sat on a hiring panel recently where 4 senior engineers spent 40 minutes arguing about whether a candidate had cheated. The candidate used an AI assistant on a take-home SQL exercise. Nobody had written down whether that was allowed. Half the room called it fraud; the other half pointed out that all 4 of us had used AI tools that morning to write the code we'd shipped before lunch.

That argument is happening at every company right now, and the result is a mess for candidates. Some Data Engineer loops ban AI, some allow it, and a growing number grade how you use it. With no shared rule across hiring teams, you can't prepare for one policy, so you have to prepare for both. The skill that works under either one is verification: proving your SQL is correct, quickly and out loud, whether you typed it or a model did.

Data Engineer interviews have no shared AI rule

Start with the job itself. Stack Overflow's 2026 Developer Survey found that 73% of respondents who use AI coding assistants or agents use them daily. Read the denominator carefully. That figure covers people who already use AI tools, so it doesn't mean 73% of all developers. Even so, among people who've adopted these tools, daily use is normal. The survey's breakdown of what people use AI for reads like a DE's week: generating code in a familiar area (69.3%), debugging and refactoring (63.8%), writing tests (58.1%).

Now look at the interview. Karat's research page on 2026 interview trends reports that 62% of organizations still prohibit AI use in technical interviews, based on 400 engineering leaders across the U.S., India, and China. Policy also changes a lot by region. On the same page, 38% of U.S. organizations allow AI in live interviews, compared with 68% in China. If you hear that "most companies ban AI," that's true in aggregate and misleading for any single loop.

Karat's own December 2025 release on its 2025-2026 AI Workforce Transformation Report shows the gap more sharply. Nearly 70% of engineering leaders plan to strengthen their AI capabilities through hiring, and less than 30% are updating assessments and training interviewers to identify AI-ready talent.

So leaders want to hire people who are good with AI tools, and most of them haven't changed the test that's supposed to find those people. I've watched every hype cycle get a hiring mandate before it gets an evaluation process.

A few caveats. Karat sells an AI-enabled interview product, so it benefits when companies worry about this question. Its pages report different sample sizes (400, 150, and 157 depending on the edition), and the release doesn't publish its methodology. Stack Overflow says nothing about interview policy at all. "Interviews lag behind daily practice" is my argument from putting those 2 data sets side by side. Neither source measures that lag directly.

I'm still confident in the argument, because I've been on both sides of these loops. Karat also quotes tech leaders who estimate that over half of candidates use AI despite being told not to. That's an estimate, but it matches what I've seen on panels, where the bans leak.

You can't control which AI policy you'll get. You can control whether your SQL holds up under either one.

AI-allowed rounds grade whether you checked the output

Candidates often assume AI-allowed rounds lowered the bar, when they actually moved it somewhere else.

Karat publishes its Human + AI technical interview rubrics, and they're blunt. The rubrics assess "when and why AI is used, how prompts are scoped, and whether outputs are checked." They also state that candidates "should neither be penalized nor implicitly rewarded for AI-outputs." Karat adds an AI Proficiency competency with 2 parts: Prompting AI Code and Evaluating AI-Generated Code. Its stated reason is one every DE who has been paged at 2am will recognize: unchecked AI-generated code introduces operational, security, and reliability risks.

Canva's engineering blog says nearly the same thing in an interviewer's guide by Karl Hörnlund. AI collaboration is one of 3 graded areas, next to problem-solving and technical depth. Strong candidates clarify requirements and state assumptions before they write code. They use AI for skeleton code and review the complex suggestions. The weak patterns have names, and they're good ones: "AI Showcase," "Feature Marathon," and "Hands-Off."

I've seen all 3 patterns in real loops.

The first pattern is the candidate who spends 10 minutes crafting the perfect prompt and can't tell you why the join is a LEFT JOIN. Feature Marathon looks like 6 extra CTEs nobody asked for, generated because the assistant made them cheap. Hands-Off is the one who pastes the output, watches it run, sees rows come back, and says "looks good." Rows coming back proves the query runs, not that the numbers are right.

Neither rubric ranks speed. My read is that an unchecked fast answer should score below a slower one you can verify and explain. Both Karat and Canva point that way, even though nobody has published evidence that these rubrics predict job performance. Karat's rubric page says "research shows" human-plus-AI interviews produce the best outcomes and gives no figures. Treat that as the vendor's position.

The bigger point is that AI-allowed rounds are finally testing the actual job. I've said it for years: the job is less "write a DAG" and more "figure out why this pipeline silently dropped 2M rows last Tuesday." I once spent a week on a job that had been dropping 40% of records for 6 months. The code was clean, the job succeeded every night, and nobody had checked the row counts. An AI assistant would have written that same clean code, and someone would still have had to check the counts.

The Stack Overflow numbers support this too. 93% of respondents rate source attribution as at least somewhat important when verifying AI output, and 48% trust AI output when they can easily verify it. Interviewers who allow AI are grading whether you do that checking.

Practice verification on real postmortems

Verification is hard to practice in the abstract. "Check your edge cases" is advice everyone nods at and nobody does. The most useful practice I've found is taking real incidents apart, because they give you concrete stories to tell in pipeline design and behavioral rounds under either policy.

Take Zendesk. Its postmortem for the June 26, 2026 Sales incident attributes the outage to "an accidental command during maintenance that unintentionally deleted seven important tables in the Sales database." The tables were restored from a recent backup, followed by a controlled reconciliation, and the final update on July 1 says remediation was complete. (The summary window ends June 28, but the dated updates run to July 1. Cite the updates.)

Look at their preventive actions: remove unnecessary Drop privileges, set environment-specific access controls, "review and regulate activities scheduled on Fridays" (every DE who has ever deployed on a Friday just felt that one), and add safeguards that block harmful commands in production.

Every one of those fixes is a permission or a guardrail; none of them relies on people being more careful. The postmortem never mentions AI tools, so don't tell it as a story about an assistant gone wrong. It's useful precisely because the fix works whether a human or an assistant types the command. In a banned-AI loop, it's a story about access control. In an AI-allowed loop, it answers "how would you let an agent near production?" You'd let it near production with the same safeguards you'd use for a tired engineer at 5pm on a Friday.

CircleCI's July 2, 2026 post-incident report teaches a different lesson. A maintenance data deletion job, split into several hundred tasks, started at 13:30 UTC. Customer project deletion requests, unrelated to that job, started at 14:40. Pipelines failed to start between 15:12 and 16:44, and some customers couldn't log in. CircleCI named the root cause as connections between the API layer and the workflows data service that weren't configured to time out slow responses under load. The deletion jobs supplied the load; the missing timeout was the bug.

Most candidates blame whatever job happened to be running. Strong candidates separate what started the incident from the guardrail that was missing. If you can explain that distinction clearly in an interview, you're showing the same judgment a rubric is looking for when it asks whether you checked the AI's output.

For practice, pick a postmortem and write 3 sentences: the trigger, the missing guardrail and the fix. Then explain how you'd catch the same failure class in a pipeline you own. Do that 10 times and you'll have a library of stories that works in any loop.

Prepare for both policies from one shared core

Before every round, ask the recruiter in writing whether AI is allowed, which tools, and whether the round is live or take-home. I once did 8 rounds at a company, was told an offer had been sent, never received it, and was then told I'd declined it. Verbal policies at companies like that change between the phone screen and the onsite.

Then build a shared core that works under either policy, and practice it without an assistant. In SQL, that means window functions, deduplication, incremental loads, NULL handling, and joins that fan out when keys are duplicated. In pipeline design, say the grain, the late-arriving data plan and the backfill strategy before you draw any boxes. For failure handling, know retries, idempotency, and what happens when an upstream team changes a contract without telling you (they will).

These concepts transfer across policies the same way they transfer across tools, and the syntax is the easy part.

For banned-AI loops, drill from memory with a timer. Mediums are enough; do 50 and you'll be solid. Practice explaining your query plan out loud, because silence on a whiteboard reads as being stuck. Keep a short syntax cheat sheet and rebuild it from memory until you don't need it. That's the old game, and the arbitrary rules still apply.

For AI-allowed loops, the main risk is accepting generated code you can't defend. Practice reviewing AI output specifically for bad joins, missing NULL checks, timezone errors, and late-arriving records. Narrate each check: "I'm verifying the grain before I trust this count." Clarify requirements before prompting, scope prompts tightly, and turn down suggestions you don't need. Turning down a suggestion and explaining why is one of the strongest signals you can send in that room.

There's research behind practicing without AI too. In a randomized trial, Anthropic found 52 mostly junior engineers averaged 50% on a comprehension quiz after coding with AI, compared with 67% for those who coded by hand. The speed gain was around 2 minutes and wasn't significant. The sample is small and the quiz was taken immediately after the task, so don't overread it. It still matches what I see on panels: candidates who learned SQL with an assistant doing the thinking struggle to verify anything, because they never built the mental model to check against.

That's why I'd put most of your practice time into unassisted SQL, then add AI-review practice on top. If you're looking for timed, unassisted practice, for sql coding questions, datadriven.io is great. It's our site, so weigh that, but it's where we send people who ask where to drill window functions before an onsite. Once your fundamentals hold up without help, run the same problems with an assistant and practice catching where it's wrong. It will be wrong. In my experience, it's most often wrong on the edge cases interviewers love.

The candidate I'd hire in 2027 can do both: write a correct dedup query from memory in a banned loop, then catch the assistant's fan-out join in an allowed one, and explain both in plain English. Policies will keep moving for a while, and in my experience the pattern of companies demanding a skill before they know how to test it lasts around 18 months. The verification skill will still matter after that settles.

So which policy have you run into in your last few Data Engineer loops: banned, allowed, or graded? And did anyone tell you before the round started?