Bun.js Interview Questions (with short answers)

This repo is a lightweight set of Bun.js interview questions you can use for preparation or for running interviews.

Quick facts (what interviewers often test)

• What is Bun? A JavaScript runtime (like Node.js/Deno) built on JavaScriptCore (JSC) with a fast toolchain: bundler, test runner, package manager.
• What languages is Bun written in? Mostly Zig, with significant C++ (especially around JavaScriptCore bindings/integration) and some JavaScript/TypeScript in tooling/tests.
• What does Bun ship with? Runtime + bun package manager + bundler/transpiler + bun test.
• Where does Bun differ from Node? Different JS engine (JSC vs V8), different compatibility surface, lots of Node APIs are implemented but not always identical in edge cases.

Getting started commands

# create a project
bun init

# install deps
bun add <pkg>

# run a file
bun run index.ts

# run tests
bun test

Interview questions

1) Runtime & architecture

1. What is Bun, and what problems does it try to solve?
   Bun is a JS runtime + toolchain focused on fast startup, fast installs, and an integrated developer experience (runner, bundler, test runner).

2. Which JavaScript engine does Bun use and why does it matter?
   Bun uses JavaScriptCore (JSC). Engine choice can impact performance characteristics, available built-ins, and compatibility details compared to Node’s V8.

3. Is Bun “drop-in replacement” for Node.js?
   Not fully. Bun aims for high Node compatibility, but some Node APIs and edge behaviors may differ; you validate critical workloads and native addons.

4. How does Bun handle TypeScript? Do you need a separate build step?
   Bun can execute TypeScript directly (transpiling on the fly). For production you may still bundle/build depending on deployment needs.

5. When would you avoid Bun in production?
   When you rely on Node-only edge behaviors, niche/legacy Node APIs, specific native addons, or you need long-proven runtime stability guarantees.

2) Package manager & dependency resolution

6. What does bun install do differently from npm install?
   It focuses on speed with an optimized installer and lockfile. It also integrates tightly with Bun’s runtime and tooling.

7. What lockfile does Bun use?
   Bun uses bun.lockb (binary lockfile) to lock dependency resolution.

8. How do you add/remove dependencies?
   bun add pkg, bun remove pkg (and -d / --dev for dev deps).

9. How would you enforce deterministic installs in CI?
   Commit the lockfile and fail CI if it changes; use bun install with CI-friendly settings and avoid floating versions.

10. What are the practical risks of switching package managers on an existing project?
    Lockfile churn, subtle resolution differences, postinstall scripts, optionalDependencies behavior, and tooling assumptions.

3) Node.js compatibility & common APIs

11. Does Bun support require() and CommonJS?
    Bun supports many CommonJS patterns, but modern projects should prefer ESM when possible; verify any tricky interop modules.

12. How do ESM/CJS interop issues show up in Bun?
    Default import vs named import differences, __dirname/__filename expectations, and package exports resolution edge cases.

13. Does Bun implement Node’s fs, path, and http modules?
    Many Node built-ins are supported. For interviews, the key is: “mostly compatible, test edge cases.”

14. How do you read environment variables in Bun?
    process.env.MY_VAR (Node-compatible). Bun also offers Bun.env in some contexts; prefer process.env for portability.

15. How would you debug a Node script that behaves differently on Bun?
    Minimize reproduction, check Node API compatibility, confirm ESM/CJS boundaries, and compare engine-specific behavior; add tests.

4) Performance: startup, bundling, IO, memory

16. Why is Bun often faster for installs?
    It’s implemented with performance as a core goal and uses an optimized dependency installer and lockfile strategy.

17. Why can Bun have faster startup times?
    Design choices around the runtime, tooling integration, and engine characteristics can reduce overhead versus a multi-tool Node setup.

18. What would you measure to justify using Bun?
    Install time, cold start, request latency, CPU usage, memory footprint, and CI duration—measured on your workload.

19. How would you micro-benchmark fairly across Bun and Node?
    Same hardware, pinned versions, warmups, multiple runs, isolate IO, avoid JIT noise, compare p50/p95, and measure RSS/CPU.

5) Bun-specific APIs (know the highlights)

20. What is Bun.file() and when would you use it?
    A Bun API for working with files efficiently (often with streaming or easy conversion). Use when you want Bun-native file handling.

21. What is Bun.serve()?
    Bun’s built-in HTTP server API for quickly serving requests without extra frameworks.

22. How do you handle Web APIs in Bun (Fetch, Request/Response)?
    Bun supports many Web-standard APIs like fetch. Prefer Web APIs when you want runtime portability across Bun/Deno/Node (recent Node).

23. How do you read JSON quickly in Bun?
    Use standard JSON.parse on text; Bun also has optimized paths in some scenarios—main point: profile and don’t guess.

6) Testing with bun test

24. How do you run tests?
    bun test

25. How does bun test compare to Jest/Vitest?
    It’s built-in and fast. You evaluate ecosystem features you need (reporters, snapshots, mocks, watch mode) and migration cost.

26. How would you structure a Bun testing setup in a repo?
    Keep tests near code or in tests/, ensure deterministic fixtures, avoid environment coupling, and run in CI with pinned Bun version.

7) TypeScript & builds

27. Does Bun type-check TypeScript at runtime?
    Transpiling is not the same as type-checking. For strict type safety you still run tsc --noEmit (or similar) in CI.

28. When would you still need a bundler even with Bun?
    Browser targeting, tree-shaking requirements, asset pipelines, or when producing a single deployable artifact is needed.

29. How do you handle path aliases (like @/)?
    Configure tsconfig.json paths and ensure your runtime/bundler understands them; validate at build time and in tests.

8) Deployments & ops

30. How do you pin Bun in CI/production?
    Pin a Bun version (e.g., via your CI setup or container base image) to avoid unexpected runtime changes.

31. What should you validate before deploying a Node app on Bun?
    Integration tests, Node API usage audit, native addon compatibility, performance and memory profiling, and error/observability tooling.

32. What’s your rollback strategy?
    Keep Node as a fallback runtime, build artifacts compatible with both when possible, and roll out behind a canary/feature flag.

Suggested “deep dive” prompts for senior candidates

• Walk through migrating a medium Node service to Bun: risk assessment, compatibility testing, and rollout plan.
• Identify and fix an ESM/CJS edge-case bug across runtimes.
• Profile a slow endpoint and decide whether Bun materially helps.

Contributing

If you want, add more questions by topic or submit improvements to answers (keep them short and practical).