Somewhere in the last two years, interview software grew a feature where it tracks when a candidate pastes text into a response box. And somewhere around the same time, a reading of that tracking emerged: a row of paste events in a submission report started to look a little suspicious. "They pasted forty lines of text at 14:23. Should we flag it?"

It's understandable instinct, and also, we think, usually the wrong read. Most of the time a paste event is evidence that the candidate went and looked something up — exactly what a senior engineer does on day one of a new job, and on day 300 too.

What paste events actually indicate

Think about what you do when you're working on something real. You read a stack trace, you copy half of it into a web search. You find a GitHub issue, you paste the relevant function into a reply. You draft a design doc, you pull the old design doc's opening paragraphs in and rework them. You ask Claude a question, you paste the answer into a notes file to come back to.

None of that is fraud. All of it involves paste events.

Candidates who paste never during a take-home tend to be one of the following. Some are very junior and don't yet know what's worth looking up. Some are heavily rehearsed and are working from a template they've memorised for exactly this shape of problem. Some are anxious and have assumed the tracker will be used against them. None of those three profiles is a particularly strong hiring signal on its own.

The candidates who paste a lot are often the ones who are treating the problem like real work: they look things up, they quote AI output when it's useful, they pull in their own snippets from prior projects, they reference the prompt text directly to stay anchored. That's what thinking alongside tools usually looks like.

The difference you're actually trying to see

There is still a thing worth looking at in a paste event. It just isn't whether it happened. It's what happened around it.

  • Did the pasted text get used, or did it sit there unmodified and untouched until submission? A pasted chunk that wasn't read is a different signal from a pasted chunk that got pulled apart.
  • Did the candidate disagree with the pasted content anywhere? A senior engineer takes AI output and argues with it. A junior engineer takes AI output and prays.
  • Did the paste map to a question they'd clearly asked themselves, or did it appear from nowhere? You want to see the why of the paste, which is almost always in the preceding paragraph or the preceding AI turn.

That's how to read a paste. Not "they pasted, therefore they cheated" — but "what were they doing the moment before, and what did they do with the thing they pasted?"

The useful way to surface a paste

CriticCode shows hiring managers every paste a candidate made during a challenge, highlighted directly in the response. The intent isn't to flag that the candidate did something wrong. It's to give the reviewer context: where the candidate's thinking was borrowed, where it was adapted, where a quoted passage originally came from. The interviewer then gets to ask about it on the follow-up, which is usually the only place any of this is worth resolving anyway.

If a take-home tracker presents a rising paste count as a warning sign, it's measuring something other than what most teams actually want to know. What it reliably catches is whether the candidate knows the tracker exists. The same data becomes much more useful the other way round: surface each paste in context, and bring it into the follow-up conversation as a prompt for discussion rather than as evidence.