Platform engineering hiring — the skills you actually need vs. the job descriptions you are writing

TL;DR. The typical platform engineering job description selects for engineers who know the current toolstack and can extend it. The engineers who build platforms that developers actually use have a different profile: they investigate friction before designing solutions, treat platform telemetry as feedback rather than reporting, ask what work the platform should absorb rather than what features it should have, and attribute low golden path adoption to platform design failures rather than developer behavior. Tool familiarity is trainable. These five qualities are not. A job description that lists Kubernetes and Terraform is hiring to maintain what exists. An interview process that tests absorption orientation is hiring to improve developer experience.

The typical platform engineering job description lists tools. Kubernetes. Terraform. Backstage. ArgoCD. Some combination of AWS, GCP, or Azure. Golang or Python. CI/CD tools. The job description selects for engineers who know the current platform's toolstack and can extend it.

The engineers who build platforms that developers actually use have a different skill profile. They are problem investigators before they are tool builders. They measure what the platform absorbs before they decide what to build next. They treat the absence of usage on a golden path as a signal about the path's design, not about developer behavior. They know when to build versus when to configure versus when to constrain, and they make those decisions from data rather than from tool preference.

Tool familiarity is a trainable skill. The judgment required to build a platform that developers route through under deadline pressure is much harder to develop on the job. Hiring for tools and hoping judgment follows produces platform teams that build sophisticated tooling that developers work around.

What tool-first job descriptions actually hire for — and what they miss

A job description that lists Kubernetes as a requirement is optimizing for engineers who have worked with Kubernetes before. That is a reasonable proxy for someone who can continue the existing work. It is a poor proxy for someone who can decide whether Kubernetes is the right tool for the next problem, how to make the Kubernetes abstraction simpler for the developers who use it, or when to build a golden path that hides Kubernetes complexity rather than exposing it.

The same pattern applies to every tool in the standard list. Terraform experience tells you the candidate can write and maintain Terraform. It does not tell you whether they will design Terraform modules that developers use voluntarily versus modules that developers copy into their own repos and modify because the standard module does not absorb their actual use case.

The tool-first job description produces a specific hiring failure mode: a team that maintains the toolstack well but does not evolve the platform toward higher absorption. The tooling runs. The golden paths exist. The developer experience metrics are flat because the team is optimizing the tooling rather than optimizing what the tooling absorbs.

Five qualities that predict whether an engineer will build platforms developers use

These are the skills I look for when I help organizations build or assess platform teams. They predict whether an engineer will build platforms that developers use, not just platforms that exist.

The first is problem investigation before solution design. The best platform engineers spend more time understanding a friction problem than most engineers spend on both understanding and solving combined. Ask in an interview: "Tell me about a time you discovered that a platform capability was not being used the way you expected. What did you do?" The answer you are looking for is that the engineer investigated why. They talked to developers. They looked at telemetry. They found a friction point they had not anticipated and changed the capability based on what they found. The answer that indicates poor fit: the engineer concluded that developers were not using the capability correctly, added documentation, and moved on to the next feature. The distinction is the investigation step. Engineers who investigate why their platforms are not being used produce platforms with improving adoption. Engineers who attribute non-adoption to developer behavior produce platforms with static adoption and increasingly sophisticated documentation.

The second is what I call telemetry instinct — treating platform telemetry as feedback rather than reporting. The distinction: reporting is what you look at to confirm things are working. Feedback is what you look at to understand what to change. An engineer with telemetry instinct will, unprompted, instrument new platform capabilities before shipping them, define what good adoption looks like before measuring it, and treat unexpected usage patterns as data rather than anomalies to ignore. Evaluate this in interviews by asking about a specific platform capability the candidate shipped. Ask what they measured before and after. Ask what the data showed that surprised them. Engineers with telemetry instinct will have specific answers to all three questions. Engineers without it will describe the capability they built, not the outcome it produced.

The third is absorption orientation versus feature orientation. A platform engineer with absorption orientation asks: what work is the developer doing that the platform should be doing instead? A platform engineer with feature orientation asks: what capability can I add to the platform? Both orientations produce work. The absorption-oriented engineer produces capabilities that developers use because the capabilities reduce work the developer was already doing. The feature-oriented engineer produces capabilities that developers may or may not use, depending on whether the capability happens to match a real need. The interview question that surfaces this: "If you joined a new platform team tomorrow, what would you do in the first two weeks before writing any code?" The absorption-oriented engineer describes investigation — shadowing developers, reviewing deployment telemetry, asking what developers route around most often. The feature-oriented engineer describes scoping: reviewing the backlog, understanding technical debt, planning what to build first.

The fourth is judgment about build versus configure versus constrain. Most platform decisions are not build decisions. They are configuration decisions (use the tool differently), constraint decisions (add a guardrail that prevents the problematic pattern), or build decisions (build the capability that does not exist). Engineers who default to building when configuring or constraining would serve better produce platform complexity without equivalent capability gain. Evaluate this with a concrete scenario. Describe a situation where a team keeps deploying to production without running the full test suite, bypassing the CI requirement. Ask what the candidate would do. The engineer with good judgment will ask clarifying questions: why are they bypassing it? Is the test suite too slow? Is there a specific test category that consistently fails with false positives? The answer changes the intervention from "add a harder gate" — which produces more workarounds — to "fix the specific thing causing the bypass," which produces adoption of the correct path.

