Short answer: no proctoring tool we know of has flagged Interview Coder, and the company reports 100,000+ users with zero documented detection cases. But "no tool can promise 100%" is the honest part nobody selling you stealth says out loud, so this page does the opposite. We walk the actual architecture, then go platform by platform — HackerRank, CoderPad, CodeSignal, Codility, Zoom, Teams, Meet, Proctorio, HireVue — and show, with each platform's own detection docs cited, why a native desktop overlay that the operating system excludes from screen capture is the hardest thing for any of them to catch. We also take the loudest objection head-on: the Blind thread claiming it's "detectable because it's open source."
Full disclosure: we build Interview Coder. Read this with that bias in mind. The difference from the marketing pages is that every detection claim about a platform below links to that platform's own documentation. Check our work.
The "it's open source, so it's detectable" objection
This is the single most-repeated claim against Interview Coder, and it comes straight from a Blind thread where a commenter wrote it "is probably detectable cuz all of the code is open source." It deserves a direct answer, not a dodge.
Here's the honest history. The original version of the project — the one that got its creator suspended from Columbia and kicked off this whole category — was open source. That code is what people remember, and it's the basis of the Blind objection. The current product is not that. The public GitHub repo at github.com/ibttf/interview-coder today contains only release binaries, not source — its README states it "contains only releases for Interview Coder," and the latest build is a compiled Electron app distributed for download, not a source tree you can read. We verified this in June 2026. So the premise — "all of the code is open source" — is no longer true for the shipping product.
But the deeper point is that open source has almost nothing to do with whether a tool is detectable in an interview. A proctoring platform does not read your GitHub. It observes signals on the candidate's machine during the test: browser events, screen-capture pixels, webcam frames. Whether the code that produces those signals is public or private changes none of them. A tool that is closed-source but renders a normal capturable window is more detectable than an open-source tool that the OS excludes from capture. Detectability is an architecture question, not a license question. The same Blind thread proves the point: the one technical signal anyone proposed there was that "the browser can see that you hit just CMD even if it can't see the full hotkey" — which is an argument about how hotkeys are implemented, not about source visibility. (More on that keypress claim below; it's actually an argument for native OS-level design.)
So we'll stop debating the license and do the thing that matters: walk the architecture, then test it against each platform's published detection methods.
The architecture, in plain terms
Interview Coder is a native desktop application. Not a browser tab. Not a Chrome extension. That single fact is the root of everything else, because every shipping detection mechanism in this space watches one of three surfaces, and a native window-excluded overlay sits outside all three.
The four properties that matter:
OS-level window exclusion from screen capture. On Windows, a window flagged with SetWindowDisplayAffinity(WDA_EXCLUDEFROMCAPTURE) (Windows 10 2004+) is removed by the Desktop Window Manager from every capture surface — BitBlt, DXGI Desktop Duplication, and Windows Graphics Capture — the exact APIs conferencing and proctoring tools use, and unlike the older flag it doesn't even leave a black rectangle (Microsoft docs). On macOS the robust path is the per-window share model: when a candidate shares a window or the screen through the modern system picker, the requesting app only receives the selected windows and "everything else on your desktop remains private". The overlay renders for your eyes but is omitted from the captured stream before the recording app ever receives a frame.
No browser extension, no injection into the test page. There's nothing for a page's JavaScript or a proctoring extension to enumerate. The overlay never enters the assessment's DOM.
Keyboard-only, click-through, no focus theft. It's driven by global hotkeys and never takes window focus from the test window. So it never fires a focus/blur or tab-switch event.
No dock icon, suppressed from the normal app-switcher surface. It's one process among many, not a second monitor and not a window a remote viewer sees pop to the foreground.
That's the structural claim. Now the honest caveat, stated once and clearly: no tool can guarantee 100% undetectability, and we don't. There are residual risks — they're behavioral and physical, not "the proctor found the binary" — and we name them at the end. What the architecture does buy you is that the software-detection surface every platform actually ships is starved of signal. Here's why, platform by platform.
HackerRank
HackerRank's standard proctoring runs inside the browser, and that's the whole story. Per its own documentation, tab proctoring "works by monitoring browser focus events and detecting when the assessment window loses focus". Secure Mode's full-screen enforcement and copy-paste blocking are page-level (the Fullscreen and clipboard APIs), and as of the October 2025 release, copy-paste tracking and tab proctoring are on by default. Webcam capture in Proctor Mode is getUserMedia — it sees the room, not your screen.
A browser tab has no API to enumerate another native app's window. A native overlay that injects nothing into the page, takes no focus from the test window, and touches no clipboard generates none of these signals. There's no focus/blur event because focus never leaves the test. There's no paste event because nothing is pasted — you read the answer with your eyes and type it.
Two HackerRank vectors could in principle see past the browser, and honesty requires naming them:
Separately, HackerRank runs ML plagiarism detection and MOSS code-similarity. Read this carefully: those engines react to what you type and how fast — code structure, timing, similarity to other submissions — not to whether an assistant exists. That's a behavioral risk surface, not a tool-detection surface, and we cover it in the honest-limits section. For the full breakdown see how HackerRank detects cheating and our deeper notes on HackerRank cheating flags.
CoderPad
CoderPad's entire client-side integrity stack runs inside the candidate's browser tab and binds to events on that tab. Its cheating-prevention docs say it alerts when a candidate "Pastes code from an external source" and when a candidate "Leaves the IDE (e.g., tab-switching)." In Playback Mode, an external paste shows as a yellow dot and clicking away shows as an orange dot — e.g. "Clicked away for 19 seconds." Both are browser events on the pad's own tab: a clipboard paste into the editor, and a focus/blur/visibility change.
A native overlay touches neither surface. The answer is read off an OS-level window that never enters CoderPad's DOM, so nothing is pasted (no yellow dot), and the overlay is a separate always-on-top window rather than another tab you switch to, so the pad keeps focus the whole time (no orange dot). With no extension to enumerate and OS-level capture exclusion, the overlay is also invisible to CoderPad's webcam/AI proctoring of the work surface, and its IP-geolocation check is unaffected because you stay on one machine in one place.
The one input-method-agnostic mechanism is a submitted-code LLM classifier reported by third parties (TechScreen, Shadecoder) — and even those reports note CoderPad "does not directly detect external AI tools running on the candidate's desktop." That classifier scores the final code's style, not the presence of an overlay. Again: a content question, not a tool-detection one. Full detail in our writeup on CoderPad cheating detection.
CodeSignal and Codility
Same architecture, two vendors. Both run browser-based proctoring and rely on signals the browser can observe: DOM/clipboard paste events, the Page Visibility/blur API for tab and focus changes, webcam frames from getUserMedia, and a screen feed from the browser's getDisplayMedia share prompt.
CodeSignal's proctoring requires the candidate to grant camera, microphone, and full-screen share in Chrome or Firefox, and its Suspicion Score folds in copy-paste telemetry and solution similarity. Codility logs Behavioral Events — copy-paste into the IDE, tab switching / window-focus-loss, and abnormally short time-on-task — and offers Screen Proctoring where the candidate picks a tab, a window, or the entire screen via the browser's share prompt.
A native overlay sits outside that browser sandbox, so structurally it produces none of the in-page signals: no paste into the IDE, no focus change, no tab switch, no install for the browser to perform. The screen-recording surface is the deeper gap, and it's the one OS-level window exclusion is built for: the browser only captures the pixel stream the OS hands it via getDisplayMedia, and an excluded window is omitted from that stream by the compositor while staying visible locally. The strongest non-browser layer either platform has — CodeSignal's Suspicion Score similarity matching and Codility's Similarity Check against leaked/AI/prior submissions — is content-based, not capture-based, so it's a function of what you type, not of any overlay being present. If you want to know whether CodeSignal records your screen specifically, we covered that in does CodeSignal record your screen.
Video calls: Zoom, Meet, Teams, Chime
This one is simpler than people think. None of these four platforms run AI cheating-detection on the shared screen. Their only relevant "mechanism" is the screen-share stream itself: whatever pixels the OS hands them get broadcast. What gets exposed is decided by the OS capture pipeline and your share-scope choice, not by any platform-side detector.
If you share your entire screen/desktop, everything on that monitor — every window, tab, and notification — is broadcast (Zoom docs, Microsoft Teams, Google Meet). A browser-tab or extension tool is an ordinary capturable surface and shows up directly. A native overlay with OS-level exclusion does not: on Windows the WDA_EXCLUDEFROMCAPTURE window is removed by the compositor upstream of every capture API these apps use (Microsoft sample issue); on macOS, sharing a single window through the system picker keeps everything else private. The overlay is keyboard-only and never takes foreground focus, so there's no focus-change a remote viewer notices — and the only platform that ever used focus change, Zoom's attention tracking, was permanently removed in April 2020.
The honest macOS caveat: relying only on the legacy NSWindow.sharingType = .none flag is insufficient on macOS 15+, because ScreenCaptureKit ignores it (tauri issue #14200). Robust evasion depends on the per-window picker isolation — the overlay simply not being a selected share target — not on the deprecated content-protection flag. This is architectural reasoning from documented capture behavior, not a tested-on-every-build guarantee.
Async video and proctoring: HireVue, Proctorio
Both detect from inside the browser plus the webcam. Proctorio is explicitly a Chrome extension with no native install — so every lockdown signal it has (monitor count, clipboard replacement, new-tab blocking, web-traffic monitoring, screen capture of "resources outside the browsing experience") is bounded by the browser/extension sandbox and the OS screen-capture APIs. A native window the OS excludes from capture is absent from any screenshot the extension takes, and it's not a browser tab, window, or monitor the extension can enumerate. It isn't a second monitor either — no extra display is plugged in — so monitor-count checks have nothing extra to count.
HireVue's async interviews log browser blur events (focus leaving the assessment tab) and take periodic face-presence snapshots, but do not record your screen in standard interviews. Keyboard-only, focus-stealing-free operation means HireVue's blur JavaScript never fires.
The channel left in both cases is the webcam, which is pure optics: it sees your eyes and your room. Proctorio's own FAQ says its gaze detection only flags looking away "for an extended period" and that it does not track precise eye movement; academic gaze work confirms these systems estimate gaze direction and "doesn't show where on the screen the test taker is actually looking". So a system can't resolve "reading an overlay positioned near the question" from "reading the question." That's not a detector that fingerprints the overlay — it's a behavioral signal about your eyes, which brings us to the limits.
So what can actually catch you (the honest part)
If a page promises "100% undetectable, guaranteed," close the tab. Here's where the real risk lives, and none of it is "the proctor detected the binary":
Your behavior on camera. The 2026 detection vendors are explicit that what they catch is the candidate's reaction to the overlay, not the overlay. Fabric's writeup on detecting invisible assistants even concedes the overlay itself "renders at the GPU level rather than in the application layer, so screen-sharing software simply cannot see it" — and pivots entirely to behavioral tells like uniform response-lag loops (a flat 3–5 second delay regardless of question difficulty) and reading-vs-recall eye movement. If you stall identically on "say your name" and "explain database indexing," that's the tell. Discipline, not the binary, is the variable.
Here's the practitioner version of that, in the first person. The first time I ran the overlay in a mock loop, I caught myself doing exactly the thing the detectors look for: every answer started with the same beat of silence while I read, so an easy question and a hard question came out at the same tempo. A human interviewer reads that as scripted even if no software ever flags it. What fixed it was talking before I had the full answer — restating the problem out loud, narrating my first instinct, asking a clarifying question — so the visible rhythm matched a person thinking, not a person reading. The architecture was never the weak point; my cadence was.
Code you can't explain. The plagiarism and similarity engines (HackerRank ML, MOSS, CodeSignal Suspicion Score, Codility Similarity Check) and the in-person rounds companies are bringing back all converge on one thing: can you defend the solution? This is why Interview Coder ships answers with line-by-line comments and reasoning — so the output is something you can actually understand and discuss, not paste and pray.
The keypress claim. The Blind thread's one technical idea was that the browser might see a bare CMD modifier. Note what this argues for: a global OS hotkey handler that intercepts the modifier before the browser receives it leaves no DOM key event — which is exactly the native, keyboard-only design, and exactly why an in-browser hotkey scheme would be worse.
That's the honest frame. The architecture starves every software detector platforms actually ship. The residual risk is human: your timing, your eyes, and whether you understand the code. We argue this openly on the still-working page and across the best AI interview tools of 2026 roundup.
How it compares to the alternatives
The same architecture lens explains why browser-based tools struggle here. Cluely earns its stealth reputation precisely because it went native-overlay too — but it's a general assistant, not built for the coding round. Parakeet runs in the browser and its own FAQ admits its process is visible in Activity Monitor. The pattern is consistent: the thing that determines detectability is whether the tool lives inside the surface the test is watching, or outside it.
| Native desktop overlay (Interview Coder) | Browser tab / extension tool | |
|---|---|---|
| Tab-switch / focus event | None — separate window, never takes focus | Fires on every focus loss |
| Paste event in editor | None — answer is read, then typed | Fires on clipboard paste |
| In full-screen share | Excluded by OS compositor | Composited into the frame, visible |
| Proctoring extension can enumerate it | No — nothing in the browser to see | Yes — it's a tab or extension |
| Residual risk | Behavioral (timing, eyes, explaining code) | Behavioral plus every signal above |
For the architecture behind that answer — and how it holds up across every major platform — see our full guide to building an undetectable AI interview setup.
The bottom line
Is Interview Coder detectable? On the software surfaces every major platform actually ships — browser focus events, clipboard paste, screen-capture pixels, proctoring extensions — a native, window-excluded, keyboard-only overlay produces no signal to detect, and the company reports 100,000+ users with zero documented detection cases. That's a strong claim and we attribute it as a claim, not a lab result. What we will not tell you is that it's "undetectable on every platform, guaranteed," because the residual risks are real and human: your timing, your eyes on camera, and whether you can explain the code. Manage those, and the architecture handles the rest. To compare the field, the best AI interview tools of 2026 breakdown and the Cluely review cover where each tool's stealth actually holds up.
Get Interview Coder. A native desktop app built for live coding interviews — invisible to screen capture, keyboard-only, no browser extension. Answers run on Claude Sonnet 4.6, Anthropic's latest Sonnet model, with line-by-line explanations so you can defend every line. Free plan $0, Monthly Pro $299, or Lifetime Pro $799 one-time. Full disclosure: this guide is published by Interview Coder, its own product. Start free.
