What job interviews taught me about Kubernetes
What job interviews taught me about Kubernetes
Published on 15 June 2026
So I've been job hunting lately. Reading job postings, doing interviews,<br>talking to engineering teams at like a dozen companies. And I noticed<br>something compared to five years ago when I was last doing this: literally<br>everyone is on Kubernetes now. Every single company I talked to.
Last time I was job hunting that wasn't the case at all. There were<br>basically three camps: the rare Kubernetes adopters, the systemd-on-VM/VPS/EC2 crowd, and the serverless people (Lambda,<br>Cloud Run, etc.).
That surprised me, because where I work we have actual Big Tech-scale<br>problems, so K8s makes obvious sense for us. But a 10-person startup with<br>two services? None of these places were doing microservices or anything<br>close to high scale. So I asked why.
Spoiler: they don't care much about the technical side of<br>K8s.
Why?
A technical interview is actually a great place to ask why, especially<br>when you're talking directly to the CTO. So I did. The answers were<br>basically the same everywhere.
Uniformity
First one was uniformity . Every service deploys the same way. No<br>one secretly knowing that the payments service runs on some bare VM with a<br>cursed bash script from 2019 while the API is on Docker Compose because<br>nobody ever touched it. One way to deploy, for everything.
Standardized knowledge
Second was shared, hireable knowledge . K8s is basically a lingua<br>franca now. My first day at my current job, I pulled up the repo with the<br>Helm charts and Kube configs and had a solid picture of the whole<br>architecture within an hour. The knowledge is in the YAML, not stuck in<br>someone's head. Lose someone, their replacement isn't spending three weeks<br>digging through docs trying to figure out how anything runs.
At my current company, on-call SREs can keep any service up even if<br>they've never touched it before. They know Kubernetes, and Kubernetes<br>patterns are the same everywhere for all teams. Try doing that with a<br>bunch of VMs where every service is set up differently. (Caveat: this only<br>holds if nobody went exotic with the setup, of course.)
Tracing who does what
Third was traceability (with or without compliance). At my current<br>company, nobody can just kubectl apply -f something straight<br>to the cluster. You push a Helm chart to git, there's a trace, there's an<br>MR approval process, then FluxCD or ArgoCD handles the actual deployment.<br>Nothing happens in the shadow. That composes really well with compliance:<br>it's basically how we ace ISO certifications. And since GitOps pairs<br>naturally with Kubernetes, you get all of that almost for free.
What I took from it
The CTOs I talked to aren't making a dumb choice. They're solving real<br>problems.
I was focused on the technical side only, and Kube always has been a<br>technical solution to technical problems, for me. But it looks like a lot<br>of CTOs are interested primarily in the non-tech benefits. More than I<br>thought. Their technical problems just don't require it. I bet you won't<br>find any topologySpreadConstraints in their manifests, they don't<br>care. No HPA, no Pod Disruption Budgets, no node affinity rules. Just the<br>same number of nodes they'd have VMs otherwise. But they accepted to pay<br>the price of having a complex piece of software for the organizational<br>benefits.
Honestly, I think it's mostly fine. But I still think most companies<br>should start without it. Clusters are genuinely hard to debug when stuff<br>goes wrong, and at that stage you want your energy on the product, not the<br>infra. When you're still pitching to your next big customer, spinning up a<br>VPS and doing a dirty git pull is a totally valid<br>emergency fix. Suboptimal, sure. But fast, and you know exactly what's<br>happening. You really don't want to spend two hours figuring out why your<br>pod is stuck in CrashLoopBackOff right before a customer<br>call.
Why the shift happened recently
I still don't totally get why the shift happened when it did. Five years<br>ago all three camps were doing fine. Now the VM+systemd crowd<br>has basically disappeared from job postings, serverless stayed niche, and<br>K8s just won.
My best guesses: managed K8s (EKS, GKE, AKS) got mature and the talent<br>pool flipped: enough people learned it that hiring for anything else<br>became the harder choice. And Helm made "just use someone else's chart" a<br>real option. But I'm not certain. If you were there for the shift and have<br>a better theory, I'd genuinely like to know.
When to use Kubernetes
My personal threshold would be the moment the CTO isn't the only engineer<br>anymore. As soon as a second person shows up, the problems K8s solves<br>become real. Now you've got someone who didn't set up the servers but<br>needs to deploy. Someone who needs proper access controls, not SSH keys to<br>everything. Someone who'll leave eventually and take everything they know<br>with them. That's when you want the system to hold the knowledge, not<br>people.