Article Building Engineering Teams
The Binance heist started with a job interview. Your take-home runs the same risk in reverse
In short
An in-house take-home assessment moves code between strangers and a company’s engineers. North Korean hackers already use fake coding assignments to break into companies, and they already apply for engineering jobs as candidates. A candidate’s submission is untrusted code, and running it on a work laptop gives it the same access the reviewer has.
- Binance says its $6.3 billion hack began with a fake job interview. In the second round, an engineer was told to download an “assignment” that was malware, and from his laptop the attackers took over 2 more engineers’ laptops.
- Fake coding assignments are an established attack. In 2025, security researchers tied 338 malicious npm packages to a North Korean campaign that poses as recruiters, and those packages were downloaded more than 50,000 times.
- North Korean operatives also apply for engineering jobs as candidates. Kraken kept one in its hiring process in 2025 to study how they work.
- An in-house take-home asks your engineers to download and run a stranger’s code. A malicious dependency can run the moment someone types npm install.
- Opening submissions in a sandbox protects you only when every reviewer does it, every time.
- A secure take-home keeps the task, the answer and the review inside an isolated environment, and confirms who took it.
What happened at Binance?
In October 2026, hackers drained $6.3 billion in crypto from Binance’s wallets, in what the BBC calls the largest crypto hack to date. Binance suspended withdrawals for customers worldwide while it contained the attack.
On November 3, 2026, Binance published its initial findings. It described a “sophisticated, multi-stage campaign,” and the campaign started with a job search. One of its engineers was “contacted through a legitimate job-hunting platform by an individual posing as a Project Director,” Fortune reported. He was invited to interviews with fake company representatives, including a fake HR representative and a fake CEO. To build trust, the attackers shared social media accounts filled with personal photos.
In the second interview, the engineer was told to download an “assignment.” It was malware, hidden with “obfuscation techniques” that evaded detection, the BBC reported. The attackers then used his computer and a compromised internal AI tool to take over 2 more engineers’ laptops, and from there the tools that controlled Binance’s wallets.
Binance now says, in a post on X: “The latest information released by the Federal Bureau of Investigation indicates that the Democratic People’s Republic of Korea is responsible for this incident.” North Korea denies it.
What stayed with me is how ordinary every step looked. A recruiter on a job site, friendly interviewers with real-looking social profiles, then a task to complete in the second round. That is the hiring process most engineers have been through, which is exactly why it works as a way in.
Why do attackers use job interviews to break in?
Because tech hiring has made “download this and run it” a normal request. Plenty of companies send candidates a repository to clone, ask them to install its dependencies and have them build a small feature on their own laptop. An engineer who gets that request from a recruiter has no reason to be suspicious.
North Korean hackers have built a long-running campaign on that habit. Security researchers call it Contagious Interview. The attackers “pose as recruiters or hiring managers on LinkedIn,” and their victims “are asked to complete coding assignments as part of a supposed interview process,” eSecurity Planet reported in October 2025. In one case, a software engineer was asked to clone a repository that pulled in a malicious npm package. Researchers found 338 malicious packages tied to the campaign, downloaded more than 50,000 times.
The packages use npm lifecycle hooks, such as postinstall, which run code automatically when a package is installed. Typing npm install is enough to set them off. Nobody has to open a file or read a line of code. The payloads go after browser credentials, API tokens and cryptocurrency wallets.
An engineer’s laptop is worth the effort. It holds source code, cloud credentials and access to internal tools. At Binance, one infected laptop led the attackers to 2 more, and then to the tools that controlled the wallets.
Could the same attack reach your company through a take-home?
Flip the direction. Your team runs its own take-home: a GitHub repository that candidates clone, complete at home and send back. A candidate returns a submission with one extra dependency. One of your engineers clones it onto a work laptop and runs npm install to check that the tests pass. The install script now runs with everything that laptop can reach: your source code, your cloud accounts and your internal tools.
The attacker only has to apply. Your hiring process invites them to send you code, and asks one of your engineers to run it.
North Korean operatives already apply. In 2025, Kraken identified a North Korean applicant for an engineering role and kept them in its hiring process to study how they worked, The Block reported. Kraken found that “one individual had established multiple identities to apply for roles in the crypto space and beyond,” and that “several of the names had previously been hired by multiple companies.”
Every part of that attack is already in use: the malicious coding assignments, the fake candidates, and the engineers who run code from strangers because a hiring process asked them to.
Isn’t it enough to open submissions in a sandbox?
A sandbox protects you when someone uses it. The risk sits in the times nobody does. Your team has to build it, maintain it and remember it. Every reviewer has to use it for every submission, including the engineer who reviews 3 take-homes the night before a debrief.
There is a second cost. Every time your process asks a candidate to clone your repository and run it locally, it teaches engineers that real employers ask for this. That is the cover fake recruiters rely on. When real employers keep their assessments off candidates’ machines, a fake request stands out.
What does a secure take-home assessment look like?
Run any take-home process, your own or a vendor’s, against these 5 checks.
- The task and the answer stay in an isolated environment. Candidates never download your code to their own machine, and your engineers never download theirs.
- Reviewers run the code where it was written. Your engineers see the tests, the output and how the solution was built, all inside the platform.
- You know who took the assessment. Kraken’s applicant came apart when asked to hold up a government ID and confirm their location. Identity verification before the assessment puts a check like that at the start of the process.
- Candidates know what to expect. Tell candidates in your first email which platform the assessment runs on and how your team will contact them. A request that doesn’t match stands out.
- The vendor passes your own security review. Ask for SOC 2 Type II and ISO 27001 reports, and ask where candidate code runs.
Where does Codility fit?
Codility passes all 5 checks.
Candidates work in the browser, or in Codility’s desktop app when you want a more locked-down setup. Either way, the task runs in an isolated virtual machine on Codility’s infrastructure. The task never leaves that environment, and neither does the candidate’s answer. Nothing comes back to your team as a file.
Your engineers read, run and replay the solution inside the candidate report. Nobody clones a repository or runs npm install on a work laptop.
You can turn on identity verification before the assessment starts. Codility is SOC 2 Type II audited and ISO 27001 certified, with EU or US hosting on AWS. Our security and compliance page has the details your security team will ask for.
Candidates still get real work: a real-world task from the job, in a real VS Code environment, the same kind of work an in-house take-home is built to test. An in-house take-home asks your engineers to trust every candidate’s code. Codility never asks them to.
About the author
I lead product marketing at Codility, where I own how the platform is positioned across Screen, Interview and Skills Intelligence, and I work alongside the Assessment Science team behind the Engineering Skills Model. I came to hiring from the other side of the AI question: before Codility I led product marketing for AI data and model evaluation at Toloka, serving frontier AI labs and large technology companies. I have also built marketing teams from nothing 3 times, so the hiring problems I write about are ones I have had myself. I am based in Rome, Italy.
Frequently asked questions
They can be, in both directions. Attackers posing as recruiters have used fake coding assignments to install malware on engineers’ machines. A take-home that a company receives from a candidate is also untrusted code, and running it on a work laptop gives it the access that laptop has. That is why the whole assessment, from the task to the review, should run in a self-contained environment built for it, such as Codility, where candidate code runs in an isolated virtual machine on the vendor’s infrastructure. Nobody downloads the task or the answer, which removes the risk of a submission’s code ever running on a company machine.