Can Interviewers See Your Whole Screen During a Coding Interview? (2026)

The Short Answer

During a coding interview in 2026, the interviewer can see only the exact surface you chose to share — not your entire computer. Screen sharing is a consent-based browser and operating system capability built on the Screen Capture API, and at the moment you start sharing you pick a scope: your entire screen, a single application window, or a single browser tab. The interviewer receives a video stream of only that surface. They cannot expand it, cannot enumerate your other windows, cannot reach a second monitor you did not select, and cannot see anything behind the shared surface. The one real exposure is entire-screen share, which streams everything on that one display — including notifications, the dock or taskbar, and any window you bring to the foreground.

How Screen Sharing Actually Works Technically

Screen sharing in every modern interview tool runs on the same browser primitive: the Screen Capture API, invoked through navigator.mediaDevices.getDisplayMedia(). Understanding that one call explains nearly everything about what an interviewer can and cannot see.

When an interview platform — Zoom, Google Meet, Microsoft Teams, CoderPad, HackerRank CodePair — wants your screen, it does not reach into your operating system and take it. It calls getDisplayMedia(), which triggers a native picker rendered by the browser or the OS itself, not by the platform. You select what to share. The browser then hands the platform a single MediaStream containing one video track of the surface you picked. The platform never chose the surface; you did. This consent boundary is the structural reason the interviewer's visibility is so much narrower than candidates assume.

The picker presents up to three categories of surface, which map directly to the displaySurface values defined in the API: monitor (an entire screen), window (one application window), and browser (one browser tab). The capturing site can hint at which options to offer — including a monitorTypeSurfaces option that lets a site exclude the entire-screen choice to reduce accidental leakage — but it cannot override your final selection. Whatever you click is the only surface that ever enters the stream.

The pseudocode below shows the shape of the call an interview platform makes and the surface choice the API exposes. It is simplified, but it is representative of what runs underneath Zoom's web client, Google Meet, and every browser-based coding pad.

// What the interview platform requests
const stream = await navigator.mediaDevices.getDisplayMedia({
  video: {
    displaySurface: "browser",   // hint: prefer a tab; "window" or "monitor" also valid
  },
  audio: false,
  // monitorTypeSurfaces: "exclude"  // a site CAN hint to hide the entire-screen option
});

// The browser shows the native picker. THE USER chooses the scope.
// The platform receives exactly one track for exactly one surface:
const [track] = stream.getVideoTracks();
const settings = track.getSettings();

settings.displaySurface;  // "monitor" | "window" | "browser" — the user's choice
// There is no API to read other windows, other displays,
// or anything outside this single captured surface.

The final comment is the load-bearing fact. The MediaStream is one track of one surface. There is no method on it that returns your other windows, lists your monitors, or widens the capture. The interviewer's software is downstream of this stream and inherits its limits exactly.

It is worth being precise about where the consent boundary sits, because it is the foundation of every answer in this article. The capturing site does not run getDisplayMedia() with the power to choose a surface for you. It runs it with a request — a set of hints in the DisplayMediaStreamConstraints object — and the browser, acting as a trusted intermediary, presents the picker and waits for your click. The browser process, not the page's JavaScript, owns the picker. A web page cannot script a selection, pre-check a surface, or suppress the picker to silently grab a screen. If you dismiss the picker, the promise rejects with a NotAllowedError and the platform gets nothing. The surface choice is removed from the site's control and handed to the user every single time, and an interview platform is just another site subject to that rule.

Once the stream exists, the platform also cannot quietly upgrade it. There is no method that converts a window track into a monitor track or adds a second display to an existing capture. To change scope, the platform must call getDisplayMedia() again — another picker, another explicit selection by you. That is why interviewers ask out loud, "could you share your whole screen instead?" rather than expanding the view themselves. They have no API to do it; they need you to re-grant.

What Each Share Mode Exposes

The share scope you pick determines everything that follows, so the three modes are worth treating as three completely different privacy postures. The summary line: entire screen shows that whole display, a window shows only that app, a tab shows only that tab.

Entire-screen share is the only mode that leaks broadly. Everything that draws pixels on that one display is in the stream — including the things you do not think of as windows, like notification toasts, the macOS dock, the Windows taskbar, and the menu bar clock. The moment you alt-tab, drag a window, or open Spotlight, that content enters the stream, because the surface is the whole display, not any single app.

Window and tab share are narrow by construction. When you share an application window, the browser composites only that window's pixels into the stream. Another app can sit directly on top of the shared window on your physical screen and the viewer still sees only the shared window — the compositor isolates it. A tab share is narrower still: just that one tab's document, with the rest of the browser chrome and every other tab outside the capture surface.

