Can Interview Websites See Other Apps Running?

An ordinary interview webpage does not receive a standard list of every application or operating-system process running on your computer. It can still detect that its page became hidden or lost focus, and an authorized screen capture can show other apps that appear inside the selected capture surface.

The boundary changes when the assessment requires a browser extension, a managed environment, or a native desktop application. Native assessment software can have operating-system permissions that a normal webpage does not. The useful question is therefore not only “Is this an interview website?” but “What software is running, what permissions did I grant, and what evidence does the platform say it collects?”

Can a normal interview page enumerate running apps?

There is no standard Web API that gives an arbitrary HTTPS page a task-manager-style inventory of operating-system processes. In Chromium, webpage JavaScript normally runs in a renderer process. Chromium's Windows sandbox documentation says renderers have only very limited access to the operating system, file system, and other system objects.

That sandbox boundary is part of the browser's security model. It is not a claim that a page learns nothing about the device, and it is not a defense against a browser vulnerability or malware. A page can receive browser-provided information and events, use capabilities the user explicitly authorizes, and infer facts from the evidence it collects. It simply does not inherit a general process-list API because it is open in a tab.

The same distinction applies to browser extensions. Chrome exposes an installed-extension inventory to extensions that declare the management permission, not to arbitrary pages. The guide to browser-extension detection in interview websites explains how a page may still probe a known extension or observe its effects without receiving a universal inventory.

What can a browser page observe instead?

An ordinary assessment page can log its own state and interactions delivered to it. Those signals may show that the assessment surface changed, but they do not name the other application by themselves.

The W3C Page Visibility specification defines only visible and hidden states. It lists several causes for a hidden page, including a background tab, minimized browser, off-screen browser, or operating-system lock screen. The event reports a state change, not the destination. That is why the analysis of tab-switch detection during interviews treats focus loss as evidence with a limited scope rather than proof of which tool was used.

Some device facts can also be inferred indirectly. Timing changes, screen dimensions, network properties, installed fonts, or failed requests may contribute to a fingerprint. An inference about an environment is different from a verified process name, executable path, or application inventory. Platform documentation should say which one it means.

When can screen capture reveal another application?

Screen sharing can expose other applications without enumerating processes. The page receives pixels from a display surface the user selected, and visible application windows, menus, notifications, or taskbars may appear in those pixels.

The current W3C Screen Capture specification requires the browser to let the user choose a capture surface each time getDisplayMedia() is requested. The site cannot use capture constraints to remove the user's choice before selection, and the browser cannot persist the permission as permanently granted. After the user chooses, the site can receive the resulting live media stream.

The scope depends on the chosen source:

• A browser-tab share generally exposes the selected tab, not a desktop process list.
• An application-window share exposes the chosen logical window and may behave differently from the pixels visible on top of it.
• An entire-display share can show any application that becomes visible on that display.
• A proctoring service may record or analyze the stream rather than merely show it to a live interviewer.

Seeing an app in a recording is pixel evidence. It does not prove the platform queried the operating system for that app. The guide to what interviewers can see during screen sharing maps tab, window, and display capture in more detail.

What changes with extensions, managed browsers, and desktop apps?

“Interview website” can describe several different technical layers running together.

The permission prompt and onboarding flow matter more than the vendor logo. A browser-only test, a browser test with full-display recording, and a downloaded secure-testing app may all use the same company name while exposing very different evidence.

Native access is also not unlimited by definition. The operating system, granted permissions, application implementation, account privileges, and platform configuration still set boundaries. Treat a vendor's documented behavior as a claim about that specific mode and date, not as a capability shared by every proctoring product.

What do current assessment platforms document?

As of August 14, 2026, HackerRank draws an explicit line between browser and native controls. Its Desktop App Mode documentation, updated July 22, 2026, says the downloaded Windows and macOS application provides stricter controls that are not possible in web browsers. HackerRank says the mode requires system permissions, checks that unauthorized applications are closed before the test, and detects and closes other programs opened during the session. It also says the mode blocks remote access, multiple monitors, screenshots, virtual machines, and navigation away from the test.

Those are vendor-reported capabilities of Desktop App Mode. They do not mean an ordinary HackerRank page has the same operating-system view, and they do not mean every HackerRank assessment enables the desktop mode. The current guide to what HackerRank proctoring detects and records separates Secure Mode, Proctor Mode, and Desktop App Mode.

CodeSignal documents a different browser-based proctoring flow. Its proctoring guide, updated July 26, 2026, says candidates are prompted to share their camera, microphone, and screen for the assessment and to close unrelated tabs, windows, and applications. CodeSignal says that recording and the assessment rules are reviewed after the evaluation. The documentation supports a screen-recording claim; it does not state that this browser flow returns a live operating-system process inventory.

Rules can also vary by assessment. CodeSignal's June 2026 Data Analytics Assessment rules explicitly permit external applications such as spreadsheet, R, and Python tools for that test. An “other app” is therefore not automatically prohibited even when proctoring is active. The disclosed rules supply the policy context that the technical signal lacks.

Is an application flag proof of a violation?

Not by itself. An app may be permitted, required, or covered by an accommodation. Examples include an approved IDE, spreadsheet, password manager, accessibility tool, communication aid, corporate security software, or operating-system service. A process name can also be ambiguous, and image analysis can misclassify visible pixels.

A defensible review connects four pieces:

1. Collection method: page event, screen recording, image analysis, browser policy, or native application monitoring.
2. Evidence: timestamp, visible pixels, process or application identifier, warning, or enforced closure.
3. Rule: the instructions and consent shown for that exact assessment.
4. Context: permitted tools, accessibility needs, technical support records, and the candidate's explanation.

Candidates should not rely on that nuance as permission to ignore a rule. Employers should not turn a low-context signal into a conclusion without checking the disclosed policy and evidence.

Where does Control fit?

Control is a desktop application, not webpage JavaScript or a browser extension. That means an ordinary page cannot identify Control through a standard process-list Web API or Chrome extension inventory. It does not mean Control is universally invisible.

An entire-display share can expose visible pixels. A proctoring screenshot can capture or classify what appears in its surface. A native assessment application may monitor or block other desktop applications. Control's content-protection and global-control behavior apply to particular operating systems and capture paths; they do not override assessment rules or every monitoring layer.

Use Control only when external assistance is permitted. If the invitation requires a secure desktop app or prohibits other software, follow that requirement rather than treating a browser boundary as a loophole.

Identify the assessment layer before you begin

A normal interview page can observe its own visibility, focus, fullscreen, and input events, but it does not receive a standard operating-system process list. Screen capture adds pixels from the chosen surface. Extensions, managed environments, and native assessment applications can add broader permissions and controls.

Before a real session, read the invitation, note every required download and permission, close unrelated software, and ask about any tool or accommodation the rules do not cover. Then use Control's browser focus and visibility test to see what an ordinary page can record, keeping the result scoped to browser events rather than treating it as a simulation of a proprietary proctoring system.