Fake Coding Interview Scams: A Safety Guide

A coding assessment can be a normal part of applying for a developer role. It can also be the delivery mechanism for malware.

On September 18, 2026, security agencies from Japan, the United States, Australia and Germany published a joint advisory about a North Korean cyber group they call WaterPlum, commonly known as Contagious Interview. The agencies say the group poses as prospective employers, advertises attractive technology roles and targets developers through social media, job platforms, gig sites and freelance marketplaces.

The danger begins when a supposed recruiter asks the candidate to download a project, install a package, open a development workspace or fix an “error” during a video interview. The task looks professionally relevant. Running it can give an attacker access to passwords, browser data, identity documents, client files and other sensitive information.

This does not mean every take-home test is dangerous. Reputable employers use coding exercises every day. The goal is to separate a legitimate assessment from a request that puts your device, clients and career at unnecessary risk.

Fake Coding Interview Scams: A Safety Guide

What the new advisory says

The joint warning was issued by Japan’s National Police Agency and National Cybersecurity Office, the FBI, the U.S. Defense Cyber Crime Center, the Australian Signals Directorate’s Australian Cyber Security Centre, Germany’s Federal Intelligence Service and Germany’s domestic intelligence agency.

According to the advisory, WaterPlum infected at least 30,000 devices in more than 100 countries between roughly December 2025 and July 2026. It says credentials or funds were taken from more than 7,000 cryptocurrency wallets, with approximately $10.71 million transferred to North Korea. ITPro, Tom’s Hardware and The Hacker News separately reported the figures after reviewing the warning.

The attackers’ methods are relevant even to developers who never use cryptocurrency. The advisory says stolen information can include browser logins, keystrokes, screenshots, clipboard contents, passport or driver’s-license images, files in shared folders and access to employers or clients. A compromised freelancer’s laptop can therefore become a route into another organization.

The reported malware families include malicious npm packages, information stealers and remote-access tools. One technique hides execution inside a VS Code project configuration so that trusting and opening the workspace can trigger code. Another presents a fake technical problem during an interview and asks the candidate to copy a command or run a “fix.”

Why experienced developers can still be caught

This attack does not depend on a candidate knowing nothing about technology. It uses ordinary professional behavior against them.

A developer expects to clone repositories, install dependencies and run unfamiliar applications. Time pressure during a live interview makes careful inspection harder. A polished recruiter profile, realistic company page and video call create social proof. An attractive remote salary can make an unusual instruction feel like a reasonable test of initiative.

Malicious projects may also contain enough normal code to look credible. The harmful step can sit in a dependency, installation script, task configuration or obfuscated command rather than in the file a candidate expects to review. Antivirus protection helps, but it is not permission to run untrusted code.

The correct mindset is simple: a recruiter is an unknown third party until independently verified, and interview code is untrusted code until safely examined.

Seven checks before downloading anything

1. Find the vacancy independently

Do not use only the link in the recruiter’s message. Type the company’s official domain yourself, open its careers page and look for the role. A missing listing is not automatic proof of fraud—some searches are confidential—but it requires direct confirmation through a contact method published on the official website.

2. Verify the recruiter outside the conversation

Check whether the email domain exactly matches the employer’s domain. Look for small substitutions, extra words and different top-level domains. Call or email the company through independently sourced contact details. Ask whether the named person, vacancy and assessment are genuine.

A real LinkedIn profile is not decisive. Accounts can be copied or compromised, and attackers can construct coordinated company pages and code-hosting profiles.

3. Compare the process with the company’s normal hiring flow

Ask who will evaluate the assignment, what the task measures, how long it should take and whether a browser-based environment is available. Be cautious if the recruiter skips ordinary screening, pushes an urgent download, refuses written instructions or changes platforms repeatedly.

4. Inspect the repository before trusting it

Read the project in a non-executing view first. Check its age, commit history, contributors, dependency files, installation scripts and task configurations. In VS Code, keep an unfamiliar folder in Restricted Mode and answer “No” when asked whether you trust its authors. The joint advisory specifically recommends checking .vscode/tasks.json for instructions that download or execute additional files.

If you cannot confidently review what the project will do, do not run it locally. That is a security boundary, not a failure of technical skill.

5. Never use your everyday work environment

Do not test recruiter-supplied code on a device containing client repositories, production credentials, browser sessions, password-manager access, identity scans or financial accounts.

