Lesson 14 · Senior containers & local dev
Senior containers/local-dev interview questions
High-signal questions about container workflow design, readiness, fidelity, and local debugging — with answer shapes that sound like real engineering judgment.
Your win: answer senior local-dev and container questions with repo-grounded trade-off reasoning instead of generic Docker trivia.
Why these questions feel different
At a senior level, the question is usually not “what is a container?” It is “why did your team choose this image strategy?”, “why two local stacks?”, or “how do you keep inner loops fast without lying to yourself about runtime reality?”
That is why generic Docker vocabulary stops being enough. The stronger answer connects the tool, the trade-off, and the local workflow design choice.
Question bank
| Question | Best answer shape |
|---|---|
| Why is a container not just a small VM? | Because it is an isolated process sharing the host kernel through namespaces and cgroups, so it trades stronger isolation for speed and density. |
| Why does layer order matter in a Dockerfile? | Because the cache is reused top-down, so changing an early layer forces everything below it to rebuild. |
| Why use one image for many backend services? | Because the repo compiles one build/server binary and selects service behavior at runtime with command args and mounted config. |
| Why not rebuild the image on every code change? | Because normal service edits often only change the binary, so hot-swap is cheaper while still faithful enough for that layer of change. |
What problem does wait-for-it-service solve? | It centralizes infra readiness gating so services do not crash just because dependencies started before they were actually ready. |
| Why both Compose and kind+Skaffold? | Compose is the fast process loop; kind+Skaffold is the higher-fidelity Kubernetes loop when cluster behavior matters. |
| What makes a readiness check good? | It corresponds to a real usable state and a known failure you want to prevent, not just a process being alive. |
| How do you debug a local service systematically? | Walk the path: image/runtime, config/mounts, dependency readiness, command/entrypoint, then restart or reload path. |
| What is the difference between hot-swap and redeploy? | Hot-swap changes the running container’s binary fast; redeploy re-evaluates more of the runtime stack and is needed when deeper layers changed. |
| What does this local stack teach about the wider deployment system? | That local config truth, image design, and runtime choices are already introducing the same structural ideas you later see in Helm and Kubernetes. |
Dockerfile.development stages, docker cp hot-swap, wait-for-it-service, sk.bash -- render, and “compose for speed, kind for fidelity.”
Use the local canon and the tool docs together
Great answers here come from Docker/Compose/kind/Skaffold docs plus the repo’s own local-runtime files. That combination is what makes the answer sound lived-in instead of memorized.
Check yourself (from memory)
Q1. A strong senior local-dev answer usually includes…
Sources. Repo playbook and resources.