A remote coding interview can often tell that your desktop spans more than one screen, but the mechanism matters more than the yes-or-no answer. A page running in a Chromium browser can read a single boolean that says whether your display is extended. A screen share shows only the surface you picked. A desktop lockdown app enumerates every attached display through the operating system. And webcam proctoring never sees your monitors at all — it infers them from where your eyes go.
Those are four different systems with four different levels of visibility, and candidates routinely confuse them. This article separates them, cites the specification and vendor documentation behind each, and explains what the rules actually require as of August 2026.
What a web page can learn on its own
By default, a web page sees very little about your display topology. The window.screen object describes the screen the window currently occupies — its width, height, and color depth — not the rest of your desk.
The exception is Screen.isExtended, part of the W3C Window Management API. It returns true when the device's visual output extends over multiple screens. The important detail is that it is not gated behind a permission prompt. The specification states plainly that "the isExtended boolean is exposed without explicit permission checks, as this minimal single bit of information supports some critical features for which a permission prompt would be obtrusive" (W3C Window Management specification). Any HTTPS page can read it silently.
It is one bit and nothing more. It does not report how many screens you have, their resolutions, their arrangement, or what is displayed on them. For that, a page must call Window.getScreenDetails(), which does require express user consent — MDN documents that the promise rejects with a NotAllowedError when the window-management permission is blocked or denied (MDN: Window Management API). If an assessment platform were reading detailed per-screen data, you would see a permission dialog.
Browser support constrains this further. Screen.isExtended ships in Chromium-based browsers — Chrome and Edge from version 100, Opera from 86 — and is implemented in neither Firefox nor Safari. A candidate taking an assessment in Safari is not exposing the extended-display bit at all, because the property does not exist there.
The practical reading
Assume that a browser-based assessment running in Chrome or Edge can know whether you have more than one display, without asking. Assume it cannot see what is on the second one. Those two facts are usually enough to reason about a given platform's flags.
What a screen share shows
Screen sharing is a separate channel and a more restrictive one. When a platform calls getDisplayMedia(), the browser prompts you to choose a surface — a specific screen, a specific window, or a specific tab. The page cannot widen that choice. MDN notes that the supplied options "can't be used to limit the choices available to the user" and that permission "cannot be persisted for reuse," so the prompt appears every time (MDN: MediaDevices.getDisplayMedia()).
The consequence is specific and often misunderstood: if you have two monitors and share "Entire Screen," you share the one screen you selected. The other display is not in the capture. It is also not enumerable through this API. An interviewer watching your share sees one rectangle, and if you drag a window off the edge of that rectangle it simply disappears from their view — which is itself a visible event to anyone paying attention.
This is the same boundary described in more depth in what interviewers can see during a screen share. Capture scope and system visibility are different questions, and it is the second one that trips people up.
CodeSignal's proctoring documentation is a useful illustration of how these channels stack. The company states that a proctored session confirms "camera, microphone and screenshare were shared for the duration of your evaluation," alongside a government-issued photo ID and a facial photo (CodeSignal: What is proctoring and how does it work?). Three capture channels, each with its own scope, reviewed together.
What a desktop lockdown app sees
This is the category where display topology stops being ambiguous. A native application installed on your machine enumerates attached displays through ordinary operating-system APIs. There is no prompt, no single-bit abstraction, and no browser-support caveat, because you granted the app that access when you installed and launched it.
HackerRank's July 2026 release notes describe both halves of this. The Chakra AI interviewer gained an Integrity Enforcement feature that, per the release notes, detects additional monitors, screen sharing, or full-screen exits and pauses the interview until the condition is restored. The same release introduced a HackerRank Desktop App described as locking the screen, restricting applications, monitoring activity, and flagging webcam anomalies and code-writing pattern irregularities (HackerRank July 2026 release notes). These are vendor-documented capabilities; HackerRank does not publish the thresholds or the detection logic.
Note what "pauses the interview until conditions are restored" means for a candidate. It is not a silent flag reviewed later. It is an immediate, visible interruption that requires you to disconnect the display before you can continue. If you have been treating a second monitor as a gray area, an enforcement gate removes the ambiguity in the least convenient possible moment.
The broader mechanics of installed assessment clients are covered in what changes when the assessment is an app rather than a website. The short version is that installed software operates at a different privilege level than a tab, and every question about visibility has to be re-asked from scratch.
What webcam proctoring infers
Webcam-based proctoring cannot see your monitors. It sees your face, and it reasons backwards.
HackerRank's July 2026 release notes list a Gaze Detection capability, in limited availability as an AI add-on, that identifies repeated eye-aversion from the screen followed by a resumption of typing, and reports it as a medium-severity signal. The same release describes object detection tuned for partially visible phones and tablets, and image analysis for multiple faces or candidate absence.
A second monitor produces exactly the pattern gaze detection is built to notice: sustained head or eye movement toward a fixed off-axis point, followed by typing. It is a weaker and noisier signal than an OS-level display enumeration — looking at notes, a window on the same screen, or nothing in particular can produce similar traces — but it is a signal, and it is graded as one. How eye-movement tracking works in coding assessments goes through the mechanics and the false-positive problem in detail.
The rules are inconsistent, and often unwritten
The detection question is easier to answer than the policy question. Three examples from the same month show how little consensus exists:
| Platform | Stated position on multiple displays |
|---|---|
| ProctorU | Explicit ban. Support documentation states that "multiple monitors/displays are not supported" and that a test-taker with more than one "will need to disconnect all but one." |
| HackerRank Chakra | Automatically enforced. July 2026 release notes describe detection of additional monitors with the interview paused until resolved. |
| CodeSignal General Coding Assessment | Silent. The published GCA rules and setup page does not address monitors, external displays, or screen arrangement at all. |
Sources: ProctorU: Multiple Monitors/Displays, HackerRank July 2026 release notes, CodeSignal: GCA Rules and Setup.
The silence in the third case is the problem. A candidate reading the GCA setup page has no way to know whether their normal two-screen desk is acceptable, and a platform that publishes no rule can still flag behavior after the fact. The invitation email and the pre-assessment instructions screen are the authoritative text for a specific session; the vendor's general help center is not.
What to do before the session
Read the invitation and the on-screen rules first, and treat them as the governing document. If they require a single display, disconnect the others physically or switch to single-display output — the ProctorU article documents Windows Key + P on Windows and unplugging on macOS. If the rules are silent and the session is proctored or recorded, disconnecting is still the low-variance choice, because an unwritten rule cannot be argued about after a flag is raised.
If the rules permit a second display and you keep one, understand that you are visible on two channels at once: the extended-display bit if you are in Chrome or Edge, and your gaze pattern if the webcam is on. Neither is proof of anything. Both are inputs to a review. What happens after a coding assessment flags you covers how those reviews typically proceed.
Where a desktop assistant fits, and where it does not
Control is a desktop AI interview assistant for Windows and macOS that runs as an overlay, transcribes the interviewer in real time, and answers through global hotkeys. Its documented behavior is that it stays out of supported screen captures — the site scopes that to Zoom 6.16 and earlier and to browser-based screen recording — and that it does not steal focus from the interview window.
That scope is worth stating precisely, because it does not extend to the topic of this article. An overlay changes what a capture contains. It does not change your display topology, and it has nothing to say to an installed lockdown client that enumerates screens through the operating system or to a webcam model scoring your gaze. Those are different layers, and a tool that operates at the capture layer does not reach them. If your assessment ships as a downloadable client with monitor enforcement, the honest answer is that a second display is not available to you in that session, whatever else is running.
The short answer
A browser can learn that you have more than one screen, and in Chromium it learns this without asking. A screen share reveals only the surface you selected. An installed assessment client sees your full display configuration and, on HackerRank's Chakra as of July 2026, will stop the interview until you fix it. Webcam proctoring sees none of it directly and guesses from your eyes.
Decide based on the rules for your specific session rather than on the platform's reputation, and when the rules say nothing, assume the stricter interpretation. If you want to understand the adjacent question of what a browser can observe about the rest of your machine, what interview websites can and cannot see about running applications is the companion piece to this one.
Share
Explore with AI
Continue exploring
Related guides
Assessment Guides · 9 min read
Can a Coding Assessment Detect a Virtual Machine?
A browser tab, a screen share, and a desktop lockdown app infer very different things about a VM. What each layer can actually observe, as of September 2026.
Assessment Guides · 4 min read
Does HackerRank Record Audio During a Test?
HackerRank's Proctor Mode requests webcam and screen access, not a microphone. What each HackerRank mode documents about audio, as of September 2026.
Assessment Guides · 5 min read
HackerRank Proctored Test: What to Expect Step by Step
The candidate flow for a proctored HackerRank test in order: consent, monitor check, webcam setup, screen share, full-screen launch, warnings, and the report.