A team of five running four services wants to adopt Kubernetes. Do you support it?

What the interviewer is testing

Whether you can weigh operational complexity against team capacity, and whether you can say no constructively.

The concern

Kubernetes solves problems that appear at scale: many services, many teams, heterogeneous workloads, sophisticated scheduling and traffic management. For four services and five people, those problems do not exist yet.

What does appear immediately is the operational surface: cluster upgrades, node management, networking and its failure modes, RBAC, resource requests and limits, storage classes, ingress, certificate management, and a body of knowledge that takes months to acquire. For a team of five, that is a material fraction of total capacity, spent on infrastructure rather than product.

The questions that decide it

Is there a managed platform that removes most of it? A managed control plane with managed nodes, or a container platform that abstracts the cluster entirely, changes the calculation substantially.

Does the team already know it? If two of the five have run it in production, the learning cost is much lower and the answer may be yes.

Is there a specific requirement it uniquely satisfies — a workload needing sophisticated scheduling, a vendor product that only ships as a Helm chart, a compliance requirement met by an existing internal platform?

What is the growth trajectory? Four services and five people heading to thirty services and forty people is a different answer from a stable team.

The alternatives worth naming

A managed container service that runs containers without a cluster to operate. A platform-as-a-service. Serverless. All of these run containers, scale, and require a fraction of the operational knowledge.

The recommendation

Not yet, unless the team already has the expertise or the organisation is standardising on it with a platform team providing the cluster. Choose the simplest thing that runs containers, keep the workloads portable, and revisit when there is a specific need.

What a strong answer adds

Making it reversible: containerised workloads with infrastructure as code move to Kubernetes later without a rewrite. That reduces the stakes of the decision and is the more useful architectural contribution than the yes or no.

Common weak answers

Approving because it is the standard. Refusing on complexity without naming the alternatives.