Why avoid global Python dependencies for ML, and how do containers help?

WHAT THIS TESTS: This question probes whether you understand the difference between language-level isolation and full system-level isolation in machine learning workflows. Interviewers want to see that you recognize why virtualenv alone is insufficient for production ML and that you can articulate the specific reproducibility and portability problems containers address.

A GOOD ANSWER COVERS: First, global installations create diamond dependency conflicts where one project requires NumPy 1.24 and another requires NumPy 1.26, leading to broken environments. Second, host machines accumulate stale system libraries and compiler toolchains over time, so a pip install that succeeds on your laptop may fail on a colleague's machine or in CI because of missing libgomp or BLAS versions. Third, ML workflows often depend on specific CUDA, cuDNN, and Python interpreter versions that are painful to swap on a shared host. Fourth, containerization solves this by bundling the operating system, system libraries, Python runtime, and pip dependencies into an immutable image, turning environment setup into a single deterministic build step rather than a snowflake configuration script.

COMMON WRONG ANSWERS: Treating Docker as just a heavyweight virtualenv replacement without mentioning system library isolation or immutability. Claiming containers solve everything while ignoring that the host kernel and GPU drivers must still be compatible with the container's CUDA expectations. Suggesting that pip install user is a sufficient fix, which ignores system dependency drift. Failing to mention reproducibility or deployment parity between training and serving environments.

LIKELY FOLLOW-UPS: How would you handle a scenario where your container image is ten gigabytes because of heavy ML base images? When would you prefer conda over pip inside a container? How do you manage secrets and data volume mounts without baking them into the image? What is your strategy for multi-stage builds to keep production images small?

ONE CONCRETE EXAMPLE: Imagine you are training a transformer model that requires PyTorch 2.1 with CUDA 11.8, while your legacy segmentation service needs PyTorch 1.13 with CUDA 11.3. Installing both globally on the same workstation is nearly impossible without constant environment switching. By building two separate Docker images, each pins the exact NVIDIA base image, the correct Python version, and a locked requirements file. When a new team member pulls the repo, docker build produces an identical environment to yours, and when Kubernetes schedules the training pod, the node only needs the matching NVIDIA driver while the container brings its own CUDA toolkit.