Glossary

Process telemetry — definition, examples, and why it matters in 2026

Process telemetry, in technical hiring, is a structured record of how a candidate worked with their AI: prompts, diffs, commands, decisions. Definition, examples, and why it replaced the take-home in 2026.

Also known assession telemetrycandidate process telemetryworkflow telemetryagentic process capture

Definition

Process telemetry, in technical hiring, is a structured record of how a candidate worked with their AI assistant during a coding session: every prompt they sent, every diff the model produced, every command they ran, and every decision they made along the way. It is captured inside the candidate's real coding tool — Claude Code today — and replayed as a searchable timeline of typed events, not a video of someone typing. The point is to make the process of an engineering task observable the same way production systems are observable: as a queryable event log, not a vibe.

Why the term exists / why now

For twenty years, technical interviews measured a single thing: can this person write code by themselves, in a sterile environment, under mild time pressure. LeetCode screens, take-home assignments, whiteboards — different formats, same underlying question. It was a tolerable bad proxy because at least the answer was consistent: you saw what the candidate could produce with their own hands.

That proxy collapsed in 2024–2026. Claude Code can finish a typical take-home in fifteen minutes for forty cents of API credit. CodeSignal's March 2026 survey found 91% of engineers use agentic AI at work and 75% shipped AI-generated production code in the last six months. The thing the take-home used to test became cheap. The thing it was trying to test — engineering judgment — was never really in the final code anyway.

Process telemetry exists as a term because the question shifted. The new question is how the candidate works with the agent: do they scope the problem before they prompt, do they articulate tradeoffs, do they push back when the model is wrong, do they sequence tool calls in a way that suggests they've done this before. None of that is in the final pull request. It happens in the prompts, the back-and-forth with the model, the file edits, the commands, the moments where the candidate changed direction. Software engineers have spent a decade making it normal to capture that kind of event stream out of production systems. The hiring loop is the last surface to catch on.

What process telemetry is NOT

The term gets confused with surveillance, which is its opposite. Hard lines:

Not keystroke logging. Whatever the candidate types in their terminal between prompts is theirs and is not captured. The only inputs recorded are the prompts the candidate intentionally sent to the AI.
Not screen recording. No frame buffer, no screenshots, no video of the desktop.
Not webcam, eye tracking, or any other biometrics. Ever.
Not clipboard capture. What the candidate copies and pastes between non-AI apps does not end up in the record.
Not browser history or personal-file access. Only files inside the assessment workspace are touched. Browser tabs, password managers, anything on the desktop — none of it.
Not proctoring overlay or focus tracking. No "is the candidate still looking at the screen" signal.
Not network traffic. No DNS lookups, no arbitrary HTTP requests. The only network-shaped events recorded are the AI's own tool calls.
Not a suspicion score trained on a pre-AI world. Keystroke linearity and paste-event frequency are not part of the capture surface — those signals flag good agentic coding as cheating.

A simpler frame: process telemetry is the same shape of data a candidate would put in a PR description. What they asked for, what they tried, what they tested, why they made the call they made. Proctoring is a different category entirely.

How process telemetry works in practice

A process-telemetry record is a list of small, well-defined events. In Promptster's format, every event is one of five types:

type TimelineEvent =
  | { kind: "prompt"; text: string; turnId: string }
  | { kind: "file_diff"; path: string; before: string; after: string }
  | { kind: "command"; source: "agent" | "terminal"; argv: string[] }
  | { kind: "decision_event"; rationale: string; references: string[] }
  | { kind: "mcp_call"; server: string; tool: string; args: unknown }

Each answers a real question a reviewer would otherwise have to guess at:

Prompt: every message the candidate sent to the AI, tagged with the conversation turn. Searchable across the entire session, and across every session the candidate has ever run.
File diff: every code change with before-and-after content. You can line up the candidate's first attempt against their final submission and see what they kept, what they threw away, what they reverted.
Command: every terminal command, with source showing whether the AI or the candidate started it. You can see whether the candidate ran the tests, looked at the logs, inspected the database — or shipped without checking.
Decision event: moments where the candidate explicitly picked one approach over another, with reasoning written down. Senior candidates have a lot of these. Junior candidates often have none.
MCP call: moments when the AI did something outside the codebase — a database query, an internal API hit, a Slack lookup. Candidates who know how to set these up and use them look noticeably different from candidates who don't.

A reviewer reading the timeline doesn't scrub a video. They search prompts, filter by decision type, jump to the moments where the candidate caught the model being wrong, and write the hiring brief from evidence. In Promptster's design-partner beta, average take-home review time dropped from forty-plus minutes to eight.

How process telemetry differs from session replay and proctoring

Process telemetry vs. session replay. "Session replay" is the marketing label both real and fake versions of this go by. The honest version is a typed event log: prompts, diffs, commands, decisions, tool calls. The retrofit version is a screen recording with a chat pane next to it. Both can be called "session replay" in a sales deck. Only one is searchable across candidates, joinable on decision type, and small enough to keep for compliance windows without a video pipeline.

Process telemetry vs. proctoring. Proctoring asks "is the candidate behaving suspiciously" and uses biometrics (face, eye, focus) plus typing heuristics (linearity, paste frequency, pause patterns) to answer. Process telemetry asks "what did the candidate actually do with their AI" and uses the structured event stream to answer. The two share no inputs. CodeSignal's own Cheating & Fraud page admits that browser-sandboxed proctoring "has no authority or technical means to monitor other software running on a candidate's machine" — which is the entire surface process telemetry is built to capture.

Common questions

What is process telemetry in one sentence? A structured record of every prompt, diff, command, and decision a candidate produced while working with their AI assistant on a coding task, captured inside their real session and replayed as a searchable timeline.

How is process telemetry different from a screen recording? A screen recording is a video you scrub. Process telemetry is a list of typed events you query. You can search every prompt a candidate ever wrote, filter sessions by decision type, and jump to specific moments without rewatching anything.

Is process telemetry the same as proctoring? No. Proctoring captures biometric and typing signals to flag suspicion. Process telemetry captures the candidate's intentional interactions with their AI assistant. No webcam, no keystrokes between prompts, no clipboard, no focus tracking.

Does process telemetry capture keystrokes? No. The only inputs recorded are prompts the candidate sent to the AI — the same shape of data they would put in a PR description. Keystrokes in the terminal between prompts are theirs.

Why now? Why didn't this exist five years ago? Five years ago, the final pull request still told you most of what you needed to know about the candidate. In 2026, Claude Code ships a passing solution to most take-homes in fifteen minutes. The judgment that used to be embedded in writing the code is now embedded in working with the AI. That surface needs its own capture layer.

How does process telemetry detect AI misuse? By looking for contradictions: prompt history that does not match the final code, code that appears in the record without a corresponding prompt or edit, work the candidate claims they did that the timeline cannot account for. Contradictions are a signal that still works in 2026. Typing speed is not.

Is process telemetry only for Claude Code? Today, yes. Promptster's Claude Code adapter ships now; Codex and Cursor adapters arrive Q3 2026, Windsurf Q4. The capture model — proxy in the API path plus hooks on the tool surface — generalizes across agents.

Related terms

Sources

What Is Process Telemetry in Technical Hiring? A 2026 Primer — the canonical definitional post.
In the path of every prompt — the architecture explainer for how proxy + hooks produce one timeline.
The code is no longer the signal — the argument for why process telemetry replaced the take-home.
CodeSignal: Cheating & Fraud — incumbent admission that browser sandboxes cannot observe desktop AI tools.