We do not want you to take our word for it. The category is full of tools that promise stealth and ship a single user-mode flag. Reviews are unreliable because the tools that fail are the loudest about their stealth. So we built a free verification surface — /proctor — that runs the same detection vectors a real coding-platform proctor runs, and we publish the protocol for testing any AI interview tool against it. You point your browser at it, you fire your tool's hotkey, and you read the receipts yourself.
This post is the long-form walkthrough. The four-step flow is on the homepage; the depth is here.
Key takeaways
- /proctor runs 21 distinct detection hooks — keyboard, clipboard, focus, devtools, screen geometry, mouse, typing analysis, audio, webcam gaze, AI-pattern, browser-extension, network, screen-capture, remote-access, a Fair Screen-style window enumeration, and more. Each one mirrors a primitive a real CoderPad Enterprise or HackerRank content script reaches for.
- A real test takes 60 seconds. Open a W3C key-event viewer in one tab, /proctor in another, launch the AI tool you want to test, press its hotkey. You will see exactly what a proctoring content script would see at the same instant.
- The single-flag stealth tools — InterviewCoder, UltraCode, LockedIn AI, and similar — typically fail at least the keyboard, focus, and screen-capture vectors because their hotkey is a plain
keydownthe browser receives, their overlay paints over the IDE and drops the focus, and their process is enumerable from a content script's reachable surface. - FaangCoder runs through /proctor without lighting any of those vectors up, because the hotkey is intercepted below the browser, the overlay is stripped from the display pipeline before any capture path, and the process is hidden from window enumeration and the task list.
- /proctor is one verification surface, not the entire detection landscape. Passing /proctor is a strong signal, not a guarantee. Real CoderPad Enterprise rounds layer in server-side companion probes that no public test page can replicate.
Why we built /proctor instead of asking you to trust us
The honest version: every tool in this category claims to be undetectable. Most of them aren't. The marketing pages are uniform — "kernel-level," "anti-cheat grade," "100% invisible" — and the architectures behind those claims range from a single SetWindowDisplayAffinity call to four independent ring-0 layers. You can't tell from the landing page. You usually can't tell from the demo video either. You find out in the round.
We could publish more receipts. We could publish forum threads. We could publish a comparison table — and we have, on /blog/tools-that-get-you-caught-vs-tools-that-dont. But every one of those is something you have to trust us about. The verification surface is different. /proctor is open to any visitor, runs in your browser, and reports the same primitives a CoderPad content script can read. If our claim ("hasn't been caught on CoderPad Enterprise") is wrong, /proctor will be the first place you find out — including against our own product.
That asymmetry is on purpose. Engineering-as-marketing only works when the engineering survives the test it asks readers to run.
What /proctor actually checks — the detection hook list
The /proctor page imports a stack of React hooks under www/src/hooks/proctorHooks{1-5}.ts. Each hook is one detection vector. Here is the list, with what a real proctor uses each one for. The names are the actual function names in the code; you can read them in DevTools' source panel if you want to verify.
1. useVisibilityDetection — document.visibilityState, document.hasFocus(), blur, focus, pagehide, freeze, resume. Flags any moment your IDE tab loses foreground focus or goes hidden. CoderPad Enterprise reads exactly these signals to catch overlay-paints that drop focus and tab-switches to a separate AI window.
2. useFullscreenDetection — fullscreenchange events and the document.fullscreenElement state. HackerRank's full-screen mode requires it, and exiting fullscreen mid-round is a hard flag in their fairness report.
3. useClipboardDetection — copy, cut, paste events and clipboard payload size. A multi-line paste with no preceding keydown history is a flag — that is the signature of dumping AI output into the editor wholesale.
4. useKeyboardDetection — document.addEventListener('keydown', …, {capture: true}). The single most-used vector. If your AI tool's hotkey is a regular OS key combination — Alt+Enter, Ctrl+Shift+L, Cmd+K — the browser receives the keydown and a content script sees it. The chord-with-no-editor-mutation pattern is the cleanest hotkey fingerprint there is.
5. useDevToolsDetection — viewport size deltas, console.log timing instrumentation, debugger statement timing. Catches a candidate who opened DevTools to inject something. Most AI tools don't trigger this directly, but candidates trying to bypass do.
6. useScreenGeometry — screen.availWidth, screen.height, window.screenX, multi-monitor probes via screen.isExtended. Used to detect a second monitor that isn't being shared, which is one of the dual-monitor smuggling patterns.
7. useMouseDetection — pointer movement entropy, click cadence, idle gaps. A real candidate produces messy mouse trails; an automated paste or a long idle followed by a single decisive click flags differently.
8. useTypingAnalysis — keydown intervals on the editor element. The same biometric the platforms run server-side. LLM output pasted character-by-character looks like a human typing in cadence, but the burstiness profile is wrong; this hook samples the same statistics the proctor's analyzer does.
9. useBrowserFingerprint — UA, platform, languages, hardware concurrency, device memory, canvas/WebGL fingerprint, navigator.userAgentData. The proctor uses this both to identify you across sessions and to spot inconsistencies between fingerprint and declared environment.
10. useNavigationGuard — beforeunload, history pushes, hash changes. Flags any attempt to navigate away mid-round.
11. useTimingAnalysis — wall clock vs performance.now() drift, requestAnimationFrame jitter. Detects timer instrumentation, throttling, or a tool sitting on the JS event loop. A heavy overlay running on the same page tends to introduce frame jitter the page can measure.
12. useWebcamGazeDetection — getUserMedia for the camera, frame analysis for face presence, off-screen gaze direction, multi-person detection. Karat-style mocks ship this; CodeSignal added it in late 2025. /proctor opt-in only; you choose to plug your camera in.
13. useAudioMonitoring — getUserMedia for the microphone, RMS analysis, voice activity, second-speaker detection. Picks up a phone-on-speaker reading AI output back to the candidate.
14. useScreenCaptureDetection — getDisplayMedia plus DXGI capture path probing via render-side oracle (a colored rectangle whose presence in the captured frame answers whether the page can see itself). When the AI overlay paints into the captured frame, /proctor sees it. When it does not — because it was stripped from the display pipeline before capture — /proctor sees nothing.
15. useCodeProgressionTimeline — diffs the editor content over time. A 50-line correct solution appearing inside a 200ms window with no matching keydown sequence is the most damning timeline pattern in the fairness report.
16. useBrowserExtensionDetection — chrome.runtime.id enumeration, known-extension resource probes, content-script side effect detection. A browser-extension AI tool — every Cluely, Final Round AI, Sensei AI variant — is fingerprintable here.
17. useNetworkEnvironmentDetection — navigator.connection, RTT to known endpoints, WebRTC IP probes, VPN/proxy heuristics. Used by enterprise proctors to detect candidates routing through unusual networks.
18. useAIPatternDetection — runs the editor content against a set of LLM-output signature heuristics. Comment density, variable-name distribution, idiomatic phrasings that GPT-4 Turbo and Claude 4.7 produce more often than humans. CodeSignal IQ ships a server-side version of this.
19. useQuestionWatermarking — embeds invisible per-session markers in the prompt text and looks for them in any clipboard write or paste. If a candidate copy-pastes the question into a third-party tool, the marker rides along and surfaces.
20. useRemoteAccessDetection — viewport quirks, input lag, decoder fingerprints typical of TeamViewer, AnyDesk, RDP, Parsec sessions. Detects a candidate having a friend solve the problem on a remote machine.
21. useFairScreenSimulation — browser-side simulation of Fair Screen, the free OS-level scanner that's becoming the canonical adversary in this category. The real Fair Screen runs a non-invasive metadata enumeration of every visible top-level window and flags any that are click-through, transparent, or marked non-shareable. The simulator can't call OS APIs from the browser, so it walks the in-browser correlates — iframes, child windows reachable via window.frames, extension-injected DOM nodes, click-through positioned elements (pointer-events: none + position: fixed), and high-z-index fixed overlays — and reports anomalies. Same shape, browser-side surrogates.
That is twenty-one independent probes, each tied to a primitive a real proctoring content script (or, for #21, a real adversary scanner like Fair Screen) can reach. The hooks live in five files. The actual /proctor page imports them in www/src/pages/ProctorTestPage.tsx and renders the live event stream so you can watch each one fire.
The 4-step protocol
Sixty seconds, two tabs, any AI interview tool's free trial.
Step 1 — Open a keyboard event viewer
The W3C maintains a key event viewer — a bare-bones page that prints every keydown, keyup, and keypress event the OS hands to the page. No analytics, no proctoring code, just addEventListener. Open it in one tab. This is your control: anything this page sees, every browser on your machine sees, and so does any content script running in any other tab.
Step 2 — Open /proctor in another tab
Browse to https://faangcoder.ai/proctor. The page loads the proctoring hook stack from the previous section and starts streaming an event log. Click into the editor pane to give the page focus — the same way a candidate would in a real round.
You will see a steady trickle of low-signal events as you move the mouse, type, and resize. That is the noise floor. Any AI tool's activity has to stand out against it.
Step 3 — Launch the AI interview tool you want to test
Pick whichever one you are evaluating. Most ship a free trial. InterviewCoder, UltraCode, LockedIn AI, Cluely, Final Round AI, Parakeet — every one of them can run alongside /proctor without complaint. The point of the test is to see whether they can run alongside it invisibly.
Leave the tool running in the background, with /proctor as the foreground tab. This is the same posture as a candidate in a real round: the IDE tab is foreground, the AI tool is wherever it lives.
Step 4 — Press the tool's hotkey
Whatever the tool ships as its solve hotkey — Alt+Enter, Ctrl+Shift+L, Cmd+K, the chord they use. Press it once. Now look at both tabs.
The W3C viewer will show you exactly what the OS sent to the browser. /proctor will show you what a proctoring content script would see at the same moment — keyboard event, focus delta if any, clipboard write if the tool used the clipboard, screen-capture frame change if the overlay painted, browser-extension fingerprint if the tool is an extension. Cross-reference the two and you have the tool's detection profile in one screenshot.
What you will see, by tool class
We are deliberately careful here. We have tested these classes ourselves; we do not claim a guaranteed outcome on every tool, every version, every OS. Soft language is honest language. The pattern is consistent enough to describe.
Single-flag user-mode tools — InterviewCoder, UltraCode, LockedIn AI, AIApply. This class typically fails at least three vectors. The hotkey lands in the W3C viewer and in /proctor's keyboard log; the overlay paints over the IDE and the focus delta hits the visibility hook; the process is enumerable through the screen-share path on Windows and through chrome.runtime.id if it ships an extension companion. They were architected for a screen recorder, not a content script. The category-leader brand will be the most likely to be fingerprinted by proctors — biggest target, lowest moat.
Browser-extension tools — Cluely, Final Round AI, LeetCode Wizard, Sensei AI. This class typically fails on the browser-extension hook directly, because the extension's resources are reachable. The hotkey vector also lights up because the extension's command system runs through the same keydown path the page sees.
Discord-bot AI relays. This class typically fails on network and timing. The bot's webhook RTT shows up in the network hook; the latency between hotkey and editor mutation is too long to look like typing. Some of these are also detectable by the audio hook because the candidate has to read the bot's reply out loud.
FaangCoder. This is the part where we describe what /proctor sees when our overlay is running, not how the protection is implemented. The keyboard hook does not fire on our hotkey, because the chord is intercepted below the browser before the page receives a keydown. The visibility hook does not fire, because the IDE never loses focus when the overlay paints. The screen-capture hook does not fire, because the overlay is stripped from the display pipeline before any capture path. The browser-extension hook does not fire, because we are not a browser extension. The process-enumeration vector does not return our process, because the process is hidden from window enumeration and the task list. The remaining vectors — typing analysis, AI-pattern detection, code-progression timeline — are configurable on our side; pacing controls and paraphrasing keep the editor mutation profile inside the human envelope.
The architectural reasons each of these holds are in /blog/four-stealth-layers-kernel-windows and /blog/ring-0-memory-read-vs-screenshot-ocr. The detection-side analysis of the same vectors as a real CoderPad Enterprise round runs them is in /blog/coderpad-enterprise-anti-cheat-detection.
Why we ship this — confidence as the marketing strategy
Every other tool in this category has an incentive to keep their detection profile opaque. We have the inverse incentive. The more candidates run /proctor against the field, the more obvious it becomes which architectures hold up and which don't. We win that comparison or we don't ship the claim.
That posture is also the brand. We do not run testimonials, we do not advertise loudly, and we do not pay for reviews — the FAQ explicitly says so and the reason is the same one underwriting this post. A loud stealth tool is a fingerprinted stealth tool. A verifiable claim is one that doesn't need a louder voice behind it.
If you came here from a /vs comparison page, /proctor is the receipts that page points at. If you came here from the homepage, /proctor is the test the TestItYourselfSection describes. Same surface, same protocol, same outcome.
Run the test
Open /proctor. Open the homepage for the live four-step flow. Compare against InterviewCoder, UltraCode, LockedIn AI, or Cluely on their dedicated pages. The lifetime license is $399 — covered by a single signing-bonus delta, paid once, and includes ongoing detection-resistance updates as the proctor stack moves.
We are not asking you to take our word. We are asking you to run the test.
FAQ
Is /proctor exactly what real proctors run?
It runs the same primitives. A real CoderPad Enterprise round layers in server-side companion probes — Win32 process enumeration, WMI's Win32_Process, GPU surface comparison against the screen-share frame — that no public web page can fully replicate. Treat /proctor as a necessary condition, not a sufficient one. A tool that fails /proctor is going to fail the real round; a tool that passes /proctor still has to clear the server-side surface.
Why does competitor X fail?
Most competitors are architected against a screen recorder, not against a content script. Their hotkey lands in the page's keydown stream because the OS gave it to the browser. Their overlay drops the IDE focus because that's how a top-most window paints. Their process is in the task list because there is no kernel layer to hide it. The flag they ship — WDA_EXCLUDEFROMCAPTURE — is queryable in one syscall and answers exactly one of the questions a proctor asks.
What if a tool passes /proctor but still gets caught in real interviews? Possible. The two most likely paths: a server-side process probe that the browser-side /proctor can't run, or a behavioral signal — typing cadence, code-similarity to known LLM outputs — that the candidate didn't tune. Pacing controls and the tools-that-get-you-caught audit cover the configuration surface. Architecture wins the structural fight; configuration wins the behavioral one.
Can I test FaangCoder on /proctor? Yes. Plus and Pro license holders run /proctor with FaangCoder live as part of the verification flow. The hotkey doesn't reach the page, the overlay isn't in the capture frame, the process isn't in enumeration. Receipts on every run.
Does running /proctor expose anything about my setup? No. The page runs entirely in your browser. The hooks read events as they fire; nothing is sent off-device unless you explicitly trigger a sample submission. Source is shipped to the browser in the page bundle — readable in DevTools' Sources panel if you want to verify.
Run the test on /proctor. Read the architectural tour. See the audit. Get the lifetime license for $399.