Once you've decided to collect an AI transcript as part of a candidate's submission, you've done the easy half of the work. The harder half is changing the interview around it so the transcript actually affects the decision. Most teams I've seen adopt transcripts leave their interview process unchanged and end up using the transcript the way they used to use a scanned PDF of the take-home: they scroll through it once and move on.
That's a waste. A transcript is a different kind of artefact than a submitted code file, and it unlocks a different kind of interview — if you let it.
Before the interview: plan from the transcript, not the artefact
The first move is to stop opening the submission at the code and scrolling down to the transcript. Open the transcript first. Read it end-to-end. You'll get through it in ten to fifteen minutes, which is faster than reviewing most code submissions properly, and the specific reading technique gets easier after you've done it a few times.
What you're doing is reading the shape of the candidate's thinking before you read the polish of their output. The final answer has been tidied. The transcript is the uncurated version, and it's more informative for planning the interview.
As you read, mark the moments that stand out: where the candidate pushed back on the AI, where they asked something surprising, where they chose to stop. Those become your question sources for the live round. You walk into the interview with specific things you want to ask about, each anchored in a real exchange the candidate can't generically deflect.
This is the biggest leverage point in the whole process. An interviewer with two or three specific openings is running a different interview than an interviewer with "any questions for me?" as their backup plan.
During the interview: put the transcript in the room
Most interviewers treat the transcript as prep material only. That's leaving signal on the floor. In a follow-up round with a candidate, it's entirely reasonable to bring a specific exchange from the transcript into the conversation and ask them about it directly.
"You asked the AI about sharding strategies here, and then you pushed back on its suggestion to use range-based sharding. Walk me through what you were worried about."
That kind of question does two useful things. It tells the candidate you read the submission carefully, which tends to improve the quality of the answers you get for the rest of the session. And it forces the candidate to re-enter the reasoning they were in at the moment of that exchange, which reveals whether they actually understood it or were pattern-matching.
Where this goes wrong is if the interviewer uses the transcript as a gotcha. "I see you copied the AI's first suggestion here. Why should we hire you?" isn't a question, it's a stance. The transcript is a richer artefact than that — it rewards curiosity, not prosecution.
After the interview: anchor the debrief in the artefact
In a debrief where interviewers disagree about a candidate, the disagreement is usually about what happened in the room. Someone remembers the candidate reasoning clearly in minute 22; someone else remembers them looking lost. Without a shared artefact, the debrief becomes a negotiation between memories.
With a transcript of the async round, you now have a piece of evidence everyone can point to. "I think the candidate is weak on trade-offs" becomes falsifiable: you can both look at the three places in the transcript where they named trade-offs unprompted. The disagreement either resolves, or both parties update their reads at the same time.
This is especially useful in teams that have been trying to improve calibration by adding rubrics. Rubrics without anchors tend to produce the same disagreements in rubric vocabulary. Rubrics with an artefact everyone can quote from produce shorter, sharper debriefs. The artefact is doing the work the rubric was supposed to do.
The workflow, compressed
If you implement nothing else from this post, try this workflow on your next candidate submission:
- Read the transcript before the code.
- Mark two or three specific moments as question sources.
- Walk into the follow-up with those openings already written down.
- Quote at least one transcript exchange directly in the room.
- Bring the transcript back out in the debrief.
That's the whole change. An extra 15 minutes of interviewer prep per candidate, and noticeably clearer hiring decisions downstream. At CriticCode the transcript is built into the submission view for exactly this reason, but the workflow works anywhere you can get a text record of a candidate's reasoning.
The practical question
If you're already collecting transcripts, the question worth asking yourself is: when was the last time a specific line of a transcript changed someone's mind in a debrief? If the answer is "never," the transcript isn't in the process yet. It's in the folder next to the process. The move from folder to process is the one that actually affects hiring decisions.