The fifth is the ability to say "the platform failed here, not the developer." This is the hardest to interview for and the most predictive of long-term platform quality. Platform engineers who produce improving developer experience attribute non-adoption and golden path bypasses to platform design failures rather than developer behavior failures. They interpret a developer routing around the deployment pipeline as information about the pipeline's friction, not about the developer's attitude toward process. This attribution changes the investigation: an engineer who attributes non-adoption to developer behavior investigates how to get developers to comply. An engineer who attributes it to platform design investigates what the platform is asking developers to do that costs more than the platform's value provides.

An interview process that evaluates absorption orientation instead of tool knowledge

A platform engineering interview process that evaluates these skills has four components.

Start with a technical screen that is a diagnosis exercise, not a coding exercise. Present a set of platform metrics and ask the candidate to describe what is happening and what they would investigate. This tests whether they can read telemetry as feedback and form hypotheses from data.

Follow with a problem investigation interview. Present a realistic platform adoption problem — golden path compliance at 35 percent, paved road bypasses during release crunches. Ask the candidate to walk through how they would investigate, what data they would gather, and what hypotheses they would form. Evaluate whether they investigate the platform before investigating developer behavior.

For the system design interview, ask the candidate to design a golden path for a specific service type. Evaluate whether they define the absorption requirement before designing the path, and whether they describe how they would measure whether the path is actually working once shipped.

Close with a reference check specifically focused on platform adoption. Ask former managers and colleagues whether the candidate's platform work was actually used by developers, and how they know. Engineers who build platforms that developers use tend to produce specific, measurable adoption stories in references. Engineers who build sophisticated platforms that are underused tend to produce references that describe technical quality without reference to adoption.

Platform team structure at three organizational size stages

The right platform team structure depends on organizational size and maturity, not on an ideal template.

Under 30 engineers, the platform work is primarily reliability — deploy pipeline, monitoring, incident runbooks — and golden path quality for the two or three most common service types. A dedicated platform team is premature at this stage. One to two engineers with explicit platform responsibility alongside product development work is more appropriate.

From 30 to 100 engineers, a dedicated platform team of three to five should focus on the Foundations Framework first pillar sequence: delivery reliability, golden paths, measurement. At this size, the team's primary return is in reducing on-call load for product engineers and reducing the time senior engineers spend teaching platform knowledge to new hires. The team should have at least one engineer with absorption orientation as their lead — the platform's value comes from what it absorbs, not from what it builds.

Above 100 engineers, the team scales to six or more with specialization between reliability engineering, developer experience, and portal work. At this size, the team needs a measurement practice for its own work: which investments are producing adoption, which golden paths have compliance rates above target, which incident categories have runbook coverage. Without measurement, a larger team produces more tooling without necessarily producing more absorption.

Frequently asked questions

What is the most predictive interview question for platform engineering candidates?

"If you joined a new platform team tomorrow, what would you do in the first two weeks before writing any code?" The answer distinguishes absorption-oriented engineers from feature-oriented ones. The absorption-oriented answer describes investigation: shadowing developers, reviewing deployment telemetry, asking what developers route around most often. The feature-oriented answer describes scoping: reviewing the backlog, understanding technical debt, planning what to build first. Both produce work. Only the first produces capabilities developers use because those capabilities reduce work developers were already doing.

What is telemetry instinct and how do you evaluate it in interviews?

Telemetry instinct is treating platform telemetry as feedback rather than reporting — looking at usage data to understand what to change, not just to confirm things are working. An engineer with telemetry instinct will instrument new platform capabilities before shipping them, define what good adoption looks like before measuring it, and treat unexpected usage patterns as data rather than anomalies. Evaluate it by asking about a specific platform capability the candidate shipped: what did they measure before and after, and what did the data show that surprised them. Engineers with telemetry instinct have specific answers to all three questions. Engineers without it describe the capability they built, not the outcome it produced.

How should platform team structure change as the organization scales?

Under 30 engineers, dedicated platform headcount is premature — one to two engineers with explicit platform responsibility alongside product development is more appropriate, focused on deployment reliability and incident runbooks. From 30 to 100 engineers, a dedicated team of three to five should focus on delivery reliability, golden paths, and measurement, led by someone with absorption orientation. Above 100 engineers, the team scales to six or more with specialization across reliability engineering, developer experience, and portal work, and needs a measurement practice for its own work to avoid producing more tooling without more absorption.

Related reading

• 5 signs your platform team is stuck in ad-hoc mode — what ad-hoc mode looks like from the outside: the patterns a team with absorption orientation would investigate and fix.
• Platform engineering ROI — what to measure and how to defend it — the business case for hiring to the absorption-oriented profile rather than the tool-familiarity profile.
• Cognitive Absorption in platform engineering — the definitive reference — the design accountability the third quality (absorption orientation) is built on: what engineers with that orientation are accountable for building.
• Platform engineering consulting vs. hiring — how to decide — when to hire internally versus engage externally, given the same skill-profile requirements.

---

The Foundations Assessment includes an organizational readiness evaluation that covers team structure, skills gaps, and sequencing for platform team investment. The assessment produces a team design recommendation alongside the platform gap analysis. The free Platform Score surfaces your most critical team structure gaps in fifteen minutes.