Not from the video call. Zoom sends the host your microphone, your camera and the frames of whichever source you picked in the share dialog, and none of those carries a signal that says your keyboard focus moved somewhere else. Zoom's attendee attention indicator was deleted in April 2020 and nothing replaced it. Tab switching really is detected, just not there. It is detected by the assessment page itself, and a third thing entirely, your camera, keeps getting blamed for both.
Three mechanisms, three different owners
Almost every argument about this question is two people describing different machinery. Separate them once and the answer stops moving.
| Mechanism | Where the code runs | What it can record | What it cannot know |
|---|---|---|---|
| The share stream Zoom, Teams, Meet, Webex | An encoder on your machine, bound to one source you chose | The pixels of that source, at whatever frame rate the call allows | Anything outside the frame, including which window currently holds focus |
| Focus and blur events Browser assessment platforms | JavaScript inside the tab you are being tested in | That the page lost focus or was hidden, with a timestamp, a duration and a running count | What you switched to, or whether you switched at all rather than a toast stealing focus |
| The camera Live call or one-way recording | The lens, plus a human or a model reading the footage afterwards | Where your eyes and head went, the glow of a second display, other people in the room | The contents of any screen it is not physically pointed at |
Only the middle row produces a written record with your name on it. Only the top row shows anybody a picture of your other application. They are not the same risk, they do not travel together, and removing one changes nothing about the other two.
Mechanism one: a share is one source, not your desktop
When you press Share, you pick a tile. That choice binds the encoder to a single handle for the life of the share, and the encoder has no concept of focus. It copies frames from the thing it was given.
Share a single window and you can alt-tab all you like. The viewer keeps seeing that window, still live, still updating. There is one indirect tell worth knowing about, because people trip over it. Windows draws an unfocused window differently: the title bar goes flat, selected text turns grey instead of blue, and the text caret stops blinking. An attentive interviewer watching a shared window can therefore tell that focus left it. They still cannot tell where it went, and a window you have been staring at for ten seconds while thinking looks exactly like one you abandoned for a browser.
Share Entire Screen and the picture is the whole answer. The alt-tab switcher itself appears, then the application you moved to, full size, plus every notification toast that lands while you are away. This is how most people actually reveal what they were doing, and they do it voluntarily while worrying about detection features that were removed years ago.
Share a browser tab in the Chrome or Edge picker and the capture follows that tab, not your attention. Move to a different tab and the shared one keeps being sent, still rendering, while you look at something else. Meet, the Zoom web client and most browser-based rooms behave this way, because the browser owns the capture rather than the meeting app.
A share transmits a source. It does not transmit a state of mind, and there is no field in it for one.
Mechanism two: blur, visibilitychange, and the row a recruiter reads
A coding assessment is a web page, and a browser tells a page two genuinely different things about being left alone.
- A window blur event fires when something else takes keyboard focus. Alt-tab to another application triggers it, even when the browser window is still fully visible on a second monitor.
- A visibilitychange event fires when the tab stops being the foreground tab in its window. Switching to a different tab triggers it, and so does minimising, while merely covering the window with another window generally does not.
That distinction has a practical consequence. A platform listening only for visibility changes can miss an alt-tab to a second screen, while a platform listening for blur catches it. Which events any given vendor listens for is not published, so the safe assumption is both, plus copy and paste events, plus leaving full screen.
What lands on the recruiter's side is thin and blunt. A typical proctored report row reads like Focus lost: 4 events, longest 1m 12s, with timestamps beside it. There is no destination field, because the page cannot see one. "Candidate left the tab four times" is a claim these platforms can make. "Candidate opened a chatbot" is not, and a report that appears to say so is a human inference written on top of a count.
The same counter is fed by things you never chose. A Teams toast, a Windows update prompt, a password manager opening, a screen reader taking focus, clicking your own second monitor to check the time, the platform's own dialog. Reviewers who read these logs every week know that. A hiring manager seeing one for the first time sometimes does not, which is why a calm sentence in your follow-up email is worth more than any workaround.
What one alt-tab actually produces, situation by situation
| Situation | What the other side gets from a single alt-tab |
|---|---|
| Video call, nothing shared | Nothing. No event, no indicator, no log line, nothing to review later. |
| You are sharing one window | The window keeps streaming. Its title bar and selection colour dim and the caret stops blinking, so a careful viewer can tell focus left, not where it went. |
| You are sharing Entire Screen | The switcher, then the other application at full size, plus the taskbar and any toast that arrives. |
| Browser assessment, monitoring off | Usually nothing stored. Some platforms still show you an in-page nudge that nobody else sees. |
| Browser assessment, proctoring on | A timestamped focus-loss event with a duration, added to a count on the report the recruiter opens. |
| Shared coding pad with session playback | A marker on the replay timeline at that second, sitting beside your keystrokes and your test runs. |
| One-way recorded video interview | No focus data at all. Only your face, moving, on a recording somebody can scrub through. |
| Lockdown browser or a required proctoring client | Frequently blocked outright, or the attempt is ended. That software was installed for exactly this. |
Mechanism three: what a camera can and cannot show
A camera logs nothing by itself. It produces footage that a person or a model interprets later, which makes it the weakest evidence and the one candidates fear most.
In a live interview, the human on the other end sees your eyes leave the lens, your head turn, the reflection in your glasses, sometimes the blue wash of a second display on your face, and hears typing that does not line up with the pauses in your speech. All of that is suggestive and none of it is conclusive, because looking away is also what thinking looks like. In a one-way recorded interview the same footage is replayable and reviewers do scrub it. Some vendors run gaze or face-presence heuristics on top and raise a flag. A flag is a flag, not a finding, and how those thresholds are configured differs per employer in ways candidates are rarely told.
The camera case that overrides every screen-side consideration is the second device: a proctoring flow that asks you to place a phone behind your shoulder aimed at your monitor. At that point there is no software question left to argue about. Something is looking at your screen from outside the machine, and nothing running inside it can change what that lens sees.
Two minutes that let you check all three yourself
Join your own meeting from your phone
Start a meeting on your PC, join it from your phone, mute both to avoid feedback. The phone is now the interviewer's eyes, and it cannot be wrong about what actually left your machine.
Share one window, then alt-tab away
The phone keeps showing the shared window. Look closely at its title bar on the phone screen: it dims. That dimming is the entire honest exposure of a window share.
Switch to Entire Screen and repeat
Same meeting, same client, completely different result. The switcher, the taskbar and whatever you opened all appear on the phone. One tile in the picker decided that.
Watch the events fire in your own console
Open any page, press F12, and paste window.addEventListener('blur', () => console.log('blur')) then document.addEventListener('visibilitychange', () => console.log(document.visibilityState)). Alt-tab, come back, then switch tabs. You will see which action produces which line. That is the exact signal a proctored assessment writes down.
Record yourself reading a second monitor
Point your phone camera at your face and read something off your other screen for fifteen seconds. Play it back. Judge how visible the glance is at your camera angle and lighting, then fix the angle instead of guessing about it.
Where our own tool is the wrong answer
Since this question usually arrives attached to ours, here is the boundary drawn plainly. The OfferPilot AI overlay is excluded from screen capture at the operating system level, so it does not appear in a Zoom, Teams, Meet or OBS share, or in a screenshot, while staying visible on your own monitor. That holds on every plan, including the free one.
Now the honest part. Capture exclusion addresses mechanism one and nothing else. It does not touch mechanism two, because a focus-loss event is fired by your own browser about your own window, and it fires whether or not anything is visible in a capture. It does not touch mechanism three at all: a webcam still sees your face, a second-device camera still sees your monitor, and a lockdown browser or a proctor sitting in the room is outside the picture entirely. It runs on Windows 10 and 11 only, so it does not exist on macOS. On a monitored assessment where the rules say no assistance, it is the wrong tool, and we would rather say so than sell you a subscription you will regret. The free tier on the pricing page takes no card, which is the cheapest way to test a capture claim rather than believe one.
The short version
- The call cannot tell. A share carries one chosen source and has no focus signal in it. Zoom's attention indicator was removed in April 2020 and never came back.
- The assessment page can. Blur and visibility events give it a timestamped count, and that count reaches a recruiter as a number, never as a destination.
- Alt-tab and tab-switch are not the same event. One fires blur, the other also fires a visibility change, and which of them a platform listens for is not published.
- Entire Screen is the real leak. Most accidental reveals are a share choice, not a detection feature.
- A camera proves nothing on its own, but a second device aimed at your monitor makes every screen-side argument irrelevant.
If you want the platform-specific version of any row above, the rest of the guides cover Zoom, Meet, HackerRank, CoderPad and Codility one at a time.