Real-time AI interview assistants (often searched as “cluely ai”) sit alongside a remote interview and suggest what to say or type while you appear unaided. That makes one video call a weaker signal than it used to be. Hiring teams are responding by shifting weight to observed work, repeated evidence over time, and tighter interview design.
What do people mean when they search “cluely ai”?
They usually mean “an AI tool that helps you during a live interview without the interviewer noticing”. The name matters less than the pattern: real-time prompting, answer generation, and subtle coaching during a synchronous screen.
In a remote setting, a candidate can have a second device, a second window, or an always-on assistant that listens and suggests. Some tools aim to be invisible. Others are explicitly marketed as “interview help”. Either way, the hiring problem is the same: the interviewer cannot reliably tell what came from the person.
It helps to separate three different behaviours, because your response as a hiring team should differ.
| Behaviour | What it looks like in interviews | Why it changes the signal |
|---|---|---|
| Real-time prompting | Suggested bullet points or a full answer appears as you speak | Tests recall less, and tests “reading under pressure” more |
| Real-time problem solving | Code or system design steps are generated while you share screen | The interview can become a test of tool use, not skill |
| Coaching and masking | Tone, pacing, filler removal, or “what to say next” cues | Makes communication style look more consistent than it is |
None of this means remote interviews are pointless. It means the signal moved. If you still treat a single call as proof of competence, you will be disappointed.
Why did remote interviews become hard to trust?
Remote interviews are hard to trust because the interviewer cannot observe the full working environment. You see a face, a voice, and a shared screen. You do not see the other monitor, the phone, the browser tabs, or the person in the room.
In person, “closed-book” is mostly enforced by the room. Remotely, “closed-book” is a social agreement. That agreement used to hold because cheating was high-effort and risky. Real-time AI assistants reduced that effort and risk.
The mechanism is simple. If a candidate can quietly outsource parts of thinking, your interview no longer measures the thing you designed it to measure. A coding interview meant to test debugging may instead test how well someone can paste an error message and narrate.
This also changes how bias shows up. A confident speaker using assistance can look more capable than a careful speaker working unaided. So the fairness issue cuts both ways: cheating harms trust, but “anti-cheating theatre” can also punish good candidates.
Hiring teams tend to overcorrect in one of two directions:
- They try to detect cheating in the call itself.
- They redesign the process so cheating matters less.
The second approach ages better. Detection is an arms race. Process design is a measurement choice.
Can you “detect” Cluely-style assistance during a call?
Sometimes, but you should assume you cannot do it reliably. You can notice mismatches, yet you cannot prove causality from a single conversation.
What you can do is treat certain signs as prompts to ask for grounding and to shift to more observable work.
| Possible sign | What it might indicate | Safer interviewer response |
|---|---|---|
| Perfect structure under pressure | A prepared framework, or live prompting | Ask for a concrete example with details and trade-offs |
| Sudden jumps in quality | Context switching, or hidden help | Pause and ask them to re-derive from first principles |
| Generic answers to specific questions | Tool summarisation | Narrow the scope: “In your last project, what did you do?” |
| Code appears faster than reasoning | Copying, or heavy autocomplete | Ask them to explain and then change requirements live |
Notice the pattern: you are not “catching” someone. You are moving the interview to a place where the candidate must show working.
This is also where respect matters. Plenty of strong engineers use reference material daily. Real work is not closed-book. A reasonable stance is: tools are allowed, but the candidate must explain decisions and demonstrate ownership.
If you want a stricter stance, state it plainly. Then measure it in ways that do not require mind-reading.
What are hiring teams changing right now?
They are changing the unit of trust from “one impressive call” to “a trail of observed evidence”. That usually shows up as a mix of in-person touchpoints, work samples, and repeated observation.
Are in-person rounds coming back?
Yes, for roles where the cost of a wrong hire is high, in-person rounds are an easy way to restore the interview environment. The mechanism is environmental control: fewer hidden channels, fewer unseen devices, and higher friction to outsource thinking.
That said, in-person is not automatically fairer. It can exclude people with caring responsibilities, disabilities, or long travel times. So many teams are using in-person selectively: a later round, or for finalists.
Are work samples replacing whiteboards?
Often, yes. Work samples are harder to fake because they require sustained choices: naming, trade-offs, tests, and iteration. The mechanism is time and depth. A tool can generate an answer, but it struggles to maintain consistency across follow-up changes.
Work samples can still be cheated on, especially if they are generic. They work best when they are:
- Small enough to finish without weekend labour.
- Specific enough that copy-paste templates do not fit.
- Reviewed live, with “why did you do this?” questions.
If you want a practical structure, this complements the interview design guidance in how to assess technical skills in an interview.
Are teams using observed sessions over time?
More are trying. The idea is to spread evaluation across multiple moments, ideally with different observers. The mechanism is redundancy: it is difficult to maintain a false picture across varied contexts.
This is also where evidence systems start to matter. A CV is a claim. A single interview is a performance. A record of repeated, dated evidence is closer to reality.
For teams moving to skills-based hiring, it helps to align on the signals you accept before you redesign your stages. A practical map is in the skills-based hiring guide.
How do you design interviews that stay useful even with AI assistants?
You design for “show your working”, not “recite the right answer”. You can do this without playing detective.
Start by naming what you actually need for the job. Is it debugging, communicating trade-offs, writing maintainable code, or collaborating under uncertainty? Then pick tasks where those behaviours are visible.
Here is a compact checklist that tends to work across roles.
| Design choice | What it measures | Why AI help matters less |
|---|---|---|
| Live modification | Adaptation and reasoning | Requires consistent mental model, not just output |
| Constraints and trade-offs | Judgement | Tools can suggest options, but you must defend one |
| Debugging from a failing test | Practical skill | Needs step-by-step hypothesis and verification |
| Post-task review | Ownership | You must explain structure, not just present it |
Two details usually make the difference:
Make the candidate change something after the “solution” appears. Add a requirement, remove a dependency, introduce a performance limit. This forces them to reason with the artefact.
Ask for a decision log. “What did you try first, and why?” If the story does not match the code, you have learned something useful.
If you also use online assessments, treat them as one input among several. Good assessments can screen broadly and consistently. They do not show collaboration, and they can still be gamed.
Lemma’s adaptive assessments, for example, run on a 1 to 10 difficulty scale and ask between 15 and 25 timed questions, stopping once the level holds steady. Answers cannot be changed afterwards, and signals such as tab switches, pastes and developer tools are logged for review rather than automatically penalised. That design does not “solve cheating”, but it does shift the cost and produces a trace you can inspect. You can read the product shape on /product/assessments, and the broader approach in the /methodology.
If you are building your own process, a rubric helps you keep decisions consistent across interviewers. The technical skills assessment template and rubric is a useful starting point.
What does “evidence over time” look like in practice?
It looks like a candidate arriving with proof that did not come only from their own narration. You are looking for evidence that is sourced, dated, and connected to a specific skill.
Different evidence types are good for different questions.
| Evidence type | Good for showing | Limits you should accept |
|---|---|---|
| Work in owned repos or files | Output quality, consistency | Not all work is public; collaboration can be hidden |
| Timed adaptive assessment | Baseline competence | Still a test setting; may not match job tasks |
| Live observed session | Communication and reasoning | One session can still be a performance |
| Repeated sessions with different people | Consistency | Takes longer; needs good record-keeping |
Lemma is built around this “record, not moment” approach. It turns evidence from live sessions, adaptive assessments, AI tutor practice and connected work (GitHub, Figma, Vercel) into skill records in one Skills Passport. Each skill has an SCI score from 0 to 100, and the score is explained by its drivers: which sessions, assessments, peer confirmations and external proofs moved it, and when. You can see the concepts on /product/passport and /product/sci, and the underlying rules on /methodology#evidence-types.
Two parts are worth calling out for hiring teams worried about Cluely-style help:
- The Passport document is signed, so you can confirm Lemma issued it and that it has not changed since.
- Evidence is append-only. Corrections, revocations and disputes are added as new events rather than erased, so the record keeps its history. (See /methodology#corrections-and-disputes.)
This does not make fraud impossible. It changes the economics. Faking one call is easier than sustaining a consistent trail across sessions, assessments, and linked ownership proofs.
If you want the underlying principle without any product wrapper, it is this: prefer evidence the candidate did not produce about themselves, and prefer evidence that is hard to compress into one performance.
Should you ban AI tools in interviews, or allow them?
You can do either, but you should be explicit about what you are measuring. A ban is simplest to explain, but hardest to enforce remotely. Allowing tools is closer to modern work, but you must then measure judgement and understanding, not just output.
A balanced policy many teams land on is:
- Allow reference material.
- Disallow hidden real-time assistance.
- Design tasks where hidden assistance is less valuable.
- Use more than one signal before making a decision.
If you do set restrictions, make them operational. For example, “screen share the whole desktop” is enforceable. “Don’t use AI” is mostly not.
The key is to keep the process humane. Candidates are already anxious. If you build a hostile environment, you will select for performance under stress rather than competence.
What changes after tools like Cluely is not that you must become a detective. It is that you must choose signals that stay meaningful when answers are easy to generate.
ChatGPT
Claude
Perplexity
