November 3, 2026·8 min read
A VM-based coding assessment gives a candidate a real virtual machine: its own kernel, its own root user, its own network stack, a terminal instead of a text box. Nothing about it is simulated. If the candidate reboots it, it actually reboots. If they run out of disk space, df actually says so.
That sounds like a small implementation detail until you try to assess anything that is not a pure function. A service that needs restarting, a config file that needs editing, a process that needs killing to see whether it comes back on its own, none of that fits inside the box-in-a-browser that most coding tests still use. This post is for hiring managers and engineering leads who are choosing an assessment format and want to know, concretely, what "VM-based" buys you, what it costs, and when a lighter sandbox is the more honest answer.
Every coding assessment runs the candidate's work somewhere, and where matters more than most job descriptions of "hands-on" let on.
The browser judge. This is the HackerRank/Codility/CodeSignal model: the candidate writes into an editor, a backend service runs the snippet against hidden test cases, and a process (often itself sandboxed, sometimes with something like gVisor between the code and the host) returns pass or fail. There is no machine the candidate can see. There is no state that survives one run to the next.
The container. The candidate gets a shell, but it is a Docker container, or something like it, sharing the host's kernel through namespaces and cgroups. This is a real step up: a filesystem, a shell, the ability to install a package. But the kernel is not theirs. NIST's guidance on container security is explicit that this shared kernel is the boundary that matters: a container "shares the OS kernel with the host and other containers on the same host system," which is why container escapes and host misconfiguration are treated as a distinct risk category from VM escapes (NIST SP 800-190). For an assessment, the practical version of that fact is smaller and duller: most container images used for candidate sandboxes do not run systemd or a real init system, so half the diagnostic commands a working engineer reaches for do not behave the way they do on a real host.
The VM. Its own kernel, its own init system, its own PID 1. Root is a normal, expected thing to have, not a misconfiguration. It boots, it can be broken on purpose, and it can be rebooted for real.
| Browser judge | Container | Full VM | |
|---|---|---|---|
| Kernel | Hidden, shared | Shared with host | Its own |
| Root access | None | Unusual, and risky if granted | Normal |
| Real init system (systemd, journald) | No | Rarely | Yes |
| Long-running services, crash and restart | Not applicable | Awkward | Native |
| What a candidate "breaking" it costs you | Nothing, it is a function call | Depends on host isolation | Contained to that one machine |
Most of what a VM buys you shows up the moment the task stops being "write code" and becomes "operate a system."
Ask a candidate to find out why a service is running but not answering on its port, and the honest move is ss -lntp followed by journalctl -u <service>. Neither command means anything in an environment with no real init system and no real socket table. We wrote up six of these scenarios in detail in the Linux troubleshooting interview, and every one of them depends on the machine actually being a machine: a full disk that disagrees with itself because a deleted file is still held open, a cron job that fails only because cron's PATH is not your shell's PATH, a certificate failure that requires testing DNS, then the socket, then TLS, as three separate layers. A container can fake some of this. A VM does not have to fake any of it.
The same is true of the messier, less glamorous parts of the job: installing a package that needs a compiler toolchain, watching memory climb across a real process tree, configuring a firewall rule and confirming it with a real client on the other side of it. Realism is not a nice-to-have here so much as the entire point. In the widest meta-analysis of hiring assessments ever run, spanning 85 years of selection research, work-sample tests, tasks that mimic the actual job, came out among the strongest predictors of on-the-job performance available, ahead of unstructured interviews and most standalone ability tests (Schmidt & Hunter, 1998). A VM is not what makes a task a work sample. It is what stops the environment from silently disqualifying the task from being one.
None of this is free, and pretending otherwise is how teams end up with a format they resent by the third candidate.
Boot time. A container starts in under a second. A cold VM takes long enough that a candidate can watch the clock start before anything is on screen, which is a bad first ninety seconds for a timed assessment. The fix is a warm pool: keep a small number of pre-booted, unclaimed machines on standby for common configurations so a candidate is handed one instead of waiting for one, and only fall back to a cold boot for a configuration nobody predicted. That is an infrastructure decision a platform makes for you; it is worth asking any vendor what happens between "candidate clicks start" and "candidate has a prompt."
Cost per session. A VM reserves real CPU, memory, and disk for the length of the session, which is a higher marginal cost than a container that exists for the ninety seconds it takes to run a test suite. At the volume of an early-funnel screen sending hundreds of tests a week, that difference is real money, and it is one of the costs we walked through in what a coding assessment really costs, after the invoice.
No green checkmark. A judge grades itself: pass or fail, in milliseconds. A VM-based task usually does not have one right final state, which means a human, or an AI pass over a recording and a transcript, has to look. That review time is real, and pricing it into your process is more honest than pretending a rubric grades itself.
If your actual bottleneck is cutting five thousand applicants down to two hundred as cheaply as possible, a VM-based round is the wrong tool for that stage. A lighter sandbox or an algorithmic screen does that job at a fraction of the cost per candidate, and the realism a VM buys you is wasted on a round designed to filter volume, not to decide who joins the team. Save the machine for the round where being wrong is expensive: the final loop, or the round that used to be a whiteboard.
The same logic applies by role, not just by funnel stage. A task that is genuinely a pure function (parse this string, implement this algorithm) does not become more informative because it runs on a VM instead of in a judge. The format should follow the task, not the other way round.
If the round in front of you is the one that decides who joins the team, the setup is short:
Before you spec out a VM-based round, ask what a container or a judge would have hidden from you in your last hire's actual first month. If the answer involves a service that needed restarting, a log that needed reading, or a machine that needed rebooting, that is the shape of task a VM was built to test, and no amount of polish on a browser sandbox will get you there instead.
Run live coding sessions and take-home challenges in real production environments. Watch sessions back, score consistently, and hire with confidence.
More posts you might like
Most interviews reward the candidate who names a plausible cause fastest, not the one who confirms the real one. Here is how to build a root cause analysis assessment with more than one suspect, and what separates a verified cause from a good guess.
Hire the first engineer and you want someone who can do everything. Hire the tenth and you want someone who makes nine other people faster. Most startups run the same loop for both. Here is what to test at each stage, and the failure each one prevents.
Read more
Rust interviews still argue about the borrow checker, which the compiler settled before anyone sat down. Here are four tasks on a service that compiles cleanly and behaves badly, panics in the request path, a blocked async runtime, errors that help nobody, and a hot path nobody measured.
Read more
