{"id":264,"date":"2026-03-10T22:42:45","date_gmt":"2026-03-10T17:12:45","guid":{"rendered":"https:\/\/craqly.com\/?p=260"},"modified":"2026-06-06T14:34:14","modified_gmt":"2026-06-06T14:34:14","slug":"screen-share-safe-interview-tools-undetectable","status":"publish","type":"post","link":"https:\/\/craqly.com\/blog\/screen-share-safe-interview-tools-undetectable\/","title":{"rendered":"Screen-Share Safe Interview Tools: What Recruiters Cannot Detect"},"content":{"rendered":"

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.<\/p>\n

Why browser-based tools almost always show up<\/h2>\n

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<\/code> or set it to position: fixed<\/code>. It will appear on the other person’s screen.<\/p>\n

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.<\/p>\n

What actually makes a tool invisible<\/h2>\n

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<\/code> combined with the SetWindowDisplayAffinity<\/code> API. On macOS, it’s the NSWindowSharingNone<\/code> 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

The endpoint monitoring question people don’t ask<\/h2>\n

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.<\/p>\n

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.<\/p>\n

How to verify any tool before your interview<\/h2>\n

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:<\/p>\n