The interview is not the sandbox: when a coding test becomes a security decision

A coding assessment is supposed to answer whether you can do the work. It should not quietly become a decision about whether an unfamiliar recruiter can introduce software into the computer that holds your personal accounts or your employer’s credentials.

That boundary is uncomfortable because technical interviews often involve running code. A request that would look unusual in a bank email can look normal in a developer hiring process. The candidate expects a repository, a dependency install and a deadline. The attacker does not need to invent a completely foreign activity; the risk can hide inside the expected task.

The useful response is not to abandon take-home assessments. It is to separate evaluating code, trusting its execution and granting access to the surrounding environment.

The reported campaign, without the sensational framing

In its March 11, 2026 Contagious Interview report, Microsoft described staged recruiting interactions that persuaded developers to execute malicious assessment material. The campaign had been active since at least December 2022; the publication was not announcing that fake technical interviews had just begun.

The report illustrates a recruitment workflow being used as a delivery route. It does not mean that all take-home tests, code-hosting services or remote recruiters are fraudulent.

Our analysis focuses on the candidate’s decision and the hiring organization’s responsibilities. It avoids reproducing execution commands or turning the reported technique into an attack recipe.

The candidate faces two different uncertainties

A real company name does not resolve the first question. A recruiter can impersonate a real employer. A professional conversation can establish rapport without proving that the person has authority to hire for that company.

A verified recruiter does not automatically resolve the second question either. Legitimate assessment materials can contain mistakes, unnecessary dependencies or unsafe assumptions. Security review should not depend on deciding that a person is malicious.

Separating the questions lets a candidate ask reasonable technical and administrative questions without making an accusation. A competent hiring process should be able to explain both its identity and its assessment requirements.

Verify the opportunity outside the conversation

Find the employer’s official recruitment information through an independent route. Confirm that the role and recruiter are connected to it using contact information that did not come only from the unsolicited message.

Be cautious about treating a social profile, video call or company-branded document as the final verification. Each may provide context, but none necessarily establishes authority over the hiring process.

The FTC’s job-scam guidance offers a broader consumer baseline: independently research opportunities and be alert to demands for money or sensitive information. A technical assessment adds another issue—what code or software the candidate is being asked to execute.

If the employer cannot confirm the process, stop before providing more information or running the material. The loss of a possible opportunity can feel costly, but uncertainty should not be resolved by exposing unrelated accounts and systems.

“Read the code first” is useful but incomplete

Reviewing an assignment can reveal whether its contents match the stated task. However, a quick glance at a small application is not the same as understanding everything its tooling may execute.

Dependencies, editor configuration and setup steps may have effects beyond the visible exercise. A candidate under interview pressure should not be expected to perform a complete security audit of an unfamiliar software supply chain as an unpaid preliminary task.

The assessment should therefore have a bounded environment and a transparent setup. Ask what needs to run, why it is necessary and whether a supported alternative exists.

Our article on ClickFix-style verification commands addresses a related boundary: a page or person asking you to execute a “quick fix” does not establish that the command is necessary or safe.

A safer assessment agreement

This table is an editorial checklist, not a certification standard. The appropriate arrangement depends on the role and the test. A short code review, a browser-based exercise and a substantial systems task will not require identical tooling.

The important feature is predictability. Candidates should know the setup before the timed portion begins, not discover sensitive permission requests while an interviewer watches the clock.

Isolation is a design, not a magic word

A dedicated assessment environment can reduce exposure, but calling something a sandbox does not establish its boundaries. Consider what accounts are signed in, which files are shared, what network resources are reachable and whether credentials are available inside it.

A virtual machine with mounted personal folders and active work tokens can carry risks that the candidate thought they had excluded. A separate browser profile is not equivalent to a separately controlled execution environment.

For employer-owned devices, follow the employer’s policy and consult its responsible team. Do not install interview material on a corporate machine merely because it is more powerful or already has the required tools.

For personal assessments, choose a setup whose limits you understand. If you cannot confidently bound the exposure, ask the hiring organization for an approved alternative rather than improvising around a warning.

The awkward moment when the setup fails

An interviewer may say that the project works for everyone else and suggest a quick repair. The candidate may feel pressure to demonstrate adaptability. This is a particularly important moment to slow down.

Troubleshooting should not require disabling security protections, sharing unrelated credentials or running unexplained material supplied during the call. A legitimate technical obstacle can be addressed by rescheduling, reviewing code without execution or using a prepared environment.

A hiring team should explicitly allow these alternatives. Otherwise it teaches candidates that professional competence means overriding their own security boundaries to keep an interview moving.

The channel-switch trust model is useful here: agreeing to discuss a role is not agreement to every subsequent installation, account connection or remote-access request.

What responsible hiring teams can improve

Publish the expected assessment format and software requirements through the employer’s established recruitment channel. Give candidates a verifiable contact for questions. Avoid introducing a new platform or download through an unexplained last-minute message.

Use synthetic data and remove secrets from sample projects. Document setup steps and review dependencies. Keep the assessment proportional to the skills being measured; unnecessary complexity creates both candidate friction and extra uncertainty.

Do not penalize a candidate for asking about permissions or requesting a safe alternative. Those questions may demonstrate judgment relevant to the job.

If a recruiter or assessment provider is external, make its relationship to the employer clear through an independently verifiable route. Outsourcing the scheduling should not outsource all responsibility for the candidate’s security experience.

If assessment material has already been executed

Stop further interaction with the questionable material and contact the responsible security or support team if the device belongs to an organization. Describe what ran, when, on which device and with which accounts or credentials available.

Do not assume that deleting the repository removes everything that execution may have changed. Do not assume that an apparently uneventful run proves nothing happened. Investigation should be based on the device and account evidence.

Preserve the recruitment messages, repository address, downloaded files and timing according to the team’s instructions. Avoid forwarding executable material casually to colleagues or uploading confidential logs to public discussion boards.

If personal or work credentials may have been exposed, recovery should be coordinated from a trusted environment. The responsible provider or administrator can advise on sessions, tokens and other access beyond a simple password change.

A candidate’s decision can remain simple

You do not need to identify a named campaign to decline an unexplained execution request. You need enough evidence to justify the requested access. If the employer is verified but the setup is unsafe, the right conclusion can simply be that the assessment needs a different environment.

If the recruiter is unverified, technical sophistication does not compensate for that missing identity. A polished repository and an articulate interview are not substitutes for an independently confirmed hiring relationship.

Keep a record of your questions and the offered alternatives. This helps distinguish a normal disagreement about assessment design from an attempt to force escalating access.

A healthy hiring process makes that boundary easier to maintain. It does not turn a candidate’s caution into evidence that they are uncooperative, unskilled or insufficiently interested in the role.