How does tree shaking work and what breaks it?
Assesses fundamental understanding of Build Tools & Bundlers conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Tree shaking removes unused exports from the final bundle. It relies on ES modules being statically analysable: imports and exports are known at parse time, so the bundler can build a graph, mark reachable bindings, and drop the rest. It works best when modules are side-effect free, which is why package.json has "sideEffects": false or an array listing files that do have side effects. Without that hint the bundler keeps imports whose removal could change behaviour.
What breaks it: CommonJS require, because imports can be dynamic and conditional. Importing a namespace and accessing properties dynamically, such as import * as x and x[name]. Re-export barrels that pull in everything. Top-level code with side effects. Usage that cannot be statically traced.
Minifiers then remove dead code within a module, so production builds must be minified; unminified output often still contains unused code. Use named imports, avoid side effects at module scope, and inspect the bundle with rollup-plugin-visualizer or webpack-bundle-analyzer.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.