What Can Interviewers See When You Share Your Screen?

Interviewers normally see only the capture source you deliberately share: a browser tab, an application window, or an entire display. The wider the source, the more you expose. A tab share is usually the narrowest boundary; a window share includes that application's window; an entire-display share can show other windows, menus, notifications, and anything else that appears on the selected monitor.

That answer changes when the interview also uses a proctoring system. Screen sharing in Zoom, Google Meet, or Microsoft Teams is one stream. A proctored assessment may separately request fullscreen, webcam, microphone, periodic screenshots, or other monitoring permissions. To know what an interviewer can actually review, identify every active capture and permission—not just the button labeled “Share.”

What does each screen-sharing option expose?

The web platform models a capture source as a display surface. The W3C Screen Capture specification defines the main surface types as a browser, window, or monitor and requires the user to choose what to share. Meeting products use different labels, but their practical boundaries follow that same pattern.

These are useful defaults, not guarantees across every operating system and client version. The W3C specification distinguishes a surface's logical contents from the pixels visible at a particular moment. It also leaves some treatment of obscured or off-screen areas to the user agent. Do not infer an exact pixel boundary from the share label alone; verify it in the actual app you will use.

Browser tab sharing

A tab share is usually the tightest meeting boundary. The audience sees the selected tab rather than your whole desktop. Switching to another tab on your computer does not automatically change the shared source, although the meeting app may show an indicator that you are viewing a different tab.

Tab sharing can include audio. Google Meet's current presentation guide says a Chrome tab shares that tab's audio by default. That matters if the tab contains a video, notification sound, or other media you did not intend to broadcast.

A tab boundary is also not the same as an assessment boundary. The page you are using may independently observe whether it became hidden or lost focus. The guide to tab-switch detection separates browser visibility events from captured pixels.

Application window sharing

A window share generally follows one chosen application window. It is narrower than sharing the entire display, but broader than sharing one browser tab when that browser window contains several tabs, dialogs, downloads, or account surfaces.

Do not assume another window placed over the shared app will reliably hide the underlying content from viewers. Capture systems can work from a logical window surface rather than simply recording the same stack of pixels you see on your monitor. The W3C specification explicitly accounts for logical display surfaces that may be obscured, off-screen, or minimized. The result can vary by application, browser, and operating system.

Entire-screen or display sharing

An entire-display share is the broadest common option. Zoom's screen-sharing guidance states that participants can see everything you view on the shared desktop or mobile device, including applications and files you open. If you have multiple monitors, the selected display is the important boundary—not the computer as a whole—but moving a window onto that display can bring it into the outgoing stream.

Google Meet similarly offers a tab, window, or entire screen. Microsoft Teams' presentation guide distinguishes sharing a screen from sharing a window and includes controls for computer sound. Labels and privacy affordances differ, so read the preview and source name before confirming.

Can interviewers see notifications, other apps, or a second monitor?

It depends on the source.

• Notifications: Expect them to be visible when they appear on an entirely shared display. A window or tab share is narrower, but notification behavior still varies by operating system and meeting client. Use Do Not Disturb rather than relying on a platform to suppress them.
• Other applications: They are ordinarily outside a tab or single-window source. They can become visible on an entire-display share as soon as they appear on that display.
• A second monitor: Sharing one display does not ordinarily share every display. Still, a proctored assessment may require one monitor or collect monitor information separately, and the organizer can require a particular sharing setup.
• Meeting controls and chat: Some clients intentionally keep their own controls or chat out of the outgoing share in certain modes. Treat that as a product-specific affordance, not a rule that applies to every window.
• Audio: Screen visibility and system audio are separate choices in many clients. Check whether tab audio or computer sound is enabled before you begin.

The safest mental model is: the capture source sets the default visual boundary, while each additional permission creates another possible evidence channel.

Is ordinary screen sharing the same as proctoring?

No. A meeting share lets other participants view the source you selected. Proctoring can combine that source with events and recordings from the assessment environment.

As of August 8, 2026, HackerRank's Proctor Mode documentation says a configured test can require screen sharing, webcam access, fullscreen, and one monitor. It also documents tab-switch and fullscreen-exit logging, periodic screenshots, and a report for reviewers. Separately, HackerRank's Observation Mode documentation describes real-time viewing of a candidate's screen activity during an interview.

Those are disclosed product capabilities, not proof that every HackerRank interview uses every control. The specific invitation, consent screen, and employer policy determine the actual setup. The HackerRank proctoring analysis explains why one passed visibility test cannot stand in for a layered monitoring system.

This distinction matters outside HackerRank too. A video meeting, browser assessment, extension, and desktop proctoring client can run at the same time. Count them as separate surfaces and read each permission prompt before continuing.

How can you test what the interviewer will see?

Run a synthetic rehearsal before the interview. Use fake documents and test accounts so an unexpected capture never exposes real personal or employer information.

1. Match the real setup. Use the same computer, monitor arrangement, operating system, browser, and meeting client you expect on interview day.
2. Join from a second device or test participant. The receiving view is more useful than the presenter's preview because it shows the outgoing result after the client processes it.
3. Test one source at a time. Share a tab, a window, and a full display. Record what happens when you switch tabs, overlap windows, minimize the source, open a dialog, and move a window between monitors.
4. Test audio and notifications separately. Play harmless test audio, enable and disable system-sound sharing, and trigger a synthetic notification with no private text.
5. Record the exact conditions. Note the app and OS versions, source type, date, and result. A conclusion is only reliable for the combination you tested.
6. Rehearse recovery. Confirm you can stop sharing, choose the right source again, and explain a technical interruption without scrambling.

The broader AI interview assistant preflight checklist covers capture, permissions, audio, response timing, and recovery. Keep this rehearsal separate from a real or restricted assessment unless the organizer explicitly provides a practice environment.

Where does Control fit in a screen-share setup?

Control is a desktop AI interview assistant designed for supported screen-share workflows. Its desktop app enables Electron's operating-system content-protection setting for the Control window. That is a real implementation detail, but it is not a universal invisibility guarantee.

Electron's current setContentProtection documentation explains that Windows uses WDA_EXCLUDEFROMCAPTURE on supported versions. The same documentation warns that newer macOS applications using ScreenCaptureKit can capture a protected window despite the setting. Meeting clients, capture paths, operating systems, and versions change; proctoring can also collect signals unrelated to pixels.

Use Control only when outside assistance is permitted. Before relying on any capture behavior, test the exact setup with synthetic content and a receiving participant. For a workflow-level comparison of meeting apps, coding editors, capture, and response surfaces, see the screen-share interview assistant guide.

Choose the narrowest permitted share and verify it

Interviewers see the source you share plus anything collected through other disclosed permissions. A browser tab is usually narrower than an application window, and a window is narrower than an entire display. Proctoring can add independent screenshots, events, camera evidence, or live observation.

Choose the narrowest source that satisfies the interviewer's request, close private material, disable notifications, and verify the receiving view before the call. If the assessment requires a broader source or prohibits outside tools, follow that rule. The share picker is a boundary control—not a substitute for consent, policy, or a real preflight test.