Most Docker interviews include a moment where the interviewer shares a Dockerfile and asks, “What would you change?” How you handle that reveals more than any definition you recite. So this guide starts there, then gives model answers to the conceptual questions that follow, and finishes with troubleshooting scenarios used to test experienced candidates. Facts come from Docker’s own documentation, checked in November 2026. All model answers are illustrative; put them in your own words.
The Dockerfile review
Here is an illustrative Dockerfile for a Node.js service. It works, but it has at least six problems.
FROM node:latest
COPY . /app
WORKDIR /app
RUN npm install
RUN apt-get update
RUN apt-get install -y curl vim git
EXPOSE 3000
CMD npm startA strong review, in roughly the order an interviewer would like to hear it:
- Unpinned, heavy base image.
latestcan change under you, and the full image is large. Docker’s best-practices guide advises choosing a trusted, minimal base, and points out that a tag can resolve to different content over time. Pin a specific version and consider a slim variant. - Cache-unfriendly order.
COPY . /appcomes beforenpm install, so any source change invalidates the dependency layer. Docker’s cache documentation says that once a layer changes, “all downstream layers need to be rebuilt as well”. Copypackage.jsonand the lock file first, install, then copy the rest. - No
.dockerignore. Without it,node_modules,.gitand local secrets may go into the build context. Docker recommends keeping the context small with a.dockerignorefile. - Split
apt-get updateandinstall. In separateRUNsteps, a cached update layer can be reused with a later install, which can give stale package lists. Combine them in oneRUNand clean up in the same step. - Unnecessary packages.
vimandgitdo not belong in a production image. The guide says not to install packages “just because they might be nice to have”. - Shell-form
CMD.CMD npm startruns under/bin/sh -c, so the shell becomes PID 1 and may not pass on stop signals. Use exec form, such asCMD ["node", "server.js"]. - Bonus: runs as root. Add a non-root
USERfor the runtime process.
An improved version, using a multi-stage build:
FROM node:22-slim AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
FROM node:22-slim
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]Say why: dependency installation is cached until the lock file changes; the final stage carries only what the app needs; and the process runs as an unprivileged user. Docker’s guide notes that multi-stage builds “let you reduce the size of your final image”. The version number here is an example; pin whatever your project supports.
Conceptual questions with model answers
What is the difference between an image and a container?
Model answer: “An image is a read-only template built in layers from a Dockerfile. A container is a running instance of an image with its own writable layer on top. I can start many containers from one image. Anything written to that writable layer disappears when the container is removed.”
The last sentence matters. Docker’s storage documentation states that data written to the container layer does not persist when the container is destroyed. Interviewers use it as a bridge to the next question.
Volumes, bind mounts and tmpfs: when do you use each?
| Type | What it is | Typical use |
|---|---|---|
| Volume | Storage managed by the Docker daemon; survives container removal | Database files, uploads, anything long-lived |
| Bind mount | A host path mapped into the container; both sides can change files | Local development with live code reload; sharing config from the host |
| tmpfs | Held in host memory, never written to disk; lost when the container stops | Temporary caches, sensitive data that should not touch disk |
The definitions match Docker’s storage page, which also notes that volumes are managed by Docker, while bind mounts depend on the host filesystem and are not isolated by Docker.
CMD versus ENTRYPOINT
Model answer: “ENTRYPOINT sets the executable; CMD sets the default command or default arguments. Arguments passed to docker run replace CMD but are appended to ENTRYPOINT. If I want the image to always run one program and let users change its flags, I set ENTRYPOINT in exec form and put default flags in CMD. You can still override the entrypoint with --entrypoint.”
This matches Docker’s own explanation, including its example: with ENTRYPOINT ["python", "/app/my_script.py"] and CMD ["--default-arg"], running the image with --user-arg executes the script with --user-arg instead of the default.
Follow-up: “Why exec form?” Because in shell form /bin/sh -c becomes PID 1, and Docker notes it does not handle signals properly, which can mean unclean shutdowns. In exec form your process is PID 1 and receives SIGTERM directly.
How does the build cache work?
Model answer: “Each instruction produces a layer. If an instruction or its inputs have not changed, Docker reuses the cached layer. Once one layer changes, every layer after it is rebuilt. So I put things that change rarely, like dependency installation, near the top, and things that change often, like application source, near the bottom.”
Docker’s optimisation guide says steps that change often should appear near the end of the Dockerfile. Experienced candidates can add cache mounts, which keep a package manager’s cache between builds so a rebuilt layer only downloads new or changed packages, and external caches for CI pipelines.
How do containers in Compose talk to each other?
Model answer: “Compose creates a default network for the project and attaches every service. Each service registers its name with internal DNS, so the web service reaches the database at db:5432. Service-to-service traffic uses the container port; the host port mapping only matters from outside.”
Docker’s Compose networking page gives the same example: a database published as 8001:5432 is reached by other containers on 5432 and by the host on 8001. Candidates often get this backwards.
Does EXPOSE publish a port?
No. It documents which port the application listens on. You publish with -p on docker run or ports in Compose. This is a quick check of whether you have actually run containers.
How do you make containers more secure?
Give layered answers: minimal, trusted base images; rebuilding regularly to pick up patches (Docker suggests --pull to fetch an updated base image); no secrets baked into layers; running as a non-root user; dropping capabilities you do not need; and scanning images in CI. For the host, mention rootless mode, which Docker describes as running “the Docker daemon and containers as a non-root user” to reduce the impact of vulnerabilities in the daemon and runtime.
Should a container run one process?
Docker’s guide says each container should have one concern, and adds that one process per container is “not a hard and fast rule”. A balanced answer: separate concerns so they scale and restart independently, but a supervisor plus worker in one container can be acceptable when they are tightly coupled.
Troubleshooting scenarios
Experienced candidates are usually given a symptom and asked how they would investigate. Show the order you would check things.
| Symptom | First checks | Likely causes |
|---|---|---|
| Container exits immediately | docker logs, docker inspect for the exit code |
Main process finished or crashed; wrong CMD; missing environment variable |
| App works locally, not in the container | Listening address and port inside the container | Binding to 127.0.0.1 instead of 0.0.0.0; port not published |
| Web container cannot reach database | Both on the same network; hostname used | Using localhost instead of the service name; using the host port instead of the container port |
| Data lost after redeploy | Where the data is written | Writing to the container layer rather than a volume |
| Builds are slow in CI | Which step invalidates the cache | Source copied before dependency install; large context; no shared cache between runners |
| Container takes ten seconds to stop | How the process is started | Shell-form CMD, so the app never receives SIGTERM and is killed after the timeout |
Freshers and experienced candidates: what to prepare
If you are new to Docker, be fluent in the basic loop: write a Dockerfile, docker build, docker run with a published port and a volume, read logs, and run a two-service Compose file. Expect the image-versus-container, volume and EXPOSE questions.
If you are experienced, expect the Dockerfile review, multi-stage builds, caching in CI, image size and security, signal handling, and at least one troubleshooting scenario. Have a story about an image you made smaller or a build you made faster, with before-and-after numbers from your own work.
Your CV should make the interviewer want to ask about that story. List the stack, the pipeline and the result, not just “Docker” in a skills box. The software engineer resume builder has space for projects and tooling, and the resume templates include plain layouts that parse cleanly in applicant tracking systems.
Frequently asked questions
Do Docker interviews include Kubernetes?
Often, for DevOps and platform roles, because Docker builds the images that Kubernetes runs. For developer roles, Docker and Compose are usually enough. Check the job description.
What should a fresher know about Docker?
Images versus containers, writing a simple Dockerfile, building and running it, publishing ports, mounting a volume, and running two services with Compose. Be able to explain each command you type.
Is Docker Desktop the same as Docker Engine?
No. Docker Engine is the daemon and runtime; Docker Desktop is an application for Mac, Windows and Linux desktops that bundles the engine with tools and a user interface. Interview questions are usually about the engine and Dockerfiles.
Sources
- Building best practices (Docker Docs)
- Docker Best Practices: Choosing Between RUN, CMD, and ENTRYPOINT (Docker blog)
- Docker build cache (Docker Docs)
- Optimize cache usage in builds (Docker Docs)
- Storage (Docker Docs)
- Networking in Compose (Docker Docs)
- Rootless mode (Docker Docs)