25 Docker Interview Questions & Container Best Practices

Docker interviews are refreshingly concrete. There's no ambiguity about what they want: can you containerise an application well, keep the image small and secure, and debug when the container won't start or can't talk to anything? It's a craft interview, and craft shows.

The key idea: An image is a layered, immutable filesystem plus metadata; a container is a running process isolated by namespaces and cgroups. Once that clicks, "why is my image 1.4 GB?" and "why did my data vanish?" stop being mysteries.

The question taxonomy

• Fundamentals. Image vs container, layers and caching, containers vs VMs.
• Dockerfile craft. Layer ordering, multi-stage builds, .dockerignore, choosing base images.
• Runtime. Volumes vs bind mounts, port publishing, environment variables, restart policies.
• Networking. Bridge networks, container-to-container DNS, why localhost doesn't mean what you think.
• Compose and debugging. Multi-service setups, logs, exec, inspecting layers.

Worked example: the multi-stage build question

"My Node image is over a gigabyte. Fix it." This is a gift of a question — show the before and after:

# Stage 1: build
FROM node:20-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Stage 2: runtime — only what production needs
FROM node:20-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER node
CMD ["node", "dist/server.js"]

Then narrate the wins: the build toolchain never ships to production, the alpine base is small, npm ci gives reproducible installs, layers are ordered so dependency installation caches independently of source changes, and the app doesn't run as root. Each point is a checkbox on the rubric — say them all.

How answers get scored

Interviewers reward operational realism: you know why containers shouldn't run as root, you understand that docker compose is for development and simple deployments rather than a production orchestrator, and you can explain why a process in a container can't reach another container's "localhost." Debugging fluency — docker logs, docker exec -it, docker inspect — matters more than memorised flags.

Common mistakes

• COPY . . before installing dependencies — every source change busts the entire cache. Copy manifests first.
• Storing data inside the container and losing it on recreate. Use a volume.
• Baking secrets into the image. They're visible in docker history to anyone who pulls it.
• Running one container per concern badly — e.g., baking nginx and the app and the database into a single image.

The scenario round: "it works on my machine"

Every Docker loop includes a debugging scenario. The classics: a container that exits immediately (check logs; the entrypoint crashed or the command finished — containers live as long as their main process), a service that can't reach its database (they're on different networks; use a shared user-defined bridge and the service name as hostname), and a build that's mysteriously slow (the context is huge — add a .dockerignore for node_modules and .git). Notice the pattern: each answer starts with observing — logs, inspect, events — before changing anything. That order of operations is the rubric. Candidates who immediately start rewriting the Dockerfile read as guessing; candidates who say "first I'd look at the logs and the exit code" read as operators. Practise these scenarios in a real terminal, not in your head, so the commands come out of your fingers automatically.

FAQ

How is this different from Kubernetes questions? Docker is the build-and-run-one-container layer; Kubernetes orchestrates many containers across hosts. Most roles want both — see the Kubernetes guide for the orchestration half.

Do I need to know containerd or runc? Only conceptually — Docker sits on top of them. Deep runtime internals are platform-team territory.

Connect this to CI/CD and infrastructure in the DevOps engineer guide, and get live feedback on your Dockerfiles with Aissence's coding copilot.