What does the AI coding round consist of?
A repository you have never seen, a failing check that reproduces a production incident, an AI agent (the company's harness or a tool like Cursor or Claude Code), and a timer. You drive the agent to a fix, keep the passing checks green, and then walk the interviewer through the diff and the reasoning.
Is using the AI heavily a good or bad signal?
Neither; direction is the signal. Strong candidates delegate mechanical work (finding call sites, writing the harness) and keep judgment work (what the bug is, what the fix must preserve). Candidates who paste the prompt and accept the first diff fail on the follow-up questions about their own patch.
What separates candidates in this round?
The reproduce-first habit, the precision of instructions to the agent, and diff review. Reported debriefs converge on one tell: candidates who can say what the agent got wrong and why outperform candidates whose session went smoothly, because smooth sessions leave no evidence of judgment.
Which stacks come up?
The data platform surface: Airflow DAGs, dbt models, Kafka consumers, Spark jobs, Flink streams, Iceberg tables, feature stores, and increasingly RAG and embedding pipelines. The scenarios on this page cover all of them, one incident each, because breadth of recognition beats depth in any one tool.
How do I prepare if my company does not use agents yet?
Run the workflow on real scenarios: reproduce a failing check, write the agent a scoped instruction, review its diff line by line, demand proof. Tool fluency transfers across agents; the workflow is the durable skill.
What should I say when the agent produces a wrong fix?
Out loud, exactly what you would say to a junior engineer: what the diff does, why it is wrong (passes the check, breaks the semantics), and what instruction you are giving next. Interviewers weigh that narration more heavily than a session where nothing went wrong.
Does the round replace the regular coding round?
In most reported loops it is additive or replaces a second coding round, not the first. SQL remains the highest-frequency screen and Python the tiebreaker; the AI round checks a third thing, whether your engineering judgment survives delegation. Prepare it third, but do prepare it.
What is the most common failure?
Skipping reproduction. Candidates who start prompting before running the failing check fix the wrong thing convincingly, and the round is unrecoverable from there. Run it, read it, restate it: nothing else in the hour pays off like those first 3 minutes.
How do you review AI-generated code for correctness?
Read it against the failing check, not against your intuition of what looks right. Generated code is fluent by construction, so plausibility is not evidence. Confirm the diff changes the behavior the test exercises, look specifically at boundary conditions the model tends to guess at (empty input, ties, NULLs, timezone edges), and re-run the check. If the fix passes for a reason you cannot state out loud, it is not yet a fix.
What is idempotency and why do agents get it wrong?
Idempotency means re-running a pipeline step produces the same result rather than duplicating rows. Agents get it wrong because the naive INSERT looks correct in isolation and only fails on a retry, which the test suite often does not simulate. The fix is a MERGE on the business key or a delete-then-insert scoped to the partition, and the interview signal is that you asked what happens on a re-run before accepting the diff.
How do you catch data skew in code an assistant wrote?
Look at the join keys, not the syntax. An assistant will happily write a correct join that puts 90% of rows on one key, because nothing in the prompt told it the distribution. Ask for row counts per key, and if one dominates, the answer is a broadcast join, AQE skew handling, or salting the hot key and re-aggregating. Naming skew before the job hangs is exactly what this round rewards.
What should you check about partition pruning in a generated query?
That the filter is on the raw partition column, compared against a literal or bound parameter. Assistants commonly wrap the partition column in a date function or cast it, which is semantically identical and silently defeats pruning, turning a one-day read into a full-table scan. Confirm it by reading the query plan rather than by trusting the diff.
How do you read an EXPLAIN plan when the agent proposes a query?
Read it inside out. Look for sequential scans on large tables where an index exists, nested loops with a large outer relation, and a wide gap between estimated and actual rows, which means stale statistics. EXPLAIN ANALYZE gives real per-node timings so the expensive node is unambiguous. Bringing the plan into the conversation is the fastest way to show the round you verify rather than accept.
What are the biggest risks of accepting an agent's schema change?
Grain violations and silent breaking changes. An assistant will add a column or flatten a relationship without asking what one row means, which fans out every downstream aggregate. It will also rename or retype a field without a migration window, breaking consumers that read the old contract. Ask what the grain is and whether the change is additive before the diff is applied.
How do you write a good prompt for a debugging task?
Give it the evidence, not your hypothesis. Paste the failing check's actual output, the relevant schema, and the constraint that must hold, then ask for a diagnosis before a fix. Prompts that lead with a guess get that guess confirmed, because the model is agreeable. Asking for two candidate causes and the evidence that would distinguish them is a noticeably stronger move.
What is the interviewer actually looking for in this round?
Verification behavior, mostly. Did you reproduce before fixing, did you notice the wrong edit, did you demand a passing check rather than a confident explanation, and can you defend every line of the final diff as yours. Volume of AI usage is close to neutral. Accepting an unverified diff is the single most damaging thing you can do.
How is this different from a normal coding interview?
A normal coding round measures whether you can produce the code. This one assumes the code is cheap and measures whether you can direct and audit it: scoping the task, catching a wrong turn early, and proving the result. The workspace is a real repo with real failing checks rather than a blank editor, so navigation and reading unfamiliar code matter far more than recall.
