Can an Interview Tell You're on a Remote Desktop?

Whether a technical interview can tell you are working through a remote desktop session depends almost entirely on what software is running on the machine you are sitting at. A web-based assessment running in an ordinary browser tab has no reliable way to know. A desktop lockdown app installed for the test can ask Windows directly and get a definitive answer in a single system call. Those two situations are often described as the same "proctored assessment," and they are not.

This matters more in 2026 than it did two years ago, because employers started checking. Remote-access tooling is now part of the standard fraud picture in hiring, and some candidates with entirely legitimate setups — corporate VDI, a work laptop reached over RDP, an accessibility configuration — are getting caught in checks aimed at somebody else.

The layer that is actually running determines what is visible

What a browser tab can and cannot observe

No web platform API reports "this page is being rendered inside a remote session." There is no equivalent of the battery or geolocation prompt for terminal-services state. A page that wants to guess is stuck with the same indirect rendering signals used to guess at virtual machines.

The strongest of those is the graphics stack. A default Remote Desktop Services session presents a software display adapter rather than the host GPU, and browsers have historically disabled hardware acceleration under RDP outright — Mozilla tracked un-blocklisting it as bug 879624. The practical result is that a WebGL renderer string collected inside an RDP session frequently names a software rasterizer instead of a real graphics card. Frame timing degrades in the same direction. Neither observation is conclusive; a five-year-old laptop with a disabled GPU driver produces similar output, which is why these signals belong in the same "weak corroboration" bucket as the heuristics covered in our breakdown of how coding assessments try to detect a virtual machine.

Vendor documentation reflects this limit. Codility's assessment integrity features list copy-paste logging, tab switches, unusually fast completion, attempts to copy the task description, and webcam snapshots — no remote-session check. CodeSignal's proctoring overview describes capturing camera, microphone, screen, and a government-issued photo ID, and describes no session-type detection at all. Both platforms separate that browser-side proctoring from a downloadable app that can see more.

HackerRank's browser-based Proctor Mode is the interesting middle case. It does not query the session type, but it takes periodic screenshots and analyzes them for unauthorized tooling, and its documentation explicitly includes "remote desktop applications" in the category of collaboration software it looks for. That is image review, not a system call. It finds a visible AnyDesk or Chrome Remote Desktop window; it does not find a session you have already maximized to fill the screen.

What a desktop app sees in one system call

Once you install the vendor's application, the question becomes trivial. Windows has exposed the answer for two decades: GetSystemMetrics(SM_REMOTESESSION) returns nonzero when the calling process is attached to a Terminal Services client session rather than the console session, and SM_REMOTECONTROL returns nonzero when the current session is being remotely controlled — meaning, in Microsoft's words, "another user can view the contents of that session and potentially interact with it" (Microsoft Learn). Any process running on the machine can read both.

Assessment vendors use that capability rather than inferring around it:

• HackerRank's Desktop App Mode documentation states the app "prevents the test from running on a virtual machine," "prevents candidates from sharing remote access to their systems," and "prevents candidates from sharing their screen or taking screenshots." Requirements and platform coverage for that app are detailed in our guide to the HackerRank desktop app's requirements and blocked behavior.
• Safe Exam Browser exposes remote access as an administrator toggle. The Windows user manual documents a setting, "Allow remote session/screen sharing," described as allowing "Windows remote sessions (e.g. when RDP is needed) and macOS screen sharing to be used." Unless the institution turns it on, those sessions are not permitted. SEB applies the same pattern to virtualization, detecting virtual environments and refusing to run when they are not explicitly allowed.
• Respondus LockDown Browser goes further and treats mere presence as disqualifying. Its support article on Chrome Remote Desktop is blunt: "LockDown Browser will not open if it detects Google Remote Desktop on the computer," and the recommended fix is to uninstall the extension and the application.

The pattern across all three is worth stating plainly: remote-session handling in lockdown software is a hard block, not a flag. You do not get a suspicion score to argue about later. The test refuses to launch, usually minutes before it was due to start.

Why employers started asking

The hiring-side interest in remote access is not primarily about interview assistants. It comes from the remote-worker fraud advisories. The FBI's public service announcement of July 23, 2025, on North Korean IT worker threats to U.S. businesses describes facilitators establishing "remote desktop connections to U.S. company laptops through protocols or remote desktop connection software download and installation," and recommends verification steps that have since propagated into ordinary interview practice — mandating video with unobscured backgrounds, asking candidates to point a camera out a window, and capturing images for comparison across sessions because "sometimes an individual is employed to pass the initial interview, but the on-the-job work is completed by a different individual."

Those recommendations are the origin of several odd requests candidates now report. We covered the camera-pan and hand-wave versions separately in why an interviewer asks you to wave your hand. The relevant point here is that the remote-access question arrives in an interview loaded with fraud context, so a candidate who is plainly working through a remote session invites a conversation they did not expect to have.

The false positives nobody plans for

Several completely ordinary setups trip these checks:

• Corporate VDI and managed desktops. If your employer issues a virtual desktop, every session you have is a terminal-services client session. Taking an assessment on the machine you work on daily is the failure case.
• Working from a laptop into a desktop. Reaching a home workstation over RDP or Parsec because that is where your toolchain lives is indistinguishable, at the API level, from the scenario the check exists to catch.
• Software left installed. Respondus blocks on the presence of Chrome Remote Desktop, not its use. An extension you installed two years ago to help a relative with their printer is enough.
• macOS Screen Sharing enabled in system settings. It is a sharing service that stays on once switched on, and SEB's setting treats it the same way it treats RDP.
• Accessibility configurations. Remote-control software is a legitimate assistive tool, and none of this documentation describes an accommodation path.

If any of those apply to you, the time to raise it is when the invitation arrives, not when the launcher fails. Ask the recruiter whether the assessment uses a downloadable app or exam browser, and whether an alternative machine or a supervised session is available. That request reads as diligence. The same request made from a stalled launcher fifteen minutes into your window reads as an excuse.

Before you start

Run the platform's system check on the exact machine and session you plan to use, not a convenient one. Most vendors ship one, and it is the only check that reflects your actual configuration. Then, if the assessment uses a desktop app or exam browser: sit at the physical machine, disconnect any active remote session rather than just minimizing it, and uninstall remote-control clients if the vendor documents them as blocking. Browser-only assessments are worth understanding on their own terms too — our guide to what interview websites can see about other running apps covers where that boundary actually sits.

Where a desktop assistant fits, and where it does not

Control is a desktop AI interview assistant for Windows and macOS. It runs on the machine in front of you and, per its product documentation, does not appear in supported screen captures and does not take focus from the window being shared.

That architecture has a specific consequence for this topic, and it cuts against the product: if the assessment itself is running inside a remote session on another machine, an assistant installed locally is not in the environment where the work is happening, and anything you do inside that remote session is governed by whatever the remote host is running. A lockdown app deployed on the far end sees the far end. There is no version of a local overlay that changes that. If your interview loop is going to run inside employer-controlled remote infrastructure, that is a case where a desktop assistant is the wrong shape for the problem.

The short version

A browser tab cannot reliably tell you are on a remote desktop; it can only notice that your graphics stack looks like software rendering, which is also true of plenty of ordinary laptops. A vendor desktop app or exam browser can tell immediately, because Windows offers the answer as a system metric, and the documented behavior at HackerRank, Safe Exam Browser, and Respondus is to block rather than flag. The practical risk for an honest candidate is not being accused of anything — it is being unable to start the test at all, on a setup they had no reason to think was a problem.

If your loop is a browser-based assessment or a live screen share on your own machine, test the behavior on that hardware before an interview depends on it. Control's focus test is the fastest way to see how an overlay behaves against a shared window.