The modern software interview often includes code. That can be reasonable. A short project may show how someone structures work, reads unfamiliar code, writes tests, or communicates tradeoffs.

The problem is not the existence of coding tests. The problem is that many hiring processes ask candidates to run unknown code without clear provenance, sandboxing guidance, or verification.

Attackers noticed.

Fake recruiter campaigns now use coding tests as a delivery mechanism. The repo may look like a normal app. The setup instructions may look routine. The malicious behavior may hide in install hooks, lockfiles, obfuscated utilities, development-server startup code, or packages pulled from unexpected locations.

The safest response is not to abandon technical assessment. It is to raise the standard for how assessments are handled.

The Candidate Rule: Verify Before You Execute

Before running a repository from a recruiter, candidates should pause and verify the source.

Useful checks:

  • Does the recruiter use an official company email domain?
  • Is the job listed on the company's official careers page?
  • Is the repository under the company's verified GitHub or GitLab organization?
  • Does the repo have realistic history, contributors, and documentation?
  • Are you being pushed to run it quickly?
  • Are you asked to connect a wallet, enter credentials, or expose environment variables?
  • Does the assignment require npm install, npm run dev, pip install, shell scripts, Docker builds, or other execution steps before review?

None of these checks is perfect. Real companies sometimes have messy processes. But multiple weak signals should change the default from "run it" to "verify it."

The most important rule is simple:

Do not run a recruiter-provided repo on a machine that contains secrets.

Use a disposable environment. If the assignment is legitimate, a professional hiring team should understand that boundary.

The Hiring Team Rule: Make Legitimacy Easy to Prove

Companies should not make candidates guess whether an assessment is real.

A safer coding-test process should include:

  • A link from the official careers domain explaining the assessment flow.
  • Recruiter communication from a company-controlled domain.
  • A repository hosted under an official organization.
  • Clear instructions that do not require secrets, wallets, personal tokens, or production-like credentials.
  • A checksum, signed release, or clear provenance for downloadable artifacts where appropriate.
  • A browser-based option or sandbox guidance for local execution.
  • Enough time for review before execution.
  • A contact path for candidates who want to verify the task.

This is not just candidate care. It protects the company from impersonation.

If attackers are using your company name, candidates need an easy way to tell the real process from the fake one. A public hiring-security page can do more than reassure candidates. It creates a reference point that scammers cannot easily fake across every channel.

The Security Team Rule: Treat Assessments Like Third-Party Code

Any code a candidate receives from outside the company should be treated as untrusted. The same applies to code employees receive from freelance platforms, "quick collaboration" offers, open-source maintainers they do not know, or vendors asking for local setup.

Security teams can reduce risk by creating guidance that is practical enough for real hiring and freelance workflows:

  • Use disposable VMs or cloud workspaces for unknown repositories.
  • Avoid using a daily-driver browser profile inside assessment environments.
  • Disable or restrict network access when full connectivity is not required.
  • Do not mount home directories or SSH folders into containers.
  • Do not reuse environments after running untrusted code.
  • Monitor unusual Node, Python, shell, package-manager, and outbound network activity from developer endpoints.
  • Separate personal crypto-wallet activity from development environments entirely.

The goal is to make the safe path easier than improvising under interview pressure.

The Platform Rule: Trust Signals Need to Be Machine-Readable

Recruitment platforms, code-hosting platforms, and infrastructure providers all see different parts of the scam.

LinkedIn or messaging platforms may see recruiter outreach. GitHub or GitLab may host suspicious repositories. npm, PyPI, and other ecosystems may see malicious packages. Cloud and hosting providers may host fake company sites or command-and-control infrastructure. Security vendors may see endpoint behavior after execution.

No single platform has the full picture.

That is why threat intelligence needs to connect signals:

  • Recruiter identity and communication channel.
  • Company and domain impersonation.
  • Repository age, ownership, and commit behavior.
  • Install hooks and dependency provenance.
  • Obfuscation, exfiltration, and command-and-control indicators.
  • Reports from previous targets.
  • Appeal and correction outcomes.

A candidate does not need all of this raw data. They need a clear verdict with evidence. Researchers and defenders need the structured indicators behind it.

What "Good" Looks Like

A safer coding test does not ask candidates to take blind risk.

For candidates, good looks like:

  • The recruiter identity is verifiable.
  • The company role exists on the official site.
  • The repo provenance is clear.
  • The task can be reviewed before execution.
  • The code runs in a disposable environment.
  • No sensitive credentials are required.

For employers, good looks like:

  • The assessment process is documented publicly.
  • Candidates can verify outreach easily.
  • Repositories are hosted under official accounts.
  • The task is scoped and auditable.
  • Candidate safety is treated as part of the hiring experience.

For security teams, good looks like:

  • External code execution is recognized as a risk.
  • Developer machines are monitored for relevant behavior.
  • Suspicious cases can be investigated without blaming the candidate.
  • Indicators can be shared with the wider community.

Where RTIdx Fits

RTIdx is built for the moment before a candidate decides whether to proceed.

A developer can paste the recruiter conversation and submit the coding-test repo. RTIdx extracts the relevant entities, analyzes the repo with static detection rules, checks for suspicious interaction patterns, and returns a plain-language explanation with a risk score and evidence breakdown.

That gives candidates a safer default: check first, run later.

It also helps hiring teams and researchers. When a fake assessment circulates under a real company name, reports can become structured evidence instead of scattered warnings. When a campaign reuses infrastructure, aliases, scripts, or repository patterns, the community can start seeing the pattern sooner.

Coding tests can remain useful. But they need clearer trust boundaries.

The industry normalized running code for interviews. Now it needs to normalize verifying that code first.

Sources

  • [Microsoft Security Blog: Contagious Interview malware delivered through fake developer job interviews](https://www.microsoft.com/en-us/security/blog/2026/03/11/contagious-interview-malware-delivered-through-fake-developer-job-interviews/)
  • [ReversingLabs: Graphalgo fake recruiter malware campaign respawned](https://www.reversinglabs.com/blog/graphalgo-campaign-respawned)
  • [The Register: Fake interview repos lure Next.js devs into running secret-stealing malware](https://www.theregister.com/security/2026/02/25/nextjs-jobseekers-targeted-with-malicious-interview-repos/5192390)