Walk me through essential Dockerfile commands for a reproducible Python ML environment

WHAT THIS TESTS: The interviewer wants to know if you understand Docker image layering, build cache optimization, and reproducibility for Python data science workflows. They care less about memorizing every Dockerfile keyword and more about whether you can sequence commands to minimize image size, avoid unnecessary rebuilds, and pin dependencies so the container behaves identically across laptops and CI servers.

A GOOD ANSWER COVERS: First, choose a pinned base image such as FROM python:3.11-slim rather than latest so the Python version does not drift. Second, set WORKDIR to a clean path like /app so all subsequent commands operate from a known location. Third, copy only the requirements file before the source code with COPY requirements.txt . so that Docker caches the dependency layer until the requirements change. Fourth, install dependencies with RUN pip install --no-cache-dir -r requirements.txt to keep the layer small and use pinned versions in requirements.txt. Fifth, copy the actual application code with COPY . . and finish with CMD python train.py or an ENTRYPOINT. Mentioning that scikit-learn and pandas often compile C extensions is a bonus, which is why the slim image and pinned versions matter for reproducibility.

COMMON WRONG ANSWERS: A major red flag is using FROM python:latest which breaks reproducibility the moment the upstream image updates. Another is copying all files in one step before installing dependencies, which invalidates the cache on every code change and forces slow reinstalls. Installing packages directly in RUN pip install scikit-learn pandas without a requirements.txt also signals poor dependency hygiene. Running everything as root without mentioning a non-root USER is acceptable at beginner level but forgetting WORKDIR and dumping files into the root filesystem looks sloppy. Using ADD instead of COPY for local files is another subtle mistake because ADD has hidden tar extraction and remote URL behaviors that are unnecessary here.

LIKELY FOLLOW-UPS: The interviewer may ask how you would reduce image size further, which leads to multi-stage builds or distroless images. They might ask how to pass environment variables or secrets during build without baking them into layers, which touches on BuildKit secrets or runtime env vars. Another follow-up is how to handle data volumes or model artifacts, where you should recommend bind mounts at runtime rather than COPY for large datasets. They could also ask about GPU support, which would require the NVIDIA runtime and a CUDA-enabled base image instead of slim.

ONE CONCRETE EXAMPLE: A solid Dockerfile for a scikit-learn training script looks like this in conversation. Start with FROM python:3.11-slim. Then WORKDIR /app. Then COPY requirements.txt . followed by RUN pip install --no-cache-dir -r requirements.txt. Then COPY . . and finally CMD python train.py. If requirements.txt pins scikit-learn==1.3.2 and pandas==2.0.3, the build is reproducible and the layer cache skips pip install until those versions change. The image stays near 150 MB for the slim base plus roughly 200 to 300 MB for the ML libraries, which is reasonable for a beginner-level container.