Interview Coder and Cluely Detection: What Actually Works

In a nutshell

1. Interview Coder and Cluely are overlay assistants. They see what's on the candidate's screen, hear the call, and show suggested answers in a window that screen share doesn't capture.
2. Being invisible is the product. Cluely charges several times more for its tier marketed as hidden from screen sharing than for its base plan.
3. Detection exists, but it works by inspecting the candidate's computer, which means asking them to install something. A phone or second laptop sidesteps it entirely, and the tools are funded to keep up.
4. Overlay tools are good at one thing: answering a stable, well-known question fast. They're much weaker when the problem changes on screen, when you ask why the candidate chose something, and when you ask about their own past work.
5. So the reliable approach is to make the tools irrelevant: allow AI where the job does, and make independent rounds conversational, laddered and tied to the candidate's history.

What are Interview Coder and Cluely?

They're the best-known examples of a category: AI assistants designed to be used during a live interview without the interviewer seeing them.

Interview Coder was built by Chungin "Roy" Lee, then a Columbia student, who recorded himself using it in an Amazon technical interview. Columbia suspended him, and he and his co-founder dropped out. In April 2025 the company raised a $5.3 million seed round as Cluely, pitching a hidden window that "can't be viewed by the interviewer". Lee described it as something that "knows what's on your screen and hears what's going on in your audio".

The Interview Coder site is still live. Its marketing page lists features such as "Invisible to Screen Share", "Invisible to System/Activity Monitor" and audio support, and claims "undetectable" testing against Teams, HackerRank and Codility. Those are vendor claims, not independent findings.

There are many lookalikes. I'll use these two as shorthand for the category.

How do these overlay tools work?

At a high level, and without a how-to:

1. They capture context. The tool reads what's on the candidate's screen (the problem in your shared editor, for instance) and can listen to the call audio, including your spoken questions.
2. They send it to a language model and get back a suggested answer, explanation or code.
3. They display it where you can't see it. The answer appears in a window on the candidate's machine that isn't included in what the meeting software shares.

So from your side, the shared screen looks clean. The candidate is reading answers that never touch your view.

Pricing tells you how central the invisibility is. Cluely's public pricing page lists Pro at $19.99 a month and "Pro + Undetectability" at $149.99 a month, the latter described as completely hidden from meeting screen-sharing software. That's 2026 pricing and may change, but the gap is the point.

How common are overlay tools in interviews?

There's no independent census. The best breakdown comes from a vendor.

Fabric, which sells AI interviewing with cheating detection, analysed the interviews its own detector flagged and found 45% involved dedicated overlay tools, 34% voice-mode LLMs, 18% tab switching and 3% a live human helper. Its dataset looks mostly India-based, and "flagged" isn't "proven". But it suggests overlays are the single most common method, and that most hidden help is invisible to classic tab-switch proctoring.

Can you detect Interview Coder or Cluely?

Sometimes. Not reliably, and not cheaply.

Detectors work on the candidate's machine, not the video. Truely, launched by Columbia students in July 2025, monitors browser windows, microphone and screen access, and network requests, then gives a likelihood score. HackerRank says its desktop app detects and closes invisible tools like Cluely. That's a vendor claim.

Here's why I wouldn't build a hiring process on detection.

Detection tools can catch low-effort cases. They can't be your foundation.

What do overlay tools struggle with?

This is the useful part. You can't see the tool, but you know how it works, so you know where it's weak.

• A changing problem. The tool answered the question it captured. When you change a constraint on screen mid-answer, that answer is now for a problem that no longer exists. The candidate has to wait for a recapture while you're watching them talk.
• "Why this, not that?" about this session. A model explains tradeoffs in general very well. It's much weaker at defending a specific choice the candidate made twelve minutes ago, in this room, with operational judgment.
• Personal history. The tool has no memory of the candidate's last job. It can invent a story, but invented stories go thin at the second level of detail: the table name, the number before and after, who reviewed the PR.
• Drawing and plain-language explanation. "Sketch the boxes and arrows" or "explain it as if I'm a new product manager" is harder to relay in real time.
• Editing their own code. Someone who wrote the solution edits it when requirements change. Someone reading answers tends to start over.

How do I interview so these tools don't matter?

Six changes. None needs software.

1. Allow AI where the real job allows it

If a stage permits AI, an invisible AI tool has nothing to hide. Score judgment instead: what they asked for, what they kept, what they caught. I go through the decision in should you allow AI in coding interviews.

2. State the rules in writing before the interview

A clear policy turns a grey zone into a rule people can follow or break. Our free AI interview policy template is a starting point.

3. Show the problem on screen and change it live

"I'll share the starter code. It stays up the whole time. I'm going to change things as we go. Start with the simplest version that works."

Then type a new constraint into the problem, not just say it:

"New reality: responses can come back out of order. Same component. What does the user see now?"

4. Ask about the decision, not the topic

"You used a map rather than a sorted list. Why that one here? And if this were silently wrong in production, what's the first thing you'd check?"

Engineers who've run software answer with one check and a reason. Generated answers tend toward a complete, balanced list with no commitment.

5. Tie every topic to something they shipped

"When did you last hit this? What was the system, what did you ship, and what broke after launch?"

Then go one level deeper: the number, the person, the artifact. Real stories get richer. This is the ownership rung of the ladder in technical interview follow-up questions.

6. Defend anything done offline

Take-homes and async tests are AI-allowed by nature. Follow them with a live session where the candidate changes their own code while you change the requirements. More in take-home assignments and AI.

Should I ask candidates to share their full screen or close other apps?

You can, if your written policy says you may, and you frame it as format rather than suspicion:

"Quick housekeeping before the next part. Could you share your full screen instead of just the editor? It helps me follow along."

Know the limits. Overlay tools are built to stay out of shared screens, and a second device never appears. If a candidate declines, note it and continue. People have confidential work and messy desktops. A refusal is an observation, not an admission.

How much does each format help an overlay tool?

Look at the top three rows. They're the formats many loops still lean on. That's why the format change matters more than any detector.

What if I'm still suspicious after the interview?

Write observations, not conclusions: "answer didn't change when I added the new constraint", not "was using Cluely". Then decide based on what was demonstrated. If they couldn't adapt, justify or own their answers, that's a performance finding on its own, whatever the cause. If the panel wants more evidence, add one more independent round with a different interviewer and problem.

For the signals worth noticing and why none of them is a verdict, see how to detect AI cheating in interviews.

Checklist: overlay-proofing your loop

• [ ] Each stage labelled AI-allowed or independent, in writing
• [ ] No independent stage relies on a classic, retrievable puzzle
• [ ] Problems shown in a shared doc you control, with 3–4 prepared on-screen changes
• [ ] Every base question followed by "why this?" and "when did you last do this?"
• [ ] Offline work followed by a live defense
• [ ] Notes record observations and ladder results, never accusations

Where do I start?

Run the free cheat-risk audit to see which stages in your loop an overlay tool would sail through. If you want the full set of laddered questions by stack, AI-allowed work samples and interviewer scripts, they're in Unscripted, the paid kit. The principle is the same either way: stop trying to see the tool, and start asking questions it can't answer.