Docker questions in a backend interview aren't really about Docker syntax. They're about whether you understand image layering, why image size matters in production, and how to wire a multi-service local environment together. This lesson covers layer caching, a real multi-stage Dockerfile for a Python app, COPY versus ADD, shrinking an image, networking and volumes, and a docker-compose file wiring an app, a database, and Redis together.

Images are layers, and layers are cached

Every instruction in a Dockerfile, RUN, COPY, ADD, creates a new, immutable layer stacked on the one before it. Docker caches each layer by the hash of its inputs: if a layer's inputs haven't changed, Docker reuses the cached layer instead of re-running the instruction. This is the entire reason instruction order matters:

Copy the files that change the least often first. In the bad version, editing a single line of application code invalidates the cache for the pip install layer too, since Docker sees COPY . . as changed and everything after it as no longer trustworthy. In the good version, requirements.txt only changes when a dependency actually changes, so the expensive install step stays cached across ordinary code edits. "How would you speed up this Dockerfile" is close to a guaranteed question, and this ordering trick is the answer almost every time.

Remember: copy your least-frequently-changing files first. A source code change should never force a dependency reinstall.

A multi-stage build for a Python app

The compiler toolchain (build-essential, the -dev headers) needed to build psycopg2 or cryptography from source lives only in the builder stage. The final runtime image copies just the compiled .local package directory: not gcc, not the headers, not the apt cache. This is the mechanism behind "how do you reduce image size": a multi-stage build lets you use a full build environment during the build without shipping any of it in the final image.

Remember: the build toolchain lives only in the builder stage. The runtime stage copies the compiled result, not the compiler that produced it.

COPY vs ADD

COPY copies files or directories from the build context into the image, literally, nothing more. ADD does everything COPY does, plus two extra tricks: it can fetch a remote URL as a source, and it auto-extracts local tar archives into the destination. That extra behavior is exactly why ADD is generally discouraged: the implicit auto-extraction and remote-fetch behavior are easy to trigger by accident, and make a build step non-obvious just from reading the Dockerfile.

The rule to state in an interview: use COPY unless you specifically need tar auto-extraction, and never use ADD for a remote URL. An explicit RUN curl/wget makes the fetch and its error handling visible in the Dockerfile itself.

Remember: COPY is explicit and predictable. ADD hides two extra behaviors (remote fetch, auto-extract) inside one instruction, which is exactly why it's the one to avoid by default.

Reducing image size: the full checklist

• Multi-stage builds, above: the single biggest lever.
• python:3.12-slim or -alpine instead of the full python:3.12 image, a difference of hundreds of megabytes. Alpine uses musl libc instead of glibc, which occasionally breaks binary wheels that expect glibc, so slim (Debian-based) is the safer default for Python.
• --no-cache-dir on pip install: pip caches downloaded wheels by default, which is dead weight in an image that's built once and never reused for incremental installs.
• rm -rf /var/lib/apt/lists/* right after any apt-get install, in the same RUN layer. A separate RUN rm in a later instruction doesn't shrink the earlier layer, since layers are immutable once committed.
• A .dockerignore excluding .git, __pycache__, .venv, test fixtures, and local env files. This keeps the build context small and stops secrets or dev artifacts from accidentally getting baked into a layer.

Remember: rm -rf /var/lib/apt/lists/* only shrinks the image if it runs in the same RUN layer as the apt-get install it's cleaning up after. A later, separate RUN can't undo an earlier committed layer.

Docker networking and volumes

Networking. Containers on the same user-defined bridge network, which docker-compose creates automatically per project, can reach each other by service name as a DNS hostname: db, redis, web resolve automatically, with no manual IP wiring needed. Containers stay isolated from the host and from other Docker networks by default; you explicitly EXPOSE/publish (-p) only the ports that actually need host access.

Volumes. A named volume (docker volume create, or declared in compose) persists data outside any single container's writable layer. This matters for a database container specifically, since the container's own filesystem is ephemeral and gets destroyed on docker rm. A bind mount (./src:/app/src) maps a host directory directly into the container, mainly used for local dev hot-reload. Avoid bind-mounting source code in production images; production images should be immutable, self-contained builds.

Remember: service names resolve automatically as DNS hostnames on a compose network. A named volume survives docker rm; the container's own writable layer does not.

docker-compose: app, database, and Redis together

depends_on with condition: service_healthy, not plain depends_on, is what prevents the classic "web container crashes on startup because Postgres isn't ready yet" race. Plain depends_on only guarantees start order, not readiness order, and a database container is considered "started" well before it's actually accepting connections. The healthcheck block is what makes service_healthy mean something concrete: without it, there's nothing for condition: service_healthy to check.

Remember: plain depends_on waits for a container to start, not to be ready. condition: service_healthy waits for the healthcheck to pass, which is what actually prevents the startup race.