For developers who understand isolation, a disposable virtual machine or sandbox can reduce exposure. It should contain no personal accounts, wallets, secrets, SSH keys or shared client folders. Disable unnecessary clipboard, drive and credential sharing, take a clean snapshot and destroy the environment afterward.

A virtual machine is not a magic shield. Misconfiguration, shared resources and advanced exploits can still create risk. Less experienced candidates should request a browser-based assessment or a code-review exercise that does not require local execution.

6. Treat “troubleshooting” commands as code execution

An interviewer may claim the video platform, microphone or assessment portal has failed and ask you to paste a command into a terminal, PowerShell or Run dialog. Stop. You should not execute a command you do not fully understand merely to continue an interview.

Use the official application installer or support page obtained independently. Suggest rescheduling or switching to a standard platform. A legitimate recruiter should accept a reasonable security boundary.

7. Keep high-value data off the test device

Isolation is most effective when there is little to steal. Do not sign into personal email, cloud storage, banking, a cryptocurrency wallet, a production dashboard or your main password manager inside the assessment environment. Use unique temporary credentials when an account is genuinely required, and remove them afterward.

A safer workflow for legitimate coding assessments

Legitimate companies can make their tests safer, and candidates can ask for that structure without sounding uncooperative.

Start with a written task description from a verified corporate address. Prefer an established assessment service, browser IDE, shared screen code review or small original task that does not need unknown dependencies. If a repository is necessary, the employer should identify the organization that owns it, explain the expected commands and allow time for inspection.

Before execution, record the clean state of your isolated environment. Review package and task files. Do not import real API keys or reuse credentials. Limit network and file access to what the exercise needs. When finished, submit only the requested work, sign out, revoke temporary access and delete the environment.

These precautions may add time. That is the main limitation: highly restrictive isolation can make some frameworks difficult to test, and a small employer may not have a formal assessment platform. The answer is negotiation, not blind trust. Ask for a sanitized repository, container specification, pair-programming session or alternative task.

Red flags during a developer interview

One signal alone may have an innocent explanation. Several together should stop the process.

  • An unsolicited high-paying offer with little discussion of your actual experience.
  • A recruiter using a free email account or a domain that almost matches the employer.
  • Different company names or domains across the vacancy, meeting invite, repository and recruiter profile.
  • Pressure to clone and run code immediately during a call.
  • A request to disable antivirus, browser protection or workspace restrictions.
  • A “technical error” that can supposedly be fixed only by pasting a supplied command.
  • Obfuscated scripts, encoded blocks or unexplained downloads.
  • Requests for wallet access, seed phrases, payment, identity scans or financial details before a verified offer and lawful onboarding process.
  • Anger or threats when you request verification or a safer assessment method.

Do not confront a suspected attacker or reveal your security setup. End the session, preserve the messages and report the account through the platform.

What to do if you ran suspicious interview code

Act as though information may already have left the device.

First, disconnect it from Wi-Fi, Ethernet and other networks. Do not use the potentially compromised machine to change passwords. From a separate clean device, change the password for your primary email first, then important work, cloud, financial and developer accounts. Enable multifactor authentication and revoke active sessions, application tokens, API keys, SSH keys and other credentials that were present.

If the device accesses client or employer systems, notify their security contact immediately. Speed matters more than embarrassment; the advisory warns that attackers may pivot into organizations connected to a targeted developer.

Preserve the recruiter profile, messages, meeting invitation, repository URL, filenames, timestamps and any commands shown. Do not keep reopening malicious files to collect evidence. Report the incident to the hiring platform and the impersonated company. U.S. victims can file a report with the FBI’s Internet Crime Complaint Center at IC3.gov; people elsewhere should contact their national cybercrime or police reporting service.

The joint advisory recommends assuming stolen wallet information may already be compromised, moving assets to a newly created wallet on a separate clean device and keeping the new seed phrase offline. It also advises backing up essential data and performing a full operating-system reset because malware may persist after apparent removal. For business systems or uncertain cases, use a qualified incident-response professional rather than relying only on a consumer malware scan.

The practical rule

A legitimate coding interview evaluates your judgment as well as your output. Refusing to run unexplained code on a sensitive computer is good engineering practice.

Verify the employer through an independent channel. Read before executing. Use a disposable environment without secrets. Treat troubleshooting commands as untrusted code. If a recruiter will not permit basic safety measures, the opportunity is not worth the access it demands.

Your laptop may contain years of professional trust. No interview should require you to gamble it.

Leave a Reply

Your email address will not be published. Required fields are marked *