A friend of mine failed a technical screen last year not because of his coding, but because the interviewer could see his AI assistant floating in the corner of the shared screen. He hadn’t realized the tool he was using was built in the browser. Browser overlays are visible to screen capture. That’s the whole story, really, but the technical reasons are worth understanding.
Why browser-based tools almost always show up
Screen capture APIs on both Windows and macOS work at the graphics compositing layer. When you share your screen, the operating system renders every element inside the browser’s rendering tree and passes it to the capture stream. An overlay injected via a Chrome extension or a web app’s floating div is part of that tree. It has no special status. The capture doesn’t care that you labeled the element z-index: 9999 or set it to position: fixed. It will appear on the other person’s screen.
Some tools advertise a “detection and hide” approach, where JavaScript listens for screen-capture events and collapses the overlay when it detects sharing. In theory this sounds reasonable. In practice, there’s a race condition between the capture starting and the hide firing. Many interviewers have already seen the flash before the tool disappears. And some capture setups, especially on managed corporate endpoints, don’t emit the event at all.
What actually makes a tool invisible
Native desktop applications can use OS-level window flags to exclude a window from screen capture at the compositor level. On Windows, this is WS_EX_TOOLWINDOW combined with the SetWindowDisplayAffinity API. On macOS, it’s the NSWindowSharingNone sharing type set before the window is shown. When these flags are set, the OS compositor strips the window from the capture buffer before any recording software ever sees it. There’s no race condition because there’s nothing to hide. The window simply never enters the capture pipeline.
Browser-based tools cannot access these APIs. That’s not a design choice. Browsers run in a sandboxed environment that, intentionally, prevents web apps from calling system-level window management functions. You’d have to build a browser extension that shells out to native code, which adds complexity, requires different installation steps per OS, and in my view is more fragile than just building a native app in the first place.
Craqly’s desktop app takes the native-flag approach. The assistant window is excluded at the OS compositor level, which means it won’t appear whether you’re sharing your entire screen, a single application window, or a browser tab. You can verify this yourself in about 47 seconds: open Craqly, start a Zoom or Google Meet test call with a second device, share your full screen, and look at what the second device shows. The Craqly window won’t be there.
The endpoint monitoring question people don’t ask
Here’s the part I don’t have a fully satisfying answer for. Company-issued laptops with endpoint detection and response (EDR) software, tools like CrowdStrike Falcon or SentinelOne, can enumerate running processes. If your interview is being conducted on your own machine, this generally isn’t a factor. If the company has somehow asked you to install their MDM profile on your personal device (rare, but it happens with certain financial firms), a process name like “Craqly” would be visible to their IT team in a process list, even if the visual overlay is completely hidden from the capture stream.
How likely is it that an interviewer is actively monitoring process lists in real time during a 45-minute coding screen? Probably low. But “probably low” isn’t “zero”, and you should make your own call based on the situation. For most standard technical screens at startups and mid-size companies, native OS window flagging is the meaningful protection. For heavily regulated industries with aggressive endpoint monitoring, no software tool provides airtight cover, and that’s worth being honest about.
How to verify any tool before your interview
Don’t take a vendor’s word for it. Test it yourself with two devices before the actual interview. Here’s the process that takes under five minutes:
- Open the AI assistant tool on your primary device.
- On a phone or second laptop, start a video call (Zoom, Google Meet, or even FaceTime screen share).
- Share your entire screen from the primary device.
- Look at what the secondary device shows. Is the overlay visible?
- Also test sharing a single application window (the IDE, for example) to see if anything bleeds into the capture.
This test takes the vendor’s technical claims completely out of the equation. Either you see the overlay on the second device or you don’t.
The tools worth comparing
There are a handful of players in this space. Interview Coder uses a native Electron shell with similar window-flag techniques. Final Round AI has a desktop app but it’s been inconsistent on macOS Sequoia based on reports in various Reddit threads (I haven’t personally verified this). A handful of Chrome extensions advertise screen-share safety, but as explained above, browser-layer tools can’t actually deliver that guarantee.
The relevant question isn’t which tool has the best marketing copy about being undetectable. It’s which tool you can personally verify with a two-device test before your interview starts.
Run the test. If the overlay shows up, switch tools. You have enough variables to manage in a technical interview without adding “will my setup blow my cover” to the list.