Can Interview Websites Detect Tab Switching?

Yes. An interview website can detect that its page became hidden, its window lost focus, or a required fullscreen session ended. Those signals can show that you left the assessment surface, but an ordinary web page does not learn the destination tab, application, or reason from a standard focus or visibility event alone.

The boundary changes when an assessment also requires screen sharing, a webcam, a browser extension, or a desktop proctoring application. Those permissioned systems can collect evidence beyond the page itself. Read the rules for the specific interview instead of treating “tab detection” as a universal description of everything the platform can see.

What can an interview website detect without extra permissions?

A normal browser page can listen for events delivered by the browser and inspect the current state of its own document. The most relevant signals are visibility, focus, fullscreen state, and input received by the page.

The W3C Page Visibility specification defines only visible and hidden states. It lists several events that can produce a hidden state, including putting the page in a background tab, minimizing the browser, moving the browser off-screen, and locking the operating system. Because the interface reports a state rather than a destination, a visibility log can establish that the page became hidden but not where the user went.

Focus is related but different. The February 2026 W3C UI Events working draft defines blur as an event sent when a target loses focus and focus as an event sent when a target receives it. The same specification separates operating-system focus, browser-interface focus, and focus within the document. A page can therefore observe that it lost focus without receiving a reliable name for the other application or browser surface.

Fullscreen state is another independent signal. The WHATWG Fullscreen API exposes the current fullscreen element and a fullscreenchange event. An assessment can log an exit from fullscreen even when the document never became a background tab. That is why “tab switch,” “window blur,” and “fullscreen exit” should not be treated as interchangeable labels.

Is a tab-switch flag proof of cheating?

No. A tab-switch or focus-loss event is evidence that a browser state changed, not proof of why it changed.

The Page Visibility specification itself names multiple causes for the same hidden state. Focus can also change because of browser chrome, an operating-system prompt, a permission dialog, a notification, an accessibility tool, or an accidental click. Some of those actions may still violate a closed-book assessment rule, but the browser event alone does not supply that policy judgment.

A sound review separates three layers:

1. Observation: The assessment page logged a visibility, focus, fullscreen, clipboard, or input event at a timestamp.
2. Context: Other evidence may show what happened near that time, such as a screen recording, candidate warning, code playback, or support ticket.
3. Rule: The employer's instructions determine whether the action was allowed, prohibited, or covered by an accommodation.

This distinction also protects candidates from overclaiming in the other direction. The absence of a tab-switch event does not prove that no outside resource was used, and a desktop assistant staying outside the browser does not make its use permitted. The AI interview ethics guide explains how preparation, permitted assistance, accommodation, and concealed outside help differ.

What can proctored interview platforms add?

“The website can detect tab switching” describes only one layer of a modern assessment. A configured proctoring product may ask for permission to capture the screen, camera, microphone, monitor configuration, or other system information. A desktop proctoring client can operate outside the ordinary browser-page boundary.

As of August 8, 2026, HackerRank's Proctor Mode documentation says candidates review prohibited actions before a test and may have to grant webcam and screen-sharing permissions, use one monitor, and remain in fullscreen. HackerRank documents automatic logging for tab switches and fullscreen exits, periodic screen captures, webcam analysis, and a session report that brings multiple signals together for review. Those are HackerRank's documented product capabilities, not evidence that every HackerRank test enables the same configuration or that every flag is correct.

CodeSignal likewise says some assessments require proctoring and that candidates are told before the assessment. Its documented proctored flow requests camera, microphone, and screen sharing. The practical boundary is therefore the actual assessment setup and consent flow, not the platform name by itself.

For a deeper breakdown of how browser events, screen capture, webcam evidence, and code behavior differ in one platform, see the HackerRank proctoring analysis. The central lesson applies broadly: passing one narrow visibility test does not reproduce a third party's complete integrity system.

How to test focus and visibility signals safely

Use a page you are authorized to test, synthetic content, and the same browser and operating system you plan to use. Do not experiment inside a real assessment unless the organizer explicitly provides a practice environment for that purpose.

Control's public focus detection lab records browser-observable events in the current session. As of August 8, 2026, it exposes window focus, document visibility, fullscreen state, active element, pointer activity, wheel activity, clipboard events, keyboard events delivered to the page, and page lifecycle events. It is a diagnostic demonstration, not a copy of any interview platform's private detection logic.

Run a controlled sequence:

1. Open the focus detection lab and clear its event stream.
2. Click and type inside the page to establish a normal on-page baseline.
3. Switch to another browser tab, return, and record the visibility and blur events.
4. Switch to another application, return, and compare that event sequence with the browser-tab sequence.
5. Enter and exit fullscreen, then inspect whether fullscreen and focus events occurred separately.
6. Use the lab's own input and clipboard fields to see which events are visible only while the page receives the interaction.
7. Repeat once after disabling notifications and closing unrelated applications. Record the browser, operating system, date, and exact actions.

The useful output is a small event trace tied to named conditions. “Chrome on this computer logged visibilitychange and blur when I switched tabs” is a defensible observation. “No interview platform can detect this workflow” is not.

For a broader preflight that also covers permissions, screenshots, meeting audio, response timing, and recovery, use the AI interview assistant testing checklist. Keep the focus experiment separate from screen-share testing because a page event and a captured pixel are different observables.

How should candidates handle tab-switch rules?

Start with the invitation and onboarding flow. Look for explicit language about open-book resources, external documentation, AI tools, screen sharing, fullscreen, multiple monitors, copy and paste, and breaks. If the instructions do not answer a material question, ask the recruiter before the assessment and keep the reply.

Use a simple decision rule:

• Closed-book or no-external-tools assessment: Keep all outside resources closed and do not switch away unless a technical problem requires it.
• Open-resource assessment: Confirm which resources are allowed and whether they must remain inside a provided environment.
• AI-permitted assessment: Confirm whether permission covers a built-in assistant, an external assistant, or both, and whether disclosure is required.
• Accessibility need: Request the accommodation in advance when possible. A focus or visibility event should not be left to explain assistive technology without context.
• Unexpected interruption: Follow the platform's support procedure and document what happened rather than trying to hide the event.

Do not disable browser APIs, inject scripts, or use extensions to falsify the event stream. That changes the evidence instead of clarifying it and may independently violate the assessment rules.

The screen-share workflow guide can help separate browser focus behavior from what a meeting client or screen capture source displays. Test each surface independently and limit every conclusion to the conditions you actually observed.

Where does Control fit?

Control is a desktop AI interview assistant rather than code running inside the assessment page. Its current product design is intended to let a user trigger configured actions without switching browser tabs or moving focus to a browser extension. That architecture means an ordinary page-level visibility event does not identify Control as a destination application.

This is a narrow technical statement, not an undetectability or permission guarantee. A proctored environment may add screen capture, webcam review, desktop monitoring, code analysis, or explicit rules that prohibit external assistance. Control should only be used when the interview permits it, and the result of the public focus lab should never be represented as proof that a separate platform cannot observe or infer tool use.

A browser signal is not a complete verdict

Interview websites can detect tab switching through visibility, focus, and fullscreen signals, and they can log input events received by their own page. Those APIs reveal a change in the assessment surface; by themselves, they do not name the destination or establish intent.

Proctoring permissions can expand the evidence far beyond browser events. Read the specific rules, identify the enabled monitoring surfaces, and treat every flag as an observation that needs context. To see the ordinary browser boundary firsthand, run the Control focus detection lab with synthetic actions before your interview—not during a restricted assessment.