Does sharing a window expose an app stacked in front of it? No — actually the stream is composited from the shared window's own surface, so an overlapping app on your real screen is never sent. The viewer sees the shared window as if nothing were in front of it.

The compositing detail is what makes window and tab share genuinely safe rather than merely conventionally safe. Modern operating systems do not capture a window by photographing the screen region it occupies. They capture the window's own backing surface — the off-screen buffer the OS already maintains to draw it. That buffer exists independently of what else is on screen, so when another application is physically drawn on top of the shared window, the capture still reads the shared window's buffer, not the screen region. The overlapping app is composited onto your physical screen but never onto the captured stream.

Entire-screen share works the opposite way. There the capture source is the display's framebuffer — the final composited image of everything drawn to that monitor: every visible window, the wallpaper, the cursor, the menu bar or taskbar, and any notification. There is no per-app isolation because the surface is the whole display. This is the precise technical reason entire-screen share leaks and window share does not: one captures a composited display, the other an isolated window buffer.

Tab share is tighter still. A browser-tab capture reads the rendered document of a single tab from inside the browser's compositor, excluding other applications, other tabs, and the browser's own chrome — the address bar, the tab strip, and any extension popups. That is why a tab share of a coding pad shows a clean editor with no browser frame around it.

What the Interviewer Structurally Cannot See

The interviewer's tooling sits downstream of the MediaStream, so it inherits every limit the stream has. The summary line: there is no consent-free path from a shared surface to the rest of your machine.

The interviewer cannot expand or switch the surface. The scope is fixed when you grant permission. The video track has no "show me more" control; widening the capture requires you to stop sharing and start a new share with a new selection. Until you do that, the surface is frozen at your original choice.

The interviewer cannot enumerate your windows or displays. Nothing in the Screen Capture API exposes a list of your open applications, your tab inventory, or your monitor count to the capturing site. The site receives one opaque video surface and the displaySurface label for it — monitor, window, or browser. It does not learn what else exists.

The interviewer cannot see a second monitor you did not select. Each physical display is its own capture surface. Sharing the primary display captures only the primary display; the secondary monitor's pixels are simply not in the stream. This is the single most misunderstood point, so it gets its own section below.

The interviewer cannot read what is behind the shared surface. On a window share, the area your real cursor occupies on the rest of the desktop is irrelevant — only the window's pixels are composited. On a tab share, the browser chrome, the URL bar, and every neighboring tab are outside the surface and never transmitted.

The interviewer also cannot extract anything but pixels. A screen-share stream is a video track: a sequence of frames. It carries no DOM, no text layer, no clipboard, no file handles, no process list. An interviewer who sees code in your editor through the share is seeing an image of that code, not the underlying text — which is why platforms that want the actual code, or want to detect pasting, do it through editor-level instrumentation rather than through the video. The screen share and the editor telemetry are two completely separate channels. This separation is the reason paste-event tracking exists as its own system: the video stream simply cannot report a paste, so the platform listens for it in the editor's JavaScript instead.

One nuance is worth stating plainly, because it seeds most overblown fears. The stream shows whatever is rendered on the shared surface. If you share your entire screen and a private message or a half-typed answer is visible on that display, it is in the stream — not because the share is reading your data, but because that content is drawn on the surface you chose to broadcast. The exposure is always about what is visible on the shared surface, never about the share reaching into your system. Keep the surface narrow and the exposure shrinks to almost nothing.

The Second-Monitor Question

This is the question candidates ask most, so here is the unambiguous answer: a second physical monitor is a separate display and is not captured unless you explicitly select it in the share picker. The summary line: one share, one surface — your other monitor is a different surface entirely.

When you have two monitors and you start a share, the native picker lists each display as a distinct monitor option ("Screen 1," "Screen 2," or named by resolution). You click exactly one. The browser captures that one display. The second display is composited by your OS into its own framebuffer, which the stream never touches. The interviewer receives the screen you picked and has no mechanism to reach the other one — they cannot see it, scroll to it, or even confirm it exists.

The corollary matters: if you drag the shared window onto the other monitor mid-interview while sharing the first display, the window leaves the captured surface and the stream shows empty desktop where it used to be. The capture follows the display, not the window. This is the opposite failure mode of an entire-screen leak, and it surprises candidates who assume the share "follows" their work.

Can they see my second monitor if a notification from an app on it pops up? No — actually the notification renders on whichever display the OS routes it to, and if that is the unshared monitor, it is outside the capture surface entirely. Only notifications drawn on the shared display enter the stream.

