Comment by koito17

The take-home assignments I've recently done, thankfully, were open-ended, and you were also evaluated based on how you architect the software, repository, etc. However, take-home assignments requiring one to download an existing project seem a lot more dangerous now.

> This attack vector is perfect for developers. We download and run code all day long. GitHub repos, npm packages, coding challenges. Most of us don't sandbox every single thing.

Even if it reflects badly on myself, one of the first things I do with take-home assignments is set up a development environment with Nix, together with the minimum infrastructure for sandboxed builds and tests. The reason I do this is to ensure the interviewer and I have identical toolchains and get as close to reproducible builds as possible.

This creates pain points for certain tools with nasty behavior. For instance, if a Next.js project uses `next/fonts`, then *at build time* the Next.js CLI will attempt issuing network requests to the Google Fonts CDN. This makes sandboxed builds fail.

On Linux, the Nix sandbox performs builds in an empty filesystem, with isolated mount / network / PID namespaces, etc. And, of course, network access is disallowed -- that's why Next.js is annoying to get working with Nix (Next.js CLI has many "features" that trigger network requests *at build time*, and when they fail, the whole build fails).

> Always sandbox unknown code. Docker containers, VMs, whatever. Never run it on your main machine.

Glad to see this as the first point in the article's conclusion. If you have not tried sandboxed builds before, then you may be surprised at the sheer amount of tools that do nasty things like send telemetry, drop artifacts in $HOME (looking at you, Go and Maven), etc.