Your client doesn't pay you to forward resumes. They pay you to send people who can do the job. Here's a practical way for recruiters to verify technical skills before a submission, without needing to be engineers themselves.

1. Turn the job description into three to five testable must-haves

Most JDs list fifteen technologies. Ask the hiring manager which ones would actually stop a hire. Then rewrite each one as something a candidate can demonstrate:

If you can't describe how a candidate would show it, it isn't a must-have yet.

2. Ask scenario questions, not trivia

"What is a closure?" can be memorised in thirty seconds. "Tell me about a bug that took you more than a day to find. What did you try first?" can't.

Good technical screening questions for recruiters:

• Walk-through: "Walk me through the last feature you shipped, from ticket to production."
• Trade-off: "When would you choose a relational database over a NoSQL one? Give an example from your work."
• Debugging: "A page that used to load in one second now takes eight. How would you investigate?"
• Ownership: "What part of your current system would you redesign, and why?"

You don't need to know the perfect answer. Listen for specifics: names of tools, numbers, decisions and what went wrong. Vague answers that stay at the buzzword level are your signal.

3. Score answers against a simple rubric

Agree on what "good" looks like with the hiring manager before you screen anyone:

• 1, not shown: generic or memorised answer, no real example
• 3, credible: a real example with some detail and a sensible approach
• 5, strong: clear reasoning, trade-offs considered, measurable outcome

Writing a one-line reason next to each score is what makes your submission defensible when the client asks "why this candidate?"

4. Make sure the answers are the candidate's own

Remote technical screening has a growing integrity problem: off-screen help, AI-generated answers read aloud, and in some cases a different person answering altogether. Before you submit, look for:

• Long pauses followed by suspiciously polished answers
• Tab switching or copy-paste during written responses
• A second voice, or a face that doesn't match the candidate's profile
• Answers that sound strong but fall apart on a simple follow-up question

Proctoring evidence lets you show the client that the answers came from the candidate, not just tell them.

5. Package the evidence with the submission

A strong IT staffing submission includes:

• The must-haves and how the candidate answered each one
• Scores with a one-line reason
• Proctoring or integrity notes
• Risks: notice period, rate expectations, gaps to probe in the technical round
• Your recommendation

Hiring managers move faster when they can see why you're confident.

Where SimpleHire AI fits

SimpleHire AI helps recruiters do steps 2 to 5 at scale. Candidates answer structured screening questions, their responses are scored, and recruiters review the answers alongside proctoring evidence before they submit. The tool doesn't replace the recruiter. It gives you the evidence to make a better and stronger client submission. If you work in IT staffing, see how SimpleHire supports IT staffing teams.

Visit SimpleHire AI: https://simplehire.ai/

I work on candidate screening software, so I spend a lot of time on this question from the other side. Here's a plain explanation of what a web page can detect, the code behind it, and the reasons a sensible system treats every signal as a question rather than a verdict.

Signal 1: the tab became hidden

The Page Visibility API tells a page when it stops being visible, for example when the user switches tabs or minimizes the window.

document.addEventListener('visibilitychange', () => {
  logEvent({
    type: document.hidden ? 'tab_hidden' : 'tab_visible',
    at: Date.now(),
  });
});

That's all there is to it. The page learns that it was hidden and when it came back. It doesn't learn which tab you switched to or what you looked at.

Signal 2: the window lost focus

Focus is different from visibility. If you click into another application while the browser window stays on screen, the tab is still "visible" but the window has lost focus.

window.addEventListener('blur', () => logEvent({ type: 'window_blur', at: Date.now() }));
window.addEventListener('focus', () => logEvent({ type: 'window_focus', at: Date.now() }));

This catches things like alt-tabbing to a chat app on a second monitor. It also catches a lot of innocent behavior, which we'll come back to.

Signal 3: text was pasted

Paste events fire on the element receiving the paste. A page can record that a paste happened and how long the pasted text was.

editor.addEventListener('paste', (e) => {
  const text = e.clipboardData.getData('text');
  logEvent({ type: 'paste', length: text.length, at: Date.now() });
});

Note what the browser allows here. The page only sees clipboard contents at the moment you paste into it. It can't read your clipboard in the background. A well-behaved system records the length and timing, not the content.

Signal 4: typing rhythm

Some tools look at keystroke timing. Someone writing code thinks, types in bursts, backspaces and pauses. Someone retyping an answer from another screen tends to type at a steady pace with few corrections. This is a weaker signal than the others and easy to over-interpret, so treat it with care.

What a browser cannot see

This is where a lot of fear (and a lot of vendor marketing) goes wrong. A normal web page cannot:

• see other applications or your screen, unless you explicitly start screen sharing

• see which tab you switched to

• read your clipboard when you aren't pasting into the page

• detect a second device sitting next to the laptop

• detect someone in the room whispering answers

Anything beyond those limits needs extra steps the candidate has to agree to: screen sharing, a webcam, a desktop app that checks for running processes, or a phone set up as a second camera.

Why every signal produces false positives

Here's the part that matters most if you're building or buying one of these systems. Every one of those events has boring explanations.

• Tab hidden: a calendar notification, a password manager popup, a candidate checking the job description in another tab

• Window blur: a Slack ping, a Windows update prompt, a second monitor with the interview instructions open

• Paste: pasting your own code from an earlier step, or a long variable name from the question text

• Steady typing: some people are just fast, careful typists

If a system turns raw events into an automatic "cheating" score, it will flag honest people. That's unfair to candidates, and it's bad for the people hiring too, because they end up rejecting good candidates over a notification sound.

What a reasonable design looks like

From working on this, a few principles hold up:

1. Tell the candidate exactly what's recorded before the session starts. People behave more naturally when nothing is hidden, and in several US states there are legal requirements around AI in hiring that make transparency a good default anyway.

2. Record events, not content. A timestamp and an event type are enough. Avoid storing clipboard contents or keystrokes themselves.

3. Look for patterns, not single events. One blur means nothing. Long pauses before every answer, followed by large pastes, with repeated focus loss, is worth a closer look.

4. Put a human in the loop. A reviewer should look at flagged sessions in context before anything reaches a hiring decision.

5. Show the evidence, not just a score. "3 focus changes, longest 4 seconds, all during question 2" is far more useful than "integrity: 72%."

If you're the candidate

You don't need to be nervous about any of this. Close notification-heavy apps, keep the interview in one window, and if something interrupts you, say so out loud or in the chat. A sensible reviewer will see the context.

Disclosure: I work on Simplehire, which screens candidates for staffing agencies and uses the kind of event logging and human review described above. The examples here are generic and work in any modern browser.