There is one subtle exception: some video tools, on a multi-monitor setup, offer an "all screens" or combined-displays option that captures every monitor into one wide stream. This is still consent-based — you have to pick it — but it is the one selection that puts a second monitor into the stream. If a picker entry shows a stitched-together thumbnail of two displays side by side, that is the all-screens option. Picking a single named display ("Screen 1") never does. The rule holds: a second monitor enters the stream only if you select a surface that includes it.

The same mechanics hold across employers. Whether you are interviewing in Airbnb's process, Cloudflare's, Notion's, Linear's, Shopify's, Palantir's, or Jane Street's, the screen-share layer is the same browser primitive. The pad and the company change; the second-monitor rule does not.

How the Major Platforms Default Their Share Options

Every platform wraps the same API, but they differ in which scopes they surface and which they default to. The summary line: the conferencing tools expose all three scopes; the dedicated coding pads usually share a tab or window because that is where the editor lives.

Google Meet has the cleanest tab-sharing workflow, which is why the privacy guidance for a Meet interview is almost always "share the tab, not the screen." Zoom and Teams both default many users toward an entire-desktop share, which is the widest and leakiest scope; the safer move on either is to pick the single window or the single tab manually. CoderPad and HackerRank CodePair are themselves browser pads, so sharing the pad's own tab keeps everything else off the stream. The deeper detection question — what these platforms log beyond the video stream — is covered in the CoderPad cheating detection breakdown, the HackerRank AI detection guide, and the CodeSignal detection analysis.

The platform's implementation choices change the texture but never the underlying limit. A native desktop client and a web client both rely on the OS-level capture permission and both present a picker before anything is shared. Native apps add conveniences — Zoom's "share a portion of screen" captures only a draggable rectangle, narrower than an entire-screen share — but every one is still a user-selected surface. No client, native or web, captures more than the user picked. When you read about whether Microsoft Teams detects screen recording or whether Webex detects AI in interviews, the same separation applies: the detection features are a distinct layer from the screen-share scope, and neither lets the interviewer see past the surface you chose.

A second-order point that trips candidates: the share indicator is not the share scope. Zoom, Meet, and Teams all render a border, toolbar, or system banner while you share, and candidates sometimes read that chrome as proof the interviewer sees their whole desktop. It is not — the indicator only reminds you that sharing is active, regardless of scope. A tab share and an entire-screen share can produce nearly identical "you are sharing" UI on your end while exposing wildly different amounts. Trust the picker selection, not the indicator.

What Candidates Get Wrong

The misconceptions cluster around one core error — assuming the interviewer's view is wider than the stream actually permits. The summary line: nearly every false assumption treats screen sharing as surveillance of the whole machine rather than a single chosen surface.

• Assuming "share screen" means "share everything." The most common mistake. "Share screen" is a menu label, not a scope. The scope is whatever surface you pick in the picker — and a window or tab share is dramatically narrower than the phrase suggests.
• Believing the interviewer can switch to your other monitor or other windows. They cannot. There is no control on their end that changes your share scope. The surface is fixed at your selection until you start a new share.
• Thinking a window share leaks overlapping apps. It does not. The compositor sends only the shared window's pixels. An app sitting on top of it on your physical desktop is never in the stream.
• Forgetting that entire-screen share leaks notifications and the dock. This is the real exposure and it is easy to miss. On a monitor share, every banner, badge, and taskbar item is in the stream. Enable Do Not Disturb before an entire-screen share.
• Dragging the shared window to the unshared monitor. When you share one display and move your work to the other, the stream goes blank where the window was. The capture follows the display, not your window.
• Assuming the screen share can read your clipboard or files. It cannot. The stream is pixels only. It carries no clipboard data and no file contents — though paste events are tracked separately, as detailed in can interviewers see paste events.

Live Interview vs Proctored Async: A Different Capture Model

The consent model above describes a live, human-on-the-other-end interview. Proctored asynchronous tests can operate under a stricter regime, so the two formats deserve separate framing. The summary line: in a live share you choose the scope; in some proctored async tests the scope is mandated.

In a live interview, you control the scope every time. The interviewer asks you to share, the native picker appears, and you select a tab, a window, or a screen. The interviewer's visibility is exactly the surface you chose and nothing more — the entire analysis above applies cleanly. The interviewer can ask you to share a wider surface, but they cannot force it; the picker is yours.

