Based on a year of platform-engineering interviews, the author found that every team called their setup 'Kubernetes' but almost no two ran the same thing — EKS+Karpenter+Istio, ancient kops clusters, ECS-with-K8s-as-job-runner, and bare-metal self-hosted control planes all coexisted under the same label. He argues Kubernetes is closer to Linux than to Heroku, and the real platform is whatever ad-hoc accretion of operators, admission controllers, and tribal Helm charts a team has built on top.
The author argues that hyper-specific debugging prompts — like a CrashLoopBackOff with an init container timing out on a sidecar readiness probe — aren't generic API knowledge tests but reenactments of recent on-call disasters. Interviews function as primary-source ethnography, giving candidates more honest visibility into a company's real stack than any conference talk or architecture diagram ever does.
Because recruiters, tool vendors, and pricing models all assume a uniform 'Kubernetes' exists, candidates with '5 years of K8s' may share almost no overlapping skills, and tools sold to 'Kubernetes shops' end up solving problems only a fraction of buyers actually have. The author frames this mispricing as the practical cost of an industry-wide pretense that a substrate is a platform.
A notnotp.com post titled *What job interviews taught me about Kubernetes* climbed to 125 on Hacker News by doing something the conference circuit refuses to: treating job interviews as primary-source ethnography. The author spent a year on the candidate side of platform-engineering interviews and used the experience to reverse-engineer what companies actually run, as opposed to what they put on their architecture slides.
The top-line finding is uncomfortable for anyone who still calls Kubernetes a *standard*. Every team interviewed had a cluster, every team called it Kubernetes, and almost no two teams ran the same thing. One shop was on EKS with Karpenter and Istio. Another was on three-year-old kops clusters they were too scared to upgrade. A third had quietly moved everything stateful to ECS and was using K8s as an expensive job runner. A fourth was *self-hosting* the control plane on bare metal because their CFO read an FinOps blog post.
The interview questions were the tell. When a company asks you to debug a CrashLoopBackOff on a pod with an init container that times out waiting on a sidecar's readiness probe, they are not testing your knowledge of the Kubernetes API. They are showing you, with the specificity of a confession, exactly which Tuesday morning ruined their last on-call rotation.
The industry has spent a decade pretending Kubernetes is a platform. The interview data says it's a substrate — closer to Linux than to Heroku — and that the actual platform is whatever ad-hoc collection of operators, admission controllers, GitOps tools, and tribal Helm charts a given team has accreted on top of it. The unit of comparison between two "Kubernetes shops" is roughly the same as the unit of comparison between two "Linux shops" in 2008: technically accurate, practically meaningless.
This matters because hiring, tooling, and vendor pitches are all priced on the fiction of uniformity. Recruiters ask for "5 years of Kubernetes" as if that string resolved to a known skill. It doesn't. Five years on a GKE Autopilot cluster with Cloud SQL and managed Istio is a different job from five years duct-taping kubeadm clusters across three datacenters with a homegrown CNI. The candidates know this. The hiring managers writing the JDs apparently still don't.
The vendor ecosystem has the same problem in reverse. The CNCF landscape is now north of 200 projects, and the meaningful question is no longer *does this tool exist* but *which of the seventeen overlapping tools did this particular team pick, and why are they angry about the choice three years later*. The interview process is one of the few venues where you get an honest answer. Nobody on a conference panel will admit they regret picking Argo Rollouts over Flagger. The platform lead doing a technical screen at 4pm on a Thursday absolutely will.
The post lands at an inflection point. Hacker News commenters this week have been re-litigating whether Kubernetes was ever the right default for sub-100-engineer companies, with the usual suspects (Fly.io, Render, ECS-on-Fargate, even a plain systemd revival) showing up in the replies. The interview data cuts through the holy war by pointing out that even the companies who chose Kubernetes mostly chose something *near* Kubernetes, and the differences between their nears are larger than the difference between Kubernetes and Nomad.
There's also a hiring-market signal here that's worth naming. When a company's interview loop spends 90 minutes on Helm template debugging and zero minutes on application code, that is not a sign of platform sophistication. It is a sign that the platform has metastasized into the product, and that whoever they hire is being recruited to maintain the maintenance, not to ship anything a customer will see.
If you are evaluating a new infrastructure hire, throw out the years-of-experience filter and replace it with a single question: *describe the worst incident your current cluster caused you, and what you did about it.* The answer will tell you, in about ninety seconds, whether the candidate has actually run Kubernetes in anger or whether they have only watched it from the audience of a KubeCon keynote. The same question, asked of yourself, will tell you whether your team needs another platform engineer or whether it needs to delete half the platform.
If you are evaluating Kubernetes itself — still a legitimate question in 2026 — stop reading the marketing pages of the managed offerings and start reading the on-call runbooks of teams two stages ahead of you. The honest version of a K8s adoption decision is not "do we want pods" but "do we want to hire the three specific humans required to keep our specific accidental distribution of pods alive at 3am." Most teams under 50 engineers don't, and the ones that pretend they do are quietly paying a managed-service vendor to pretend for them.
If you are a candidate, the inversion is the actionable bit. Treat the interview as the most reliable architecture-review document any company will ever hand you. The questions are the bug tracker. The follow-up questions are the postmortem backlog. If the loop is all happy-path Deployments and Services, the team hasn't hit production scale. If the loop is all StatefulSets, PDBs, and topology spread constraints, you are about to be on-call for someone else's three-year-old decision. Price accordingly.
The useful Kubernetes skill of the next five years is not deeper knowledge of the API. The API is mostly frozen and the useful surface area has been stable since 1.25. The skill is *reading other people's clusters* — being able to walk into a stranger's repo, identify which of the eight popular paths they took, figure out which two of those paths they took simultaneously by accident, and have an opinion about which one to delete first. That is closer to archaeology than to engineering, and the only place it's currently being taught is, apparently, in the interview loop itself.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.