Lesson 15 · Senior containers & local dev

Mock senior containers/local-dev interview pack

A retrieval-first practice pack for turning the whole containers/local-dev course into answers you can say cleanly under pressure.

Your win: run a realistic senior containers/local-dev mock interview on yourself, score the answers honestly, and turn weak spots into a concrete revision plan.

In plain English Plain English: answer out loud before checking the answer points. The goal is retrieval and structure, not passive rereading.

How to get the most out of this page

This page works best if you treat it like a real interview. Answer first. Then check the points. Then answer again more cleanly.

The trap is to read the answer points and feel fluent. Don’t do that. The value comes from trying to retrieve the answer before you look.

Round 1 · Core container foundations — 5 questions
Round 2 · Workflow design and trade-offs — 6 questions
Round 3 · Repo-grounded local-stack reasoning — 6 questions
Time target — 60–90 seconds per answer

The answer checklist A strong answer should usually include: (1) the mental model, (2) the key trade-off, and (3) a real repo-grounded consequence or example. If one of those three pieces is missing, the answer usually sounds thinner than you think.

Round 1 · Core container foundations

These questions test whether the container basics really belong to you, not just whether they still look familiar on the page.

What is a container, and how is it different from a VM?
What is the difference between an image and a container?
Why does layer order matter in a Dockerfile?
What is a multi-stage build for?
What is the difference between a named volume and a bind mount?

Round 1 · Strong answer points

Container vs VM. A container is an isolated process sharing the host kernel via namespaces and cgroups; a VM has its own guest OS and kernel through a hypervisor.
Image vs container. An image is the read-only template; a container is a running instance with a writable layer on top.
Layer order. Docker caches top-down, so a changed early layer invalidates later ones and slows rebuilds.
Multi-stage build. Build with heavy tooling, ship only the runtime artifacts you need.
Named vs bind. Named volumes are Docker-managed persistent data; bind mounts are host paths, usually for config or editable code.

Round 2 · Workflow design and trade-offs

This is where the mock becomes more senior. The question is not only what the tool does, but why the workflow is shaped this way.

Why does this repo use one image for many backend services?
Why not rebuild the image on every code change?
What problem does wait-for-it-service solve?
When is Compose the better local stack?
When is kind+Skaffold the better local stack?
What makes a good readiness signal?

Round 2 · Strong answer points

One image, many services. The repo compiles one build/server binary and selects behavior with command args and mounted config, which keeps the image strategy simpler.
No rebuild every edit. Normal service edits often only change the binary, so host-compile plus docker cp gives much faster feedback than full image rebuilds.
wait-for-it-service. It prevents application services from racing ahead before DB and other key infra are actually ready.
Compose better. Use it for day-to-day service work when the question is mainly process behavior and dependency wiring.
kind better. Use it when Kubernetes, rendered manifests, or cluster-level behavior is part of what you are validating.
Good readiness signal. It should represent a real usable state, not just a process that happens to be alive.

Round 3 · Repo-grounded local-stack reasoning

This round is what turns the mock from generic Docker knowledge into repo-specific engineering judgment.

What are the important stages in Dockerfile.development, and why do they exist?
Why does run.bash hot-swap the binary?
What is the relationship between the compose stack and sk.bash -- render?
How would you debug a service that still behaves like old code after a local restart?
What is the practical difference between -m debug and the normal path?
How would you explain this course’s local-dev model honestly in a senior interview?

Round 3 · Strong answer points

Dockerfile stages. no-op supports modd-based hot-swap, developer is the normal runtime image, and developer-debug adds Delve for debug sessions.
Hot-swap. It keeps the inner loop fast by replacing only the binary layer of reality that changed during normal service development.
Compose + render relationship. run.bash shells out to sk.bash -- render, so the compose configs are rendered from the Helm/Skaffold side rather than maintained as separate truth.
Old-code debug path. Check whether the binary was rebuilt, whether docker cp landed in the right container, and whether the reload or restart path actually picked it up.
-m debug. It starts the service under Delve on port 40000 rather than the normal hot-swap-only execution path.
Senior explanation. Describe the local model as a pragmatic two-stack workflow: fast Compose for inner-loop service work, kind+Skaffold for higher-fidelity cluster behavior, with shared configuration truth and hot-swap optimization.

Self-scoring rubric

Score	Meaning
0	I could not explain it without notes.
1	I gave fragments, but the answer was incomplete or fuzzy.
2	I explained the main idea, but missed the trade-off or repo-grounded consequence.
3	I gave a strong, clear answer with model + trade-off + repo consequence.

Recovery map — where to go next Missed container basics? Revisit Lessons 1–4. Missed repo local-stack structure? Revisit Lessons 5–8. Missed workflow and debugging judgment? Revisit Lessons 9–13. The point is not to reread the whole course; it is to go back to the exact weak seam.

Q1. The main rule of this mock pack is…

Retrieval first is what turns recognition into durable interview recall.

What are the three ingredients of a strong senior containers/local-dev answer?

recall, then click to reveal

A clear mental model, the important trade-off, and a repo-grounded consequence or example.

If you want, I can now run this as a live mock senior containers/local-dev interview and grade you answer by answer. Ask me.

Sources. This pack synthesizes the whole course into retrieval practice.