Proctored asynchronous assessments are where the model can change. Some proctoring systems require an entire-screen capture as a condition of starting the test, and may pair it with a webcam feed, periodic screenshots, browser-focus tracking, and a lockdown layer. In that setting the capture surface is not a privacy choice you make — it is a requirement enforced before the test will run. If you select a narrow scope, the assessment may refuse to begin. The mechanics of those environments, including what the webcam layer captures and how lockdown browsers behave, are covered in how to pass a proctored coding test in 2026 and the webcam proctoring software guide.

The distinction shapes the right mental model. A live screen share is a single, consent-bound video track. A proctored async test is a multi-signal capture environment where the screen stream is one of several feeds. Conflating the two leads candidates to either over-worry about live shares or under-prepare for proctored ones. For the live case specifically, the practical setup is covered in remote technical interview tips for Zoom and Google Meet.

Even within the proctored-async category, the entire-screen requirement does not grant the proctoring tool more than the OS exposes. A required monitor capture still streams one display unless the candidate selected additional ones, and a webcam feed is a separate device stream. What changes in the proctored setting is the policy enforced on top of the API: the test may inspect the granted track's displaySurface value and refuse to start if it is not monitor, may count displays through OS-level signals, and may flag a second monitor as a violation rather than capturing it. The detection-versus-capture difference matters: a live interviewer can neither detect nor capture your second monitor; a strict proctor may detect it and end your session, but still cannot pull its contents into the stream without you selecting it. The broader detection stack — focus tracking, AI classifiers, and webcam analysis layered on the video — runs through is ChatGPT in a Zoom interview detectable, Google Meet versus Zoom AI detection, and the HireVue AI detection guide.

The Closing Frame

The correct mental model is narrower than the fear most candidates carry into the call. Screen sharing is not surveillance of your machine; it is the broadcast of a single surface you consciously selected, through a browser API designed to keep that choice in your hands. The interviewer receives one video track of one surface. They cannot widen it, switch it, enumerate your windows or displays, or read anything but the pixels you are showing. Whether that exposure is large or small is a function of one decision: the scope you pick in the picker.

That decision is the whole game. Pick a browser tab and you expose one document. Pick an application window and you expose one app, isolated by the compositor from everything stacked around it. Pick your entire screen and you expose that display in full — notifications, dock, taskbar, foregrounded windows, and all. The second monitor stays out of every one of these unless you deliberately select an all-screens or second-display option. The defensive posture is therefore simple and durable: share the narrowest surface that shows your work, enable Do Not Disturb before any entire-screen share, and keep anything sensitive off the broadcast surface. Everything beyond that surface — your other monitor, your other windows, your clipboard, your files, your background applications — is structurally outside the stream, and no interviewer on a live call has a mechanism to reach it.

The operative fact governs assistive tools too: the stream contains only what is rendered on the shared surface. A tool that renders outside standard screen-capture surfaces is, by the same compositing logic that isolates a window share, absent from the stream — the category TechScreen occupies.

Frequently Asked Questions

Can interviewers see my whole screen during a coding interview? Only if you chose to share your entire screen. Sharing is consent-based: at share time you pick a scope — entire screen, one window, or one tab — and the interviewer receives only that surface. If you shared a single window or tab, the rest of your screen, your other windows, and your other tabs are not in the stream at all.

Can the interviewer see my second monitor? No, unless you explicitly selected that monitor in the share picker. Each physical display is a separate capture surface. Sharing your primary display captures only the primary display; the second monitor's pixels never enter the stream, and the interviewer cannot switch to it or confirm it exists.

Can they see notifications and pop-ups while I share? On an entire-screen share, yes — anything drawn on that display, including notification banners, the dock, and the taskbar, is captured. On a single-window or single-tab share, no: notifications render outside the shared surface. Enabling Do Not Disturb before an entire-screen share removes the exposure.

Can the interviewer expand the share to see more of my screen? No. The scope is fixed when you grant permission. The interviewer receives a video track of a fixed surface with no control over what that surface is. Widening it requires you to stop the current share and start a new one with a new selection.

Is sharing a single tab safer than sharing my whole screen? Yes, substantially. A tab share streams only that one tab — other tabs, other windows, notifications, and the rest of the desktop are all outside the capture surface. The standard privacy ordering is tab first, window second, entire screen last. This is the practical core of remote interview setup for Zoom and Google Meet.

Does a screen share reveal an invisible AI assistant running on my machine? Only if that assistant renders on the surface you are sharing. A tool designed to render outside standard screen-capture surfaces — like TechScreen — stays out of the getDisplayMedia() stream even during an entire-screen share, because the capture composites only the surfaces the OS exposes to it. How that category of tool works is detailed in how AI interview assistants work and the best invisible AI tools comparison.