Skip to main content
Blog
Jul 25, 2026Eli YoungEli Young 4 min read

A Replay Should Show What the Candidate Actually Saw

Session replay is only evidence if it reflects the candidate's real screen. Two fixes: one continuous timeline that follows the candidate across questions, and an honest band for the time they spent orchestrating agents.

AssessmentsSession ReplayEvidenceVibecoding

A reviewer watching an assessment replay is doing something specific: reconstructing a working session they were not present for. Every place the replay differs from what the candidate actually saw is a place the reconstruction silently goes wrong. Two of those places bothered us enough to fix.

One timeline, not five

Our replays used to be organized by question. Pick a question from a dropdown, watch that question's timeline, pick the next one. Tidy, and wrong. Candidates do not work in per-question compartments. They open question five at minute five, bounce back to question two, and return later with a new idea. The dropdown model erased that structure and made the reviewer do the reassembly by hand.

The replay is now one continuous session timeline. Which question is on screen is derived from the recorded switching events, so scrubbing the one timeline walks the code and preview through every question in the order the candidate actually visited them. A colored band above the scrubber shows the dwell structure at a glance, and clicking a segment jumps into it. If the question was focused at minute five, minute five is where the replay shows it.

One honesty rule made this work: for older sessions that never recorded switching events, we refuse to invent the band. The replay falls back to manual selection rather than displaying a reconstruction that looks authoritative and is fiction.

The frozen-code problem

Vibecoding sessions have two surfaces: the editor, and an agents window where candidates orchestrate parallel AI conversations. Our code frames only ever captured the editor workspace. So a candidate who spent forty minutes directing agents replayed as someone staring at unchanged code for forty minutes. Same pixels as a candidate who walked away from the keyboard, and completely different work.

The session recorder had been logging surface switches all along. The replay just never rendered them. It now reconstructs an editor-versus-agents band with the same tiling logic as the question track, and while the playhead sits inside an agents dwell, the code pane says so explicitly: the frames below are what the agents were writing into, not what was on screen. The reviewer stops misreading orchestration as idleness.

01
Product surface
02
Captured evidence
03
Reader decision
04
Next loop
A Replay Should Show What the Candidate Actually Saw should leave a product artifact someone can inspect later.

Evidence means resisting inference

Both fixes come from the same rule. A replay is evidence, and evidence is allowed to say I do not know, but never allowed to guess. Rendering a question band with no switch events, or presenting editor frames as the candidate's screen during agent work, are guesses wearing the costume of records. The honest version is sometimes less impressive to look at. It is also the only version a hiring decision should rest on.

How to read this update

The important question is not only what shipped. It is what new evidence the product can now preserve. For assessments work, a useful release should make the next session easier to understand: what happened, why it mattered, and what someone can do with the result afterward.

That is the bar we use for field notes. A feature is stronger when it turns a hidden process into something reviewable: a timeline, a report, a map, a score explanation, a replay, or a teacher-facing control. The surface can stay simple, but the evidence behind it should get harder to hand-wave.

Related posts

View all