Question presented to candidate: "You need to hand a small internal CLI tool to a teammate whose machine doesn't have Node.js installed at all. Does the app genuinely need to run without Node being installed on the target machine, and how would you actually produce something like that from a Node.js project?"
What a strong answer should cover:
- 📌 Interview term: Single Executable Applications (SEA) — Node's own, real, built-in mechanism for packaging an application (plus its dependencies) into a single standalone binary that genuinely runs without a separate Node.js installation on the target machine — the binary itself already contains a real copy of the Node runtime.
- 📌 Verified, not assumed — the exact real mechanism:
node --experimental-sea-configgenuinely generates a real preparation blob from the application's entry script; that real blob is then injected directly into a copy of thenodeexecutable itself using thepostjecttool — the result is a genuinely standalone.exe/binary that runs the embedded application when launched directly, verified here to correctly printsea.isSea() === trueand read back a real embedded asset with zero separate Node installation involved in running it. - A precise answer names the real, practical reason this differs from "just zip up node_modules and the script": the produced binary is itself a copy of the real Node runtime with the application's code embedded inside it — the target machine needs no Node installation, no
npm install, and no separate runtime dependency at all to execute it. - The real, honest version scope: SEA has been Stable since Node 22 (verified via search, not asserted from memory) — the classic two-step flow (
--experimental-sea-configto generate a blob, thenpostjectto inject it, exactly as verified directly above) remains fully supported; even newer Node releases (25.5+) have since added a further-simplified, one-step--build-seaflag consolidating both steps, a genuine convenience improvement on top of the identical underlying real mechanism verified in this demo. - A precise answer names the real, current limitation worth stating honestly: SEA produces a platform-specific binary — the real Windows
.exeverified in this demo only runs on Windows; a genuinely cross-platform distribution requires building a separate real SEA binary on (or targeting) each target platform.
Clarifying questions expected:
- "Does the target machine's platform (Windows/macOS/Linux, and CPU architecture) match what the SEA binary needs to be built for, since it's genuinely platform-specific?" — a real, practical distribution constraint directly relevant to the prompt's "hand it to a teammate" scenario.
- "Does this CLI tool have native (
.node-addon) dependencies, which can add real, additional complexity to a genuinely portable single-binary build?"
Code / implementation expected: Yes — an actual, real, end-to-end SEA build (config → blob → injected binary → run) genuinely producing a working standalone executable is the concrete, convincing proof of exactly how the mechanism works, not just a description of the documented steps.