Beware of Demo Projects Sent in Job Applications

Test-Like Assignments Can Put Your Computer at Risk

In recent years, demo projects and technical assignments have become very common in hiring processes. In fields like software development, data analysis, cybersecurity, and design, candidates are often asked to build small applications or review existing projects.

When used correctly, this approach is a useful way to evaluate a candidate’s skills. However, the same mechanism can also be exploited by malicious actors as an attack surface.

The process is usually simple:
You apply for a job, have a short interview, and then receive a project file.

Typical assignments look like this:

• Run the application and update a specific screen
• Fix a bug
• Complete an API integration
• Configure a database connection

At this point, many candidates download the files and run them directly. This is where the risk begins.

Where Does the Risk Start?

Sharing source code does not automatically mean it is safe. A running project can trigger not only the visible interface but also many background processes.

For example:

• Malicious scripts may execute
• Backdoors can be installed on the system
• Browser sessions may be targeted
• Crypto wallets can be scanned
• SSH or API keys can be stolen
• Files can be exfiltrated

All of this can happen without the user noticing.

In particular, ZIP files from unknown sources, projects without a Git history, or non-transparent hiring processes require extra caution.

“I’ll Review the Code First” Is Not Enough

Many developers assume that checking the code before running it is sufficient. However, in modern projects, this is not always the case.

Because the risk is not limited to the application code itself—it exists across the entire ecosystem:

• Dependencies (npm, pip, etc.)
• Installation scripts
• Build processes
• Docker configurations
• CI/CD pipelines
• Git hooks
• IDE automation scripts

For example:

• preinstall and postinstall scripts in package.json
• Execution commands inside a Dockerfile
• Operations triggered via setup.py or requirements.txt
• Makefile and shell scripts

All of these can run automatically when the project is executed.

Safe Approach: Use an Isolated Environment

Never run demo projects directly on your main machine.

Systems that contain your personal files, passwords, or work accounts are not test environments.

Instead:

1. Virtual Machine

Tools like VirtualBox or VMware allow you to create an isolated system.

• Completely separate from your main system
• Can be easily reset
• Ideal for risky testing

2. Separate Test Device

A second computer used only for testing purposes.

• No personal accounts
• No sensitive data
• Acts as a safe experimentation environment

3. Cloud Environments

Temporary virtual machines or cloud-based development environments can also be used.

• Can be shut down after use
• Leaves no permanent risk behind

What to Check Before Running a Project

Before executing any project, ask yourself:

• Does the sender really represent a company?
• Are they using a corporate email address?
• Does the process match a legitimate hiring workflow?
• Is it a Git repository with history?
• Or is it a newly created, empty account?

These questions do not guarantee safety, but they help assess the level of risk.

Technical Red Flags

The following situations require extra caution:

• Password-protected ZIP files
• Executable EXE files
• Obfuscated code
• Installation requiring admin privileges
• Requests to disable antivirus software
• Scripts that download many external files
• Unexplained PowerShell or shell commands
• Suspicious binaries or compressed payloads

In such cases, the project should be analyzed more deeply before running.

A Security Habit for Modern Developers

In the past, the biggest risk in hiring processes was fake job postings. Today, technical assignments have become just as risky.

Questioning the safety of a project before running it is not paranoia—it is a professional habit.

Just as we would not open an unknown email attachment, we should not run an unverified project directly.

While evaluating job opportunities, it is not only the company that evaluates you—you should also evaluate the process and the files being shared with you.

A Simple Rule

Treat any project sent as part of a hiring task like an unknown executable file downloaded from the internet.

Looking trustworthy does not mean it is safe. First inspect it, ideally test it in an isolated environment, and only then run it.