Diff the bundle rather than guessing. Run a bundle analyzer on the commit before and after, and look for a new dependency, a duplicated version of an existing one, or a barrel import pulling in a whole library. Fix with a lighter dependency, deep imports, or a dynamic import if the code is not needed on first paint. Then add a size budget in CI so it cannot happen silently again.
Why interviewers ask this
The interviewer wants a debugging process, not a list of optimization tips. They are checking that you know how to attribute size to a specific module, that you can name the common causes such as duplicate transitive versions and side effectful barrel files, and crucially that you close the loop with automation. Ending at a CI budget is what separates a fix from a habit.
How to structure your answer
- Measure and diff the two builds before proposing anything.
- Name the likely causes in order and how you confirm each.
- Give the fix that matches the cause, not a generic one.
- Add a CI size budget so regressions get caught at review time.
Example answer
First I get the facts. I build the previous commit and the current one and run an analyzer over both, so I can point at the exact module that grew rather than arguing about it. Usually it is one of three things. Someone added a heavy dependency for one function, a date or utility library being the classic. Or we now ship two versions of the same package because a transitive dependency pinned a different one, which the analyzer shows as duplicated chunks. Or an index file re-exports everything and tree shaking gave up because the package is not marked side effect free. The fix follows the cause: swap in a lighter dependency or the platform equivalent, dedupe the version, or import the specific module path. If the code is genuinely needed but not on first paint, like a rich text editor or a charting library, it becomes a dynamic import behind the interaction that needs it. Then I add a size budget to CI that fails the pull request on a jump like this, because otherwise it just happens again next quarter.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How would you find out which dependency pulled in the duplicate version?
- Where would you set the size budget threshold and for which entry points?
- How does code splitting interact with your caching strategy?
Related react developer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions