A Crypto Job Coding Test Can Steal Your Wallet: Check the Task

Do not run an unverified crypto job coding test on a computer that holds wallet secrets or active work credentials. A plausible project on a familiar hosting service is still someone else’s executable code. If you have already run it, stop using that device for wallet activity while you establish what happened; an unchanged balance does not establish that your secrets are safe.

The interview can be the delivery mechanism

Microsoft’s Contagious Interview investigation describes fraudulent hiring conversations that lead developers to execute malicious assessment material. Its observations include theft of wallet and credential material. The relevant warning is about the workflow, rather than every recruiter or every cryptocurrency employer.

F-Secure’s description of code-challenge scams also identifies downloads from legitimate hosting sites as a delivery route. A professional-looking conversation and a recognizable download domain answer different questions from whether this particular assignment is safe.

Imagine a fictional candidate, Maya, who receives a small dashboard project. The opening screen matches the advertised role, but the instructions demand an immediate setup change before she can inspect the task. Her decision should concern that setup change. Whether the dashboard looks convincing is not a substitute for understanding what she is being asked to authorize.

Check the company and the person separately

Start from an independently found company website and its stated recruitment route. Ask whether the role exists and whether the person and assessment belong to that process. Avoid treating a contact supplied inside the same unsolicited conversation as independent confirmation. A real business can be impersonated; finding its incorporation record or product does not authenticate the messenger.

1. Keep the vacancy URL, recruiter identity and project URL together so their relationship can be checked.
2. Find the employer’s own contact route independently and ask about the specific role and assessment.
3. Request a written description of what must run, why it is needed and what access it requires.
4. Offer an alternative demonstration of your skills if the requested setup exceeds what you can review safely.
5. Stop the assessment if the sender replaces a clear explanation with pressure to override a warning.

A refusal to use your main computer is a reasonable boundary for a job test. It is not a technical accusation against the sender. You can say: “I can complete a bounded exercise in a separate environment; I cannot run an unreviewed project with access to my personal or employer credentials.” Their willingness to discuss that boundary is useful context, not proof of legitimacy.

Installing dependencies is already an execution decision

Do not reserve caution for the final application launch. The npm lifecycle documentation explains that installation and preparation stages can run scripts. Review the requested setup before starting it; a command described as “just installing dependencies” can perform more than copying inert files.

In its own analysis of malicious assessment repositories, Atlassian describes substantial amounts of plausible application code surrounding a small malicious portion. Counting files, seeing a working interface or recognizing a framework cannot settle the safety question. None of those observations tells you what every setup step will do.

Workspace Trust helps, but it is not a certificate

The VS Code Workspace Trust documentation explains that Restricted Mode limits features such as tasks and debugging to reduce automatic execution from unfamiliar projects. It also states that malicious extensions can ignore that boundary. Keep the mode enabled while reviewing a project, and do not turn an unfamiliar extension into an exception simply because the assessment asks for it.

For a test that genuinely needs execution, arrange a separate assessment environment with no personal wallet material or employer credentials. Isolation is a design choice to limit exposure, not permission to trust the contents. If you do not know whether the environment shares sensitive resources with your usual computer, ask someone qualified to check it before proceeding.

A useful written boundary names what is absent: your ordinary browser sessions, wallet recovery material, production access and personal files. This is more useful than calling the setup a “sandbox” without understanding it. A recruiter should not need any of those resources to evaluate a fictional order screen or a small data-processing exercise.

If you already ran the test, separate evidence from reassurance

Microsoft recommends isolating a suspected compromised device, rotating potentially exposed credentials and tokens, and investigating continued access. Use a known-clean device and your organization’s incident process for account recovery. Do not keep opening the project to produce a better screenshot or let the same recruiter guide the investigation.

• Record when you downloaded and ran the project, the repository URL, the instructions and the warnings you accepted.
• List which accounts and wallet materials were accessible; distinguish confirmed exposure from items that still need investigation.
• Preserve the original messages and any transaction identifiers without posting passwords, recovery words or private files publicly.
• Notify the responsible security contact if employer accounts, repositories or systems may be involved.
• Ask for a recovery plan that covers accounts, wallet keys and the device itself rather than one password change.

In Maya’s example, an empty transaction history only tells her that she has not found a transfer. It does not answer whether a secret was copied, whether a work account was accessed or whether the device remains compromised. Conversely, receiving a suspicious link without executing its contents is not evidence that all those things happened. The response should follow the actions actually taken and the evidence available.

Keep the wallet problem distinct from the job application

Do not install a replacement wallet or sign a purported repair request supplied by the recruiter. The separate guide to fake wallet applications covers checking an application’s origin, while the permit and wallet-drainer guide explains a different authorization problem. A suspicious signing request and untrusted code execution can require different investigation paths.

An exchange is not a malware-removal tool. Resume ordinary activity, including a simple swap, only after you have a trusted device and have resolved the relevant access risks. The useful outcome here is a defensible boundary: verified hiring contact, bounded assessment environment, no real wallet secrets in the task, and a documented response if that boundary was crossed.