The AI-assisted coding round

As of June 2026: company formats, tool names, and rollout dates cited below reflect that date — confirm specifics before an interview.

Net-new format. Meta rolled it out Oct 2025 (one of two onsite coding rounds, 60 min); Google is piloting; Canva requires it. The interviewer hands you a CoderPad three-panel layout — file explorer, editor, AI chat sidebar with GPT-5 / Claude Sonnet 4 / Gemini 2.5 Pro preloaded — and a small multi-file codebase. They grade how you collaborate with the model under time pressure.

What's actually different from a normal coding round

In a classic coding interview the bottleneck is recall: can you remember the two-pointer trick, write a binary search without an off-by-one, finish under the clock. The AI removes that bottleneck — the model can produce a binary search instantly. So the test shifts to the things the model is bad at and you are supposed to be good at: judgment (is this the right thing to build, and is the answer correct?) and verification (have I proven it works, or am I just hoping?). A few terms, defined so nothing here is a black box:

• AI assistant / model. The chatbot in the side panel (GPT-5, Claude, Gemini). You type a request; it answers with text and code. It does not run your code unless the panel has an agent mode that executes — assume it does not, and that you are the one who runs things.
• Prompt. The instruction you send. A good prompt states intent, names the file/function, and says what "done" looks like.
• Hallucination / confidently-wrong code. The model invents a function, an import, an API field, or an edge-case behavior that does not exist or is wrong — and presents it with the same confident tone as correct code. There is no built-in "I'm unsure" signal, so skepticism is your job.
• The "driver" mindset. Borrowed from pair programming, where one person types (the driver) and one reviews (the navigator). In this round you are always the navigator and also the final driver — the AI is a very fast typist you delegate to, but you decide direction and you sign off on every change.
• Verify. Run the test, run the file, or hand-trace one concrete input. Reading the code and nodding is not verifying.

The loop that wins: intent → generate → verify → iterate

There is one repeatable cycle the strongest candidates run, and narrating it is half the score. Each turn has four beats. The key is that you speak every beat — the interviewer can't read your mind, and your spoken reasoning is the actual artifact being graded.

1. State intent (out loud, then in the prompt). Decide what you want and why before you ask. "I need a pure function that validates the input shape, returns an error string or null, no I/O." Saying it first forces you to know the answer's shape, which is exactly what lets you catch a wrong answer.
2. Generate. Send a small, specific prompt. One layer, not the whole feature. Name the file and the contract.
3. Verify. Read the diff against the contract you just stated, then prove it: run the test, run the file, or hand-trace a concrete input and an edge case (empty, null, the boundary value). This beat is non-negotiable — it is the thing they planted bugs to test.
4. Iterate. If it's wrong, say why in one sentence and re-prompt with the added context, or just fix the small thing yourself. If it's right, move to the next layer and start the loop again.

# BEAT 1 — STATE INTENT (spoken): "I want a pure function:
# string in, number of seconds out. It should handle h and m,
# and I'll decide what it does on bad input after I see a draft."

# BEAT 2 — GENERATE (prompt sent to the panel):
# "Write parseDuration(str) in utils.js. Parse formats like
#  '1h30m', '45m', '2h'. Return total seconds as a number.
#  Don't touch other files yet."

# --- model returns: ---
function parseDuration(str) {
  const h = str.match(/(\d+)h/);
  const m = str.match(/(\d+)m/);
  return h[1] * 3600 + m[1] * 60;
}

# BEAT 3 — VERIFY (hand-trace, spoken):
# "1h30m": h match -> "1", m match -> "30".
#   1 * 3600 + 30 * 60 = 3600 + 1800 = 5400.  Correct.
# "45m":   h match -> null  ... h[1] crashes: null has no index.
#   BUG. And '30' * 60 is string * number — works in JS by
#   coercion, but that's luck, not intent. I want real numbers."

# BEAT 4 — ITERATE (re-prompt with the failure you found):
# "It crashes on '45m' because the h match is null. Handle a
#  missing h or m as 0, and use parseInt so we add numbers,
#  not strings."

# --- model returns the fixed version: ---
function parseDuration(str) {
  const h = str.match(/(\d+)h/);
  const m = str.match(/(\d+)m/);
  const hours = h ? parseInt(h[1], 10) : 0;
  const mins  = m ? parseInt(m[1], 10) : 0;
  return hours * 3600 + mins * 60;
}
# VERIFY AGAIN: "45m" -> 0*3600 + 45*60 = 2700. "2h" -> 7200.
# Both correct. NOW I wire it into the handler — next layer,
# loop restarts.

Spotting confident-but-wrong code

Because the model never sounds unsure, you need a fixed checklist you run on every diff regardless of how good it looks. These are the failure shapes that recur most in this round:

The rubric, named explicitly — what every company actually scores

Meta, Google, Canva, and the AI-product startups arrived at the same rubric independently, which is the strongest sign it's real and worth memorizing. The round is not graded on whether the code works — it's graded on five judgment axes. Internalize these five and you know exactly what the interviewer's scorecard says:

Playbook: the moves that score

What interviewers reward — and the pitfalls that sink you

Two columns, same coin. The rewarded behaviors all show you steering; the pitfalls all show the AI steering. When in doubt, ask yourself "who is in the driver's seat in this moment?" and act to make the answer obviously you.