How to run an AI pair programming interview

An AI pair programming interview is a live coding session where the candidate works on a realistic task with an AI coding assistant while an interviewer pairs with them — asking questions, supplying context, and watching how they work. To run one well, pick a problem a single prompt can't solve, agree what help the interviewer may give, and score the candidate's framing, direction of the AI, verification, and ownership of the result — never the agent's raw output.

What is an AI pair programming interview?

The pair programming interview has been around for years: a candidate and an engineer work through a problem together, and the interviewer learns how the candidate thinks, communicates, and takes feedback. The AI version adds a third participant. The candidate now has an assistant — a chat-based copilot or a full coding agent — that can write, run, and refactor code on request.

That changes what the session is for. When the agent can produce a working function in seconds, typing speed and syntax recall stop being informative. What's left to observe is everything around the code: how the candidate turns an ambiguous brief into instructions, whether they read what comes back, and whether they can defend the result as their own.

This isn't hypothetical. In June 2025 Canva's engineering team replaced its computer science fundamentals screen with an AI-assisted coding round for frontend and backend roles, in which candidates are expected to use tools like Copilot, Cursor, or Claude on realistic product problems.

How to run an AI pair programming interview

1. Set up the workspace before the candidate arrives. A ready editor, the AI tool already connected, a starter project that builds. Every minute spent installing an extension or pasting an API key is a minute of signal lost, and it penalises candidates for their setup rather than their skill.
2. State the AI policy out loud."Use the assistant the way you would on the job, and talk us through what you're doing" removes the guesswork. Candidates who aren't sure whether AI use will be held against them underuse it, and you end up evaluating their nerve.
3. Open with the brief, not the code. Give the candidate a few minutes to read the task and ask questions before anyone prompts anything. Clarifying questions are some of the best evidence the session produces.
4. Let them drive; you navigate.The candidate controls the keyboard and the agent. The interviewer plays the teammate: answers requirement questions, shares the context a colleague would know, and asks "why" at decision points.
5. Reserve the last ten minutes for discussion.Ask what they would change before shipping, what they didn't trust in the generated code, and what they'd test next. This is where ownership shows up — or doesn't.

What does the interviewer do in an AI pair programming interview?

The interviewer's job changes more than the candidate's. In a classic pairing interview you could follow the candidate's typing. With an agent in the loop, large diffs appear at once, and it's easy to lose track of who decided what. Three habits help:

• Watch the prompts, not just the code. The instruction the candidate gave the agent tells you more about their understanding than the code it returned.
• Ask about accepted changes.When the candidate accepts a large suggestion, ask them to walk you through it. A candidate who read it can; one who didn't, can't.
• Keep a consistent help budget. Decide in advance what context interviewers may offer and when they may nudge a stuck candidate. Without that, two interviewers running the same problem are running two different interviews.

Live notes are still lossy. Interviewers who are typing notes miss moments, and notes written afterwards drift toward an overall impression. A recording of the session — ideally one that separates what the human did from what the agent did — is what makes the debrief about evidence instead of memory.

What problems work for an AI pair programming interview?

The problem has to survive the agent. If a single well-written prompt produces a correct answer, the session collapses into watching the candidate paste the brief. Canva describes making its questions "more complex, ambiguous, and realistic" for exactly this reason — swapping a Game of Life-style exercise for something like a control system for aircraft takeoffs and landings. Good problems tend to share a shape:

• Ambiguous requirements that reward asking questions before building.
• An existing codebasewith conventions the agent won't know unless the candidate tells it.
• A trap the agent is likely to fall into — an edge case, a concurrency issue, a misleading name — so verification has something to catch.
• More scope than fits the time box, so prioritisation is part of the test.

If you're adapting a take-home into a live format, the same scoping rules apply; the guide to running a take-home coding assignment covers how to size the work.

How to score an AI pair programming interview

Score the candidate's contribution, not the final diff. A rubric that works across roles has four parts:

• Framing. Did they clarify scope and assumptions and sketch a plan before prompting?
• Direction. Were their instructions to the agent specific, scoped, and informed by the codebase — and did they adjust when the first attempt missed?
• Verification. Did they read, run, and test what the agent produced, and catch what was wrong with it?
• Ownership. Can they explain and defend every part of the result, including the parts the agent wrote?

Canva's follow-up post, written after running many of these interviews, names three patterns that score poorly: the "AI Showcase" (demonstrating tool tricks instead of solving the task), the "Feature Marathon" (racing through features by accepting output quickly), and "Hands-Off" (delegating too much without reviewing). All three look productive in the moment, which is why a rubric anchored to verification and ownership matters. For the full set of criteria, see what technical interviews should measure in 2026.

AI pair programming interview vs. take-home vs. AI ban

Pairing isn't the right format for every round. A rough guide:

• Choose an AI pair programming interviewwhen you want to see judgment in real time and ask follow-up questions as decisions happen. It costs an engineer's hour per candidate, so it belongs late in the loop.
• Choose an async, recorded session when you need the same evidence at screening volume, or when candidates are in time zones that make live pairing hard. You give up live follow-up questions; the session record has to carry the weight instead.
• Choose an AI-free round only when unaided fundamentals are genuinely part of the job — and label it as such. The trade-offs of an outright ban are covered in should candidates be allowed to use AI in technical interviews.

Where DeftBench fits

DeftBenchgives each candidate an isolated browser IDE with a coding agent already wired in, captures the session as telemetry with human and agent actions attributed separately, and produces an evaluation in which every score links back to the moment that produced it — so a pairing debrief, or an async session with no interviewer at all, starts from evidence. DeftBench is pre-GA and onboarding design partners. If you're comparing it with a collaborative coding pad, the DeftBench vs CoderPad comparison sets out what each captures. Or talk to us about a pilot.