Yes, when the hiring company has switched proctoring on for that test. What it detects is narrower than most people assume: the browser tells the test page it has lost focus, and the page writes down three things, when it happened, how long it lasted, and how many times. It cannot see which tab you opened, which app you moved to, or anything on your screen. That log reaches the recruiter as a flag beside your score, and no platform publishes a limit, because a person reads the shape of the events, not the total.
The event that actually fires
Tab-switch detection is not a HackerRank invention. It is two ordinary web APIs any page can listen to, and they differ in a way that matters to you.
visibilitychangeon the document fires when the tab stops being visible: you switch browser tab, minimise, or the OS puts a full-screen app over it.document.visibilityStateflips tohidden.bluron the window fires when it loses keyboard focus, a much lower bar. Alt-Tab fires it. So does clicking anything on a second monitor, while the test page stays fully visible on the first.- Tests that force full screen also watch
fullscreenchange, which fires the instant you press Esc, whether or not you went anywhere.
None of these events carry a destination. The browser says you are no longer focused. It does not say which tab, which application, or whether you moved at all rather than a dialog opening on top of you. A web page cannot read your other tabs, and browser-based proctoring is a web page.
| Signal | Fires when | Does not fire when |
|---|---|---|
visibilitychange | You switch browser tab, minimise, or the screen locks | Another app takes focus while the tab is still visible on a second screen |
blur | Any other window takes keyboard focus, including a toast or an undocked devtools window | You scroll, type or click inside the test page itself |
fullscreenchange | Esc, F11, or the OS drops you out of full screen | You switch tabs inside a browser that is already full screen |
| Editor paste | Text arrives in the code editor from the clipboard | You retype the same text by hand |
The three fields in one focus-loss record
Timestamp
The offset into the test at which focus was lost. Its job is alignment, not accusation: it lets a reviewer line the event up against the code replay and see which problem was on screen, and what appeared in the editor in the minute after you returned.
Duration
The gap between the blur and the matching focus event. This field carries almost all the signal, and almost nobody thinks about it. Two seconds reads as a notification. Four minutes reads as a decision.
Count
A running tally for the session. The weakest of the three, and the most likely to be the only number a busy reviewer looks at, because it is what the report summary puts at the top.
What is absent matters as much as what is stored. No URL, no page title, no keystrokes from wherever you went, and no screenshot pinned to that moment, because camera snapshots, where enabled, run on their own schedule rather than on a focus change. Field names, and whether events are kept individually or summarised, vary by proctoring tier, so treat these three as the shape of the data, not a guaranteed schema.
Where it surfaces for the recruiter
It lands in the candidate report, in a proctoring block beside the score rather than inside it. That block gathers the focus-loss count, copy-paste activity in the editor, whether full screen was exited, camera snapshots if enabled, and a code-similarity signal comparing your submission against public solutions and other candidates. Many configurations also warn you live, with a banner along the lines of you have navigated away from the test window, which is your clue the listener is running.
The key thing is that this is a flag, not a deduction. Your score comes from test cases passed and is untouched by the counter. The flag changes how much a human trusts that score, which is why two candidates with an identical 340 out of 400 can get different outcomes, and why the reasonable response to a flag is a follow-up interview rather than a silent rejection.
Why nobody publishes a pass or fail number
Two reasons, both defensible. A published threshold becomes a target: if any vendor said five switches fails, every guide online would say stay under five within a week and the signal would be dead. And the count means nothing alone. Consider two cases.
- Candidate A: 14 focus losses, each between one and three seconds, spread evenly across a 90-minute test, none of them followed by a paste. That is a laptop with chat notifications left on.
- Candidate B: 2 focus losses. The first is 11 seconds at minute 3. The second lasts six minutes, starts 40 seconds after the hardest problem loads, and the replay shows a 60-line working solution arriving as a single paste 20 seconds after focus returns.
Candidate B has one seventh of the count and is the one who gets asked about it. Duration, timing against the problem, and what the replay shows next are the whole signal. A good reviewer uses them to decide what to probe next, usually by setting a live variation of the same problem and listening for whether the explanation matches the submitted code. That conversation, not the counter, decides the outcome.
Where OfferPilot AI is the wrong tool
Worth stating plainly on a page published by a company that sells an interview assistant. Our overlay is excluded from screen capture at the operating-system level, so it is absent from a Zoom, Teams or Meet share, from recordings and from screenshots. That property is irrelevant here. Focus-loss detection never looks at pixels, it reads which window the operating system considers focused, so interacting with any overlay, or with the Code Copilot screenshot shortcut, moves focus off the test tab and logs the identical event. Capture exclusion also does nothing against webcam monitoring, a lockdown browser, eye tracking, a second-device camera or a human proctor.
So on a proctored HackerRank assessment whose rules say no outside assistance, this is not the tool for the job, and we would rather write that than sell you something that fails on the exact terms this page is about. Where it earns its place is untimed preparation beforehand, working through problem archetypes until you know them well enough to have no reason to leave the tab.
The innocent things that fire the same event
- A notification toast. Chat and mail toasts do not always steal focus, but the ones that do are indistinguishable from an Alt-Tab in the log.
- Opening developer tools. Undocked, it is a separate window and blurs the page instantly. Docked, focus moves into the panel and the document loses it anyway. Inspecting a test harness logs the same event as leaving.
- A password manager popup. Bitwarden, 1Password and the browser's own autofill open in their own window, and the tab stays blurred until you dismiss it.
- A second monitor. Clicking your notes on screen two fires blur while the test stays fully visible on screen one, the least intuitive case of all.
- The machine itself. Auto-lock, a screensaver, the laptop lid, an update restart prompt, an antivirus popup.
- The platform's own links. Opening the problem's linked documentation, or a support article, in a new tab is a tab switch to the counter.
None of these arrive with a marker separating them from a deliberate exit, which is precisely why duration matters more than count. Before a proctored test, turn on Do Not Disturb and quit the chat apps rather than minimising them, read the whole brief before you type, keep the test on one screen, and disable autofill on that domain. If something does interrupt you, note the time and what it was, then say so in your follow-up email. An unexplained six-minute gap and an explained one read very differently to the same person.
OfferPilot AI is a Windows 10 and 11 desktop app for live interview rounds and coding practice, not for proctored tests. If your next round is a conversation, start with the Interview Copilot and the free tier on the pricing page, no card needed.