What I Look For in a Platform Engineer

Not certifications. Let’s start there.

I’ll be upfront: this is a contrarian position and I know it. I’ve held certifications from the largest cloud-focused vendors. I know what they teach and what they don’t. The opinion isn’t uninformed. It’s a conclusion I landed on after years of seeing what cert-heavy hiring actually produces versus what the work actually requires.

Vendor certifications show you can talk about a platform the way the vendor wants you to. That’s what they’re designed for: building ecosystems, driving adoption, creating a language that keeps practitioners inside a specific set of products. Some of them do teach real fundamentals. Some of them have genuine universal value. But most of them are biased toward vendor-specific capabilities that are lock-in opportunities dressed up as conveniences and best practices. That’s not an accident. It’s the business model.

None of that means you shouldn’t go in that direction. My argument is that you shouldn’t go in blind. A certification tells you the vendor’s answer. It doesn’t tell you whether that answer is right for your situation, what you’re trading away by taking it, or what the problem looks like from a layer the vendor doesn’t want you to think about. Someone who knows all of that and chooses the vendor path anyway is making a real decision. Someone who doesn’t know it is just following a map someone else drew for their own reasons.

So. What am I actually looking for?

---

The First “It Depends”

The most reliable signal in any technical interview is the placement of the first “it depends” and the precision of what follows it.

Someone who gets how platform engineering actually works will say it early. Not as a hedge. As the honest answer, because the honest answer to most infrastructure questions does depend on context. The storage architecture depends on the workload profile. The networking approach depends on whether you’re running stateful services and how they need to talk to each other. The abstraction level depends on what varies across your environments and what stays stable. The right answer to most real questions is conditional, and someone who has thought carefully about the problem knows which conditions matter.

What I’m listening for isn’t just the words. It’s the specificity of what follows. “It depends on your scale and team maturity” is pattern matching. “It depends on whether you’re running stateful workloads, because if you are the storage layer changes the whole conversation and managed services start looking different” is actual reasoning. One of those is a person who has read about the topic. The other is a person who has thought about it.

You can probe it. Ask the follow-up. Make them go one level deeper. The real thinkers get more specific as you push. The ones who were pattern-matching run out of road.

---

The Opposite Problem

The person who never says “it depends” is a different kind of liability.

Blind, absolute confidence in this space, confident answers to every question with no acknowledgment of tradeoffs or conditions, means one of two things. They’re following an interview guide and giving the popular answers, or they’ve only ever seen one version of the problem and have no idea that other versions exist.

Both are dangerous, but the second one is the harder failure mode. Interview guide answers you can usually find the edge of quickly. The one-problem engineer is harder to spot because their confidence is real. They believe the answer they’re giving because it’s the only answer they’ve ever had to give. They solved that problem once, it worked, and they’ve been solving it again ever since. Every new situation that superficially resembles their one problem gets the same solution.

Platform work surfaces the edges of that model fast. The environment is too varied, the failure modes are too specific, and the consequences of applying the wrong mental model too confidently are too real. Someone who doesn’t know what they don’t know is more dangerous than someone who knows they don’t know something.

Experience is supposed to produce calibration. The tell that it has is a willingness to say “it depends” early and mean it.

---

Depth Plus a Growth Pattern

I’m not looking for generalists. Generalists go wide and shallow. Wide and shallow doesn’t hold up in this space because the problems are deep and the failure modes live at the bottom.

What I’m looking for is depth in one or two areas and evidence of a growth pattern outside that depth. Someone who is deep in networking and has clearly pushed themselves into distributed systems. Someone who is deep in application architecture and has worked their way down into the infrastructure layer, or vice versa. Not someone who has dabbled in everything but someone who has gone deep somewhere and has demonstrated they can do it again somewhere new.

The question I’m actually trying to answer is: can this person do it again?

Not “what do they know,” which is answerable with a resume. The harder question is whether they’ve shown the pattern of going deep on something unfamiliar when it mattered, building genuine operational understanding, and coming out the other side with a mental model that actually holds. That pattern is the thing that compounds. The specific domains they’ve gone deep in matter less than whether they’ve proven they can add new ones.

The evidence for this pattern is usually in how people talk about learning something hard. Not what they learned. How they went about it, what it cost them, what they got wrong before they got it right. Someone who has done this has specific stories. Someone who is representing competence they don’t have tends to stay at the level of outcomes.

---

Operational Empathy

The last thing, and the hardest to screen for, is whether someone thinks about the people their platform serves.

Platform work is easy to do in a way that’s technically correct and practically useless. A system that works but that no one can operate under pressure, a deployment process that’s theoretically sound but costs engineers twenty minutes of cognitive overhead every time, an abstraction layer that’s architecturally elegant and operationally exhausting. These are failure modes that don’t show up in tests. They show up when someone is tired and under pressure and has to do the thing.

The best platform engineers I’ve worked with have an almost instinctive sense of what it’s like to be on the other end of what they’re building. They ask what happens when someone has to use this at 2am when they don’t fully remember how it works. They think about the person who’s going to inherit this system eighteen months from now and has never seen it before. They treat operational ease as a design constraint, not an afterthought.

This is harder to hire for than technical depth, but it’s not impossible. The tell is how people talk about the systems they’ve built: whether they talk about how the system works or how people work with the system. Those are different conversations and the people who default to the second one tend to build things that hold up.

---

One More Thing

Potential team members don’t deserve hostile interviews. Ever.

You can be rigorous. You can push hard on reasoning. You can follow up, ask for more specifics, probe the edges of an answer. Objective and strong is fine. Hostile isn’t, and the line between them is clearer than some interviewers seem to think.

I’ve been on the receiving end of this. I was interviewing for a role and one of the interviewers decided to drill me on BGP after I directly stated I wasn’t an expert in the space. Not my circus, not my monkeys. I said so clearly. They kept going anyway. I had a long conversation with the recruiter afterward because I was a hair’s breadth from walking out of the process entirely. I would have been justified.

That interviewer was demonstrating failure mode one in real time. Someone who only knows how to evaluate depth in their own domain, so they probe for it regardless of relevance or context. It’s the one-problem engineer applied to interviewing. And it told me everything I needed to know about what working there might look like.

The best candidates have options. The ones who walk away from a hostile interview aren’t the ones who couldn’t handle it. They’re the ones who correctly read what it signals. You don’t get to see them leave. You just never hear from them again.

The interview is day one. How you conduct it is the first data point anyone gets about how you operate. Make it count for the right reasons.

The conversation I’m trying to have in any platform engineering interview is: show me how you think.

Not what you’ve memorized. Not what tools you’ve used. How you reason about tradeoffs, how quickly you get to “it depends” and how precise you are about the conditions, whether you know the edges of your own knowledge, whether you’ve shown you can learn the next hard thing.

The resume tells me where someone has been. The conversation tells me whether they can get to somewhere new. Platform work is always somewhere new. The environment changes, the constraints change, the hardware has opinions the design didn’t anticipate, the team you’re building for has needs that weren’t in the requirements.

The engineers who are consistently useful in that environment aren’t the ones who have seen everything. They’re the ones who know how to see what they haven’t seen before.

Certifications don’t tell me that. The first “it depends” usually does.