Cluely and invisible AI helpers: what still shows

On 13 October 2026, on a demo call with a team that hires for IT roles, one of their recruiters asked me two questions I could not answer the way I wanted to. Can your interview detect hidden AI helpers, the Cluely-style overlays that do not show up on a screen share? And can it tell when a candidate switches to another app, like a second browser window?

I said no to the first, because we had not built it. I said I was not sure about the second, because our tab rule only knew when the interview tab itself was hidden. Two days later, on 15 October, we shipped a flag for the second case. The first is still the harder problem, and this post explains why, what a voice interview can still see when a candidate uses Cluely or a tool like it, and how to design an interview that makes those tools slow and obvious. It is the third post in our series on AI proctoring for interviews.

What is Cluely, and why recruiters keep asking about it?

Cluely is an AI assistant that runs on the candidate’s computer during calls, listens to the conversation and shows suggested answers in a window the other side is not meant to see. It grew out of Interview Coder, a tool built to help engineers in technical interviews. Recruiters ask about it because it is designed to stay out of screen shares.

The backstory explains the anxiety. In June 2025 TechCrunch reported that Cluely had raised a $15 million Series A led by Andreessen Horowitz, and that its co-founders had been suspended from Columbia University over Interview Coder, which the report described as an “undetectable” AI tool for technical interviews. Earlier that year CNBC reported that Interview Coder’s founder said it was “invisible to all screen-recording softwares”, a company claim CNBC did not test.

When I pulled Google’s results for “cluely” in the US and India on 2 November 2026, the page was full of reviews, tutorials and “best alternatives” lists, plus a guide on undetectability. Very little of it was written for the person on the other side of the call. That is who this post is for.

How invisible interview helpers work

Tools in this category share a few design choices, whatever their brand:

• They float above everything else. The answer panel sits in a layer over the browser, so the candidate can read it while looking at the interview.
• They stay out of screen capture. Operating systems let an app mark a window so it is excluded when the screen is shared or recorded. The interviewer’s view of a shared screen shows the browser, not the panel.
• They avoid taking focus. The panel can be shown without becoming the active window, so the browser keeps keyboard focus and the interview page stays visible.
• They hear the question. They listen to the call audio, transcribe the question and send it to a language model, then show the answer a few seconds later.

Each of those choices is aimed at a specific detection method. Put them together and the usual browser checks have nothing to see.

Why tab-switch and focus detection cannot see an overlay

HireQwik’s interview watches two things it enforces and one it flags:

• The interview tab becoming hidden. Three warnings, then the call ends. What Tab Switch Detected means covers the screens.
• The camera being switched off. The interview pauses until it is back on. Three warnings, then the call ends.
• The interview window losing focus to another app for at least two seconds while the tab stays visible. Recorded as a flag for the recruiter since 15 October 2026, with no warning to the candidate.

An overlay that never hides the tab, never touches the camera and never takes focus trips none of the three. That is not a bug in our implementation. It is the limit of what any web page can know. A browser tab can see its own visibility and its own focus. It cannot list the other windows on a computer, and it should not be able to.

The focus flag does catch the less sophisticated version of the same idea: a candidate with ChatGPT open in a second window, clicking across to type the question. That is the case the recruiter on 13 October was asking about, and it is far more common than a polished overlay.

What a voice interview still sees

The weakness of an overlay is that the candidate still has to say the answer, out loud, in their own voice, in real time. That leaves traces a reviewer can hear and some our signals already measure.

The timing does not bend with difficulty. An honest candidate answers “Tell me about your current role” quickly and pauses longer on “How would you handle a client who disputes three invoices in a row?”. In 1,447 production interviews we measured, the median answer started 6.9 seconds after the question, with plenty of variation. An overlay has its own fixed round trip: hear, transcribe, generate, display. That can make answers arrive at much the same speed whatever was asked. We do not yet score this pattern automatically, so it is something a reviewer listens for.

The delivery sounds read. Reading a generated paragraph aloud produces speech with almost no hesitation, few restarts and a steady pace. Our possibly-scripted flag looks for exactly that combination over at least 150 words. It was built for candidates reading prepared notes, and it applies just as well to someone reading a panel.

The structure gives it away. Language models like tidy answers: “Firstly… secondly… in conclusion”, or “Great question”. One of our AI-assist signals counts that essay-style structure. On its own it means little. Next to read-aloud delivery it means more.

The eyes move like a reader’s. In the recording, a person reading text moves their eyes in short horizontal sweeps. We do not run gaze tracking and do not score where anyone looks, so this is for the human reviewer only, and it needs care: plenty of honest people look away while thinking.

The follow-up breaks it. This is the strongest tell and it needs no software. An overlay is good at a plausible first answer to a question it can hear. It is poor at the third follow-up about the candidate’s own experience, because it does not have that experience.

Why a browser interview cannot rely on detecting the app

The obvious response is to detect the tool itself: scan the candidate’s computer for known helper apps. Some proctoring products do this for exams. For high-volume screening it has three problems.

First, it needs software installed on the candidate’s computer, because a web page cannot inspect other applications. Every download step loses honest candidates before the first question, and in high-volume hiring those are candidates you never hear about. Second, it only works on the operating systems you have built it for, and much of India’s high-volume hiring happens on Windows laptops, shared lab PCs and phones. Third, lists of known tools go stale fast: new helpers appear, old ones rename themselves, and a determined candidate can run the helper on a second device the check never sees.

So our live interviews stay download-free, and we put the weight on what the candidate has to do in the open: speak, in real time, about their own work. That is a deliberate trade, and I would rather explain it than claim a capability we do not run.

Questions that make overlays slow

HireQwik jobs can be set so the AI interview asks each candidate three questions generated from their own resume, scored on a rubric written for those questions. The interviewer also asks follow-ups when an answer is vague. Neither was built as an anti-cheating feature, but both raise the cost of reading from a panel.

A review checklist for a suspected helper

When a recording makes you wonder, check these before deciding anything:

1. Compare easy and hard answers. Did the candidate take the same few seconds before “Tell me about yourself” and before the hardest scenario?
2. Listen for read speech. Is the possibly-scripted flag on? Even without it, do the answers sound like reading?
3. Check the follow-ups. Did the answers get more specific when pushed, or stay at the level of a job description?
4. Check the resume match. Do details in the answers match details in the resume, or are they generic for the role?
5. Look at the AI-assist band and its evidence. Elevated or high deserves a careful listen, but a low band does not clear an overlay, because overlays leave little trace in it.
6. Decide on a re-check, not a verdict. Offer a short live conversation with a person. Candidates who did their own talking rarely mind.

Where overlays hurt most: coding rounds versus voice screens

Not every interview format is equally exposed, and it is worth being clear about which of yours are.

Coding puzzles with a known answer are the most exposed. Interview Coder was built for exactly this case: a well-known algorithm question, a shared editor, and an interviewer watching the code appear. The question is public, the answer exists, and a language model can produce it faster than most engineers can type. The CNBC report that covered the tool also described a founder who judged that more than half of 700 applicants to a coding challenge had cheated. If your technical round is a standard puzzle, an overlay is a real threat to it, and the fix is in the format: problems tied to your own codebase, a conversation about trade-offs, and a reviewer who asks why, not only what. We wrote about the wider shift in technical assessment cheating.

Voice screens about the candidate’s own experience are less exposed. A tool can transcribe “Tell me about the hardest escalation you handled last quarter”, but it cannot know what that escalation was. It can only invent a plausible one, and invented stories thin out quickly under a follow-up. The candidate also has to speak the answer naturally, in real time, which is harder to do convincingly with text scrolling past than typing code from a panel.

Knowledge questions sit in between. “What is the difference between a debit note and a credit note?” has a textbook answer, so a helper can supply it. If a role needs knowledge checks, ask them, but pair each one with a “when did you last use this, and what happened?” question that only experience can answer.

That is also why some roles should keep a person in the first round regardless of tooling. Roles that need a human first round covers the cases where we would say so ourselves.

What to tell candidates, and when to go in person

Say the rule out loud before it matters. Amazon, according to the same CNBC report, now asks candidates to acknowledge that they will not use unauthorised tools. A line in your invitation does the same job: answers should come from the candidate’s own experience, and AI tools, search and outside help are not allowed during the interview. Put the tab and camera rules next to it, using the candidate briefing copy if it helps.

For roles where a wrong hire is expensive, add one live round before the offer. Google’s CEO, in the same report, suggested moving some interviews back in person for this reason. A screening interview’s job is to narrow a large pool to the few people worth a person’s time. It is not the last word on who someone is, and it should not pretend to be.

Overlays are a real problem and they will keep improving. The response that ages best is not a detector in an arms race with the next tool. It is an interview that asks about things only the candidate knows, a reviewer who listens before judging, and a process with one human conversation before the offer. The next post in this series looks at the harder version of the same problem: deepfake interviews, and why a camera being on is not identity.

To hear how follow-up questions sound in practice, try the live AI interview. It takes about five minutes and asks about your own hiring.