How do you approach reducing a bloated Docker image and its build time for a legacy application?

This is a practical, judgment-oriented question. It tests whether a candidate optimizes methodically — measuring, prioritizing, validating — rather than applying every known trick at once and hoping nothing breaks.

Step 1: measure before changing anything

docker history myapp:legacy --no-trunc
docker images myapp:legacy
time docker build -t myapp:legacy .    # establish a baseline build time

docker history shows exactly which layers contribute the most to the image's total size. This often surfaces a surprise — an accidentally-included large dependency cache, a full package manager index left behind, an unnecessarily broad COPY — that's a much bigger win to fix first than anything more subtle. Don't start optimizing based on assumption; the biggest contributor is often not what you'd guess.

Step 2: apply changes roughly in order of expected impact, validating each independently

1. Multi-stage build, if the application has any build/compile step — often the single biggest win, since it can eliminate entire build-toolchain layers from the final image.
2. Base image swap, from a full image to a slim one, or to Alpine if compatible — a real, meaningful size reduction, but requires actually testing that the application still works afterward.
3. Dockerfile instruction reordering for cache efficiency doesn't shrink the final image, but dramatically speeds up iterative rebuilds. This matters a lot for day-to-day developer and CI velocity, even if shipped image size is unchanged.
4. .dockerignore tightening — often a quick, low-risk win, especially for legacy projects that never had one properly maintained and are likely copying in unnecessary files: old build artifacts, version control history, documentation.

The specific risk with legacy applications: hidden runtime assumptions

FROM node:20-alpine    # switching to alpine...

Error: Cannot find module 'some-native-dependency'
# (a native/compiled dependency built against glibc, incompatible with Alpine's musl libc)

A legacy application, especially one running unchanged for a long time, sometimes has hidden dependencies on specifics of its original base image that aren't obvious from reading the Dockerfile alone. Examples: a native compiled dependency assuming glibc, which breaks under Alpine's musl; a script assuming a specific shell or utility's behavior that differs between distributions; file paths and permissions the application implicitly relies on. This is exactly why each change should be validated independently, with the application's actual test suite and ideally a staging or canary deployment, before moving to the next optimization. Bundling several changes together, then discovering something broke, makes it much harder to identify which change caused the regression.

Communicating the plan and tradeoffs to a team

A strong approach also frames this work for stakeholders: here's the current baseline (image size and build time), here's the expected improvement from each change, here's the validation plan for each, and here's the rollback plan if something regresses. This treats image/build optimization as deliberate, measured engineering work with a clear before/after story — not just "I made the Dockerfile better" with no evidence.

Reporting the outcome with real numbers

"We reduced the image from 1.2GB to 180MB, mostly via a multi-stage build eliminating the build toolchain, and cut typical incremental rebuild time from 90 seconds to 4 seconds by reordering dependency installation ahead of application code copying. This was validated against the full regression suite and a week of staging traffic before rolling out to production." Concrete numbers make this kind of answer far more convincing than a vague "we made it smaller and faster." They also show the same measure-first discipline that matters most, since legacy applications hide more unstated assumptions than a project built with today's best practices from scratch.