Do Coding Assessments Record Audio and Detect Talking?

Some remote coding assessments record your microphone and some do not, and the difference is knowable before you click start. As of August 2026, CodeSignal's proctoring documentation states that it records candidate audio; HackerRank's Proctor Mode documentation lists webcam and screen-share permissions and does not list microphone access at all. The signal HackerRank calls "conversation detection" is not audio monitoring — it is a pattern in your code editor.

That last point matters because the name misleads almost everyone who reads it. This article separates what actually listens from what merely sounds like it does, names the platforms individually, and gives you a verification procedure that does not depend on trusting any vendor's summary.

The short answer, by format

Remote technical evaluation splits into three formats, and audio behaves differently in each.

Browser-based proctored assessments. Audio capture varies by vendor. A web page cannot open your microphone silently, so the permission prompt on the setup screen is a reliable indicator of whether audio is in scope.

Desktop lockdown applications. These install and run outside the browser sandbox, so browser permission rules do not constrain them. Here you are relying on the vendor's disclosure and your operating system's own permission settings rather than on a page-level prompt.

Live interviews over a call. Audio is captured by definition, because the interview is a conversation. The open question is not whether audio exists but whether it is recorded, transcribed, retained, and reviewed later.

Confusing the first category with the third produces most of the anxiety candidates report. A take-home assessment on a proctored platform and a live pair-programming session are governed by different mechanisms.

What HackerRank's "conversation detection" actually detects

HackerRank's Proctor Mode support documentation describes conversation detection as identifying "patterns where candidates type and delete content in the editor that may indicate external communication." It is a text-behavior signal. It watches the code editor for writing and erasing, on the theory that a candidate relaying a question to someone else may type it, read a reply, and delete it.

HackerRank's July 2026 release notes reinforce that reading. The update states that conversation detection now recognizes broader communication patterns, "including regional languages written in English." Audio analysis would not be described in terms of what is written.

The same documentation lists what Proctor Mode does require: webcam access, which "allows the system to monitor and record the candidate through the webcam during the test," and screen-sharing access. It describes webcam images captured every five seconds, screenshot capture at fifteen-second intervals tightening to five during suspicious activity, multiple-monitor detection, and a gaze-detection feature analyzing eye and head movements. Microphone access does not appear in that permission list.

So on HackerRank's assessment product, as documented in August 2026, talking out loud is not the monitored event. Typing a question and deleting it is. For the fuller picture of that platform's signal set, see what HackerRank proctoring detects and records.

This is a good general lesson: the marketing name of an integrity signal tells you what the vendor thinks it catches, not which sensor produces it.

Platforms that do capture audio

Other vendors are explicit that the microphone is in scope. These are vendor descriptions of their own products, not independent verification.

CodeSignal's proctoring and ID verification one-pager states that "during the evaluation, CodeSignal records the candidate's video, audio, and computer screen," and lists camera and microphone among the accesses candidates are prompted to share, alongside screen and a government-issued photo ID. On CodeSignal, audio recording is part of the baseline proctored configuration rather than an add-on signal.

Talview's candidate documentation describes analyzing "background voices" and flagging "background noises or conversations detected during the exam," attributed to its AI proctoring agent.

Mercer Mettl defines the category directly in its glossary: "Audio proctoring leverages the microphone to scan the test-takers' physical environment for additional sounds or noises to minimize instances of cheating," and says the technology identifies "whispers, low sound levels, mumbling, and other such inconsistencies." Mettl also claims the system separates candidate audio from background noise well enough to avoid unwanted false flags — a vendor claim about accuracy that the glossary entry does not substantiate with published error rates.

Note the asymmetry in evidence quality. Every vendor documents that its audio proctoring detects things. None of the sources above publishes a false-positive rate for a candidate in a shared apartment, a household with children, or a room facing a street.

Live interviews are a consent question, not a detection question

When the assessment is a conversation, the microphone is the medium. HackerRank's interview documentation confirms this plainly: starting a call prompts you to select devices for "your webcam, microphone, and speakers," and states that "the interviewer and the candidate must ensure that browser or system permissions are granted to use the microphone and/or webcam during the interview."

What varies is what happens to that audio afterward. CoderPad's AI Notetaker documentation describes a model worth knowing, because it is unusually candidate-favorable: an organization administrator enables the feature, but "each individual call participant must opt into the AI Notetaker in order for their voice to be transcribed." The documentation continues that "the candidate will be informed at the time they join the call that the call will be recorded to transcript only (no audio/video will be stored). They can agree to be transcribed or opt-out and join the call normally," and that participants can stop or mute transcription at any time.

That is transcription under disclosed consent, with an opt-out and no stored audio. It is a different thing from covert audio proctoring, and it is reasonable to treat it differently.

Where each platform stands

Verified against vendor documentation on 31 August 2026. Configurations are set by the employer, so a specific invitation may differ from the platform default.

The conclusion without the table: assume nothing from the category label. Two coding-assessment platforms in the same procurement bake-off can differ on whether your room is being listened to.

How to check before you start

You do not have to guess, and you should not rely on a forum post about how a platform behaved last year.

Read the consent screen rather than clicking through it. Proctored platforms disclose capture scope there because they need your agreement to be legally meaningful. It is the most current, most specific statement of what that employer configured.

Watch which browser permissions are requested. For anything running in a browser tab, this is close to definitive. MDN's documentation of getUserMedia() states that it "must always get user permission before opening any media gathering input such as a webcam or microphone," and that browsers "are required to display an indicator that shows that a camera or microphone is in use, above and beyond any hardware indicator that may exist." A browser assessment that never asks for microphone access is not recording your microphone.

Recognize where that guarantee stops. The browser permission model governs web pages. A desktop lockdown client is an installed application, and its capture scope is set by what you granted the application at the operating-system level. If your assessment arrives as a download rather than a link, the browser tell is unavailable to you — see what changes when the assessment is a desktop app rather than a website.

Ask, in writing, once. A short neutral message to the recruiter — whether the session is proctored, whether audio is recorded, and how long recordings are retained — produces an answer you can keep. Vendors document defaults; only the employer knows the configuration.

If you use a voice-driven interview assistant

Real-time interview assistants work by listening. Control is a desktop application for Windows and macOS that transcribes the live conversation to build context, accepts screenshots of a problem, and returns answers in an overlay driven by global hotkeys; its published documentation states that it does not appear in supported screen captures and does not take focus from the window being shared.

Two honest implications follow from the sourcing above.

Screen-capture behavior and audio capture are separate mechanisms. A tool characterized by how it behaves in a screen share is not thereby characterized in an audio recording, and on a platform like CodeSignal that records candidate audio by default, everything audible in your room is in that recording regardless of what any application does or does not do on your display.

Any application using your microphone is subject to your operating system's permission model and whatever in-use indicators that system provides. That is a property of the platform you are running on, not of the assistant. If you are weighing what a live assistant captures on your side, the candidate privacy checklist for AI interview assistants works through retention, transcription, and consent questions in more depth.

What an audio flag actually proves

Very little on its own, which cuts both ways.

Audio proctoring detects sound, not intent. A flatmate on a phone call, a television in the next room, and a candidate reading a problem statement aloud to think through it are acoustically similar events to a system trained to notice a second voice. Reading aloud is a legitimate and common problem-solving habit, and no vendor source reviewed here claims to distinguish it from dictation reliably.

Nor is a flag a verdict. Integrity signals are usually surfaced to a human reviewer with a severity level, and HackerRank's own July 2026 notes describe tuning gaze detection to a medium-severity signal specifically "to reduce false positives." What happens next is a review process, not an automatic rejection — a distinction covered in what happens when a coding assessment flags you.

The practical takeaway

Before a remote technical assessment, determine three things: whether it runs in a browser or an installed application, which permissions it requests, and whether the session is live or asynchronous. Those three answers tell you nearly everything about whether audio is in scope, and all three are available to you before you begin.

Do not infer audio monitoring from a signal name, and do not assume its absence either. HackerRank documents conversation detection without requesting a microphone. CodeSignal records audio as a matter of course. Both statements are current as of 31 August 2026, both come from the vendors' own documentation, and neither generalizes to the other platform.

If your next step is understanding the rest of the signal set rather than the audio question specifically, the HackerRank proctoring detection and recording guide covers the screenshots, gaze, and monitor signals in the same source-first way.