intermediateDebug Info
Your stack trace points at line 1, column 84210 of a bundle. What has to exist for a debugger to show you the original source, and why does it so often get it slightly wrong?
Whether the candidate understands debug information as a separate artifact with its own correctness problem, and knows that every transformation in the chain has to maintain it or the mapping degrades.
What a strong answer covers
- A mapping from output positions back to input positions has to be produced by every tool that transformed the code, and composed across the chain. A source map is one encoding of that — a table from generated line and column to original file, line, column and optionally the original name — and native toolchains do the same job with DWARF line tables and location lists.
- It goes wrong because the map is only as good as its weakest producer. A chain of transpile, then bundle, then minify has three producers, and each must consume the previous map and emit a composed one. A tool that emits positions relative to its own input instead of composing produces a map that is plausibly close and consistently off, which is the off-by-a-few-lines experience everyone recognises. A tool that emits no map at all silently truncates the chain.
- Even a perfect map runs into the fact that optimized code has no single origin. After inlining, one instruction belongs to two source functions. After a merge of identical tails, one instruction belongs to several lines. After scalar replacement, a variable may exist in three registers at different times, or nowhere, which is what "optimized out" means in a debugger — the variable is not lost, it never had a single location.
- The practical consequences: keep the maps out of the shipped bundle and symbolicate server-side, treat map generation as part of the build rather than an option, verify the mapping in CI by throwing a known error and checking the resolved frame, and remember that names come from a separate table — a mangled or minified name will still be mangled unless the map carries the original.
✓ Green flags
- Says composition across the tool chain explicitly, and identifies it as where breakage comes from.
- Knows the map is a separate artifact with its own deployment and privacy question.
- Explains "optimized out" correctly — no single location rather than deleted.
- Draws the parallel to DWARF line tables and location lists.
- Suggests verifying the mapping automatically rather than by eye.
✗ Red flags
- "Just disable minification in production." That changes the artifact you are debugging, so it no longer reproduces what your users run.
- "Source maps make the code slower." They are a separate file that is not loaded unless a debugger asks for it.
- "Debug info is generated by the debugger." It is emitted by the compiler and bundler; the debugger only consumes it.
- "-g slows the program down." It adds sections to the binary and does not by itself change code generation, which is exactly why you can ship optimized builds with debug info and strip it separately.
Follow-up
How would you check in CI that your source maps are correct, rather than merely present?
Implementation challenge
What to ask them to write or trace on a whiteboard.
Two tools in sequence, each with its own map. Write down what the composed map must contain for one position, and what a tool that skips composition produces instead.