Docker Compose - Multi-Container Apps Made Easy

Running containers one by one with a pile of docker run commands doesn't scale past a weekend project, and interviewers know it. This question checks whether you reach for the right tool when an app has more than one moving part, like a database, an API, and a cache that all need to start and talk to each other.

The answer interviewers want

For multi-container applications, the standard tool is Docker Compose. Instead of starting each container manually, you define your entire stack in one YAML file: services, networks, volumes, environment variables, all in one place.

You bring the whole stack up with a single command:

docker-compose up

Every service defined in the file starts together, and Compose wires them onto a shared network so they can talk to each other by service name. No more juggling individual docker run commands or remembering which flags each container needs.

One detail worth calling out: use depends_on to control startup order. If your API needs the database to be up first, you declare that dependency in the YAML so Compose starts the database before the API, instead of both racing to start at once.

Why interviewers ask this

They want to know you understand that container orchestration starts with the basics before you ever get to Kubernetes. Can you describe a whole application stack declaratively instead of running ad hoc commands? Mentioning depends_on specifically shows you've actually hit the startup-ordering problem, not just read the Compose docs once.

Follow-ups to expect

What happens if a dependent service isn't actually ready when the container starts, even with depends_on? depends_on controls container start order, not application readiness, so a database container can be "up" before the database process inside it can accept connections; many teams add retry logic or a readiness check in the dependent service to handle that gap.

How do services in the same Compose file find each other? They communicate over the shared network Compose creates, addressing each other by the service name defined in the YAML file rather than by IP address.

How would you move from Compose to something like Kubernetes? The same mental model applies, declaring your stack rather than issuing one-off commands, but Compose is aimed at single-host development and testing setups, while Kubernetes adds scheduling, scaling, and multi-host orchestration on top of that idea.

The common wrong answer

A lot of candidates say "I'd just write a script that runs several docker run commands in sequence," which technically starts multiple containers but misses the point entirely. It doesn't give you a single declarative definition of the stack, it doesn't handle networking between containers automatically, and it has no concept of dependency ordering, so you end up reinventing Compose badly with shell scripts.