Platform Engineering and Developer Experience

What this area actually covers

Platform engineering is the work of building the layer between raw infrastructure and the engineers who need to ship software on top of it, so that shipping software doesn't require every team to independently solve provisioning, pipelines, secrets, observability and compliance from scratch. Concretely, that means a developer portal that answers "what exists and who owns it," a CI/CD system that turns a commit into a deployed artefact reliably and fast, self-service infrastructure that a team can provision without filing a ticket, and the guardrails — security, compliance, cost — that apply automatically rather than through review.

The discipline is defined as much by its stance as by its tooling. The platform is treated as an internal product, with the engineers who use it treated as customers who have a genuine choice to adopt it or route around it, rather than as a captive audience for whatever the platform team decides infrastructure should look like. That framing sounds soft next to "build a Kubernetes cluster" or "write the CI pipeline," but it is the thing that actually determines whether a platform effort succeeds, because the technical work of provisioning compute or wiring a pipeline is well understood and has been for years. What is much harder, and what separates a platform team that matters from one that gets quietly worked around, is building something teams choose to use.

It is easiest to place by naming its two neighbours, because platform engineering sits between them and borrows from both without being either. Below it is infrastructure and operations: the literal compute, network, and storage, and the discipline of keeping those running. Platform engineering consumes that layer rather than replacing it — a platform team still needs somewhere to run the CI runners and the portal itself. Above it, in the sense of being a further step removed from the machine, is the software engineering the platform exists to serve: the actual product code that a backend or frontend engineer writes, which the platform is meant to get to production faster and more safely. Platform engineering is the middle layer that most directly determines how much friction every other engineer in the organisation experiences on an ordinary Tuesday.

What gets wrongly bundled into it varies by organisation. Pure infrastructure operations — keeping a database patched, responding to a hardware failure — is adjacent work that platform teams often also do, but it is not what makes a platform a platform; a team could run flawless infrastructure and still have built nothing anyone chooses to use. Security engineering is a second neighbour frequently conflated with it: a platform team implements security guardrails as code, but deciding what those guardrails should be is usually a security team's call, and treating platform engineering as a security function undersells the product-thinking half of the job. And DevOps, a term whose meaning has drifted since it was coined, is close enough that the titles are used almost interchangeably in job postings, but the useful distinction — covered below — is that DevOps as originally described is a cultural practice applied within a team, while platform engineering builds a product used by many teams.

The two areas underneath

This section on Preptima is divided into two subsections, and each one is where a genuinely distinct set of interview questions clusters. Read both if platform engineering is new territory; jump to the one matching a specific job description if it isn't.

Internal Developer Portals covers tools in the shape of Backstage: a service catalog that models ownership and dependencies as data rather than as institutional memory, software templates that scaffold a new service onto a golden path, and the plugin architecture that lets individual teams extend the portal without every feature becoming the core platform team's permanent maintenance burden. The reason this exists as its own subsection rather than folding into general tooling is that a portal's hardest problems are not technical in the usual sense — the catalog schema is simple, the templating engine is a solved problem — they are about data staying accurate over time and about a tool earning habitual use against a faster informal alternative. Expect questions about ownership metadata going stale within a year of launch, about a golden-path template becoming either too rigid to be useful or too loose to be enforceable, and about diagnosing a portal whose adoption plateaued well below what its launch announcement promised.

CI/CD Platforms covers the machinery that runs on every commit: a runner fleet sized and autoscaled against a cost and cold-start trade-off, a build graph that lets a monorepo test only what a change could plausibly have affected, and compliance gates — security scans, license checks, signed artefacts — enforced consistently across every repository without each one drifting into its own slightly different pipeline. It is separated from the portal subsection because the trade-offs are concrete and quantitative in a way portal questions rarely are: a runner pool has a specific size that trades idle cost against queue time, a build graph has a specific blind spot where a false negative can ship untested code, and a compliance gate has a specific mechanism deciding whether it blocks a merge or merely reports a finding. Expect scenario questions built around a real production number — a forty-minute pipeline, a fleet of a hundred repositories — because that is how the discipline's actual interviews are shaped.

Where it sits in a real system

Follow one engineer's morning rather than one request, because platform engineering's effect is felt before a request ever reaches a service. An engineer opens a ticket describing a new feature that needs a new service. Without a platform, that means requesting a repository, guessing at a pipeline configuration by copying one from elsewhere, filing a ticket for a database, and waiting on whoever owns network and security policy to approve access. With a platform, the engineer runs a scaffolding command that produces a working repository with a pipeline already wired to the organisation's standards, requests a database through a self-service form that provisions it in minutes because the dangerous choices are constrained inside the module rather than left to a reviewer's judgement, and the new service is automatically registered in a catalog with a resolvable owner the moment it exists.

flowchart TD
    A[Engineer needs a<br/>new service] --> B[Scaffold from a<br/>golden-path template]
    B --> C[Pipeline wired<br/>automatically]
    C --> D[Self-service infra<br/>request, guardrailed]
    D --> E[Service registered<br/>in the catalog]
    E --> F[First deploy reaches<br/>production]
    F --> G[Platform team sees<br/>adoption, not just uptime]

The step worth staring at is the last one. A traditional infrastructure team's job effectively ends once the service is deployed and running; a platform team's job continues, because the number that tells them whether any of this worked is not whether the service is up, it's whether the engineer chose the golden path at all, whether they're still on it six months later, and whether the next engineer chooses it too. That loop back into the platform team's own metrics is the part that most distinguishes the discipline from the infrastructure work it's built on top of.

The synchronous-versus-asynchronous framing that shapes backend engineering shows up here in a specific form: a platform decision about whether a self-service request blocks the requesting engineer or completes in the background changes what that engineer experiences while waiting. A database provisioning request that takes ten minutes and is asynchronous — the engineer gets on with something else and receives a notification — is a very different experience from one that blocks a script the engineer is sitting in front of, even if the total time is identical, and platform teams that ignore this distinction routinely underestimate how much a slow synchronous step damages the perceived quality of their platform regardless of its actual reliability.

The last row is worth sitting with, because it's the trade a platform team is actually making, not a trade that disappears once self-service is built. A human reviewer catches an unusual request a module's fixed interface never anticipated; a module never gets tired, never rubber-stamps under pressure, and never catches the case its author didn't think of. Good platform design doesn't eliminate that risk, it moves it: from a reviewer's attention span, which degrades under volume, to a module's design surface, which needs to be revisited deliberately as new requirements appear rather than trusted indefinitely.

Who does this work

The builders are platform engineers and developer-experience engineers, whose actual day is closer to a product manager's than an infrastructure engineer's title would suggest: talking to the teams who use what they build, watching adoption data, and only then writing the infrastructure code that the conversation justified. A day spent entirely writing Terraform with no conversation about who's going to use it and why is, for most platform roles, a sign the work has drifted away from the discipline's actual value.

Site reliability engineers frequently sit adjacent to or inside a platform team, particularly around the observability and incident-response tooling the platform provides to every tenant service, and the boundary between "platform SRE" and "platform engineer" is drawn differently at almost every organisation that has both titles. DevOps engineers, where the title is used for someone embedded in a smaller number of teams building and maintaining their specific CI/CD and deployment automation, do closely related work at a narrower scope — one to a few teams rather than the whole organisation — and many engineers move between the two roles over a career without the underlying skill changing much.

The distinction worth keeping in mind, because it changes what a candidate should volunteer in an interview, is between people who measure their work by whether something exists and people who measure it by whether anyone uses it. A platform engineer who describes a beautifully architected catalog with no mention of adoption, support ticket trends, or what happened when a team tried to opt out has described half the job. The other half — closer to a product sense than an engineering one — is what separates a platform effort that gets funded again next year from one that quietly gets deprecated.

Demand, adoption and how that is changing

Demand for platform engineering is high and has grown steadily rather than exploded, driven by a specific and durable pressure: as organisations run more services on more infrastructure, the cost of every team independently solving provisioning, pipelines and compliance grows faster than the organisation's headcount does, and centralising that work behind a self-service layer is one of the few ways to keep that cost from scaling linearly with the number of teams. That pressure doesn't depend on any particular technology trend continuing, which is part of why demand has been comparatively stable rather than tied to one platform's popularity.

Kubernetes' widespread adoption is a specific driver worth naming, because Kubernetes is powerful and also genuinely complex to operate correctly, and most organisations that adopted it discovered that exposing it directly to every product team produced inconsistent, insecure, and slow-to-onboard usage. Platform engineering emerged in large part as the answer to that specific problem: wrap the complexity in a self-service layer with sensible defaults, so most teams never need to become Kubernetes experts to deploy a service safely. That history is why so much of the discipline's tooling and vocabulary — golden paths, developer portals, service meshes as platform-owned infrastructure — grew directly out of the Kubernetes ecosystem, even though the underlying ideas apply regardless of which orchestration platform an organisation runs.

What is genuinely commoditising within the discipline is the tooling itself: a developer portal, a CI runner autoscaler, and a policy-as-code engine are each available as an open-source or vendor product good enough that building an equivalent from scratch is rarely the right call anymore. What has not commoditised, and shows no sign of it, is the judgement of what to build for a specific organisation's actual teams, in what order, and how to tell honestly whether it worked — the product-thinking half of the discipline rather than the tooling half. Interviews have shifted accordingly: a round that once asked mainly about Kubernetes manifests or CI configuration syntax now more often asks a candidate to reason about adoption, trade-offs, and a scenario where a platform effort visibly underperformed, because the tooling knowledge is easier to acquire than the judgement is.

What makes it hard

The defining difficulty is that platform engineering is evaluated on a dimension most engineers are never trained to measure: whether other people, who have a real choice, chose to use what you built. A backend engineer's correctness can be verified with a test suite. A platform's success cannot be verified that way at all, because the test suite passing says nothing about whether the fifty teams the platform was built for actually adopted it, and a platform team that only watches its own uptime dashboard can be entirely blind to an initiative quietly failing in exactly the way that matters.

This produces a specific, recurring failure that experienced platform engineers learn to watch for: building the technically correct solution to a problem nobody validated, then discovering months later that adoption never materialised because the thing being solved wasn't actually anyone's most pressing pain. The skill that prevents it — talking to the teams who will use something before building it, and being willing to build something narrower and less impressive if that's what a real team's real problem calls for — is closer to a product manager's discipline than to anything covered in a typical engineering curriculum, and it does not come naturally to engineers selected and promoted for technical depth.

flowchart TD
    A[Platform team builds a<br/>technically sound feature] --> B{Was it validated<br/>against a real team's<br/>actual daily task}
    B -- No --> C[Ships to silence;<br/>adoption never appears]
    B -- Yes --> D[Ships to a team already<br/>waiting for it]
    D --> E[Adoption spreads as other<br/>teams hear it worked]

A second, more concrete difficulty sits underneath the product one: guardrails that work at ten teams often break at a hundred. A review step that catches every edge case when three teams file requests a week becomes either a bottleneck or a rubber stamp once forty teams file requests daily, and the fix — encoding the guardrail into a module's interface rather than a human's judgement — requires anticipating which edge cases genuinely need a human and which can be safely fixed in code, a judgement call that gets it wrong in both directions regularly even for experienced teams. Getting this wrong in the strict direction produces a platform nobody can actually use for their real, slightly unusual case; getting it wrong in the loose direction produces exactly the security or compliance gap the guardrail existed to prevent.

The third difficulty is that a platform team's work is largely invisible when it succeeds. A team that never has to think about how CI runners scale, how a service gets registered, or how a compliance gate is enforced is a team the platform served well, and that success looks, from outside, like nothing happening — which makes justifying the platform team's continued investment to anyone who doesn't already understand the discipline a genuinely recurring management problem, not just an engineering one.

Why study it

It is the rare area of software engineering where the technical skill and the product skill are both load-bearing, and most engineers arrive with only one of the two, which makes deliberately building the other a real differentiator rather than a marginal improvement. An engineer who has spent years writing infrastructure code but never had to ask whether anyone used what they built develops the technical half without the half that actually determines outcomes; studying platform engineering deliberately forces both, because the discipline has no meaningful version of success that skips the adoption question.

It is also unusually well positioned relative to how organisations are actually growing. As more organisations run more services on more infrastructure, and as Kubernetes and cloud-native patterns continue spreading into organisations that adopted them more recently than the earliest movers, the specific problem platform engineering solves — the cost of every team solving provisioning and pipelines independently — gets larger rather than smaller, and that growth doesn't depend on speculating about which specific tool or vendor wins a category.

There is an honest case against it too. If the appeal is purely technical depth in a single system — becoming the person who knows a particular orchestration platform better than anyone — a platform engineering role will feel diffuse, because the job spans catalog data modelling, pipeline mechanics, cost attribution and stakeholder conversations rather than deep specialisation in any one of them. And if the idea of measuring your work's success by whether colleagues chose to use it, rather than by a metric you fully control, sounds uncomfortable rather than interesting, the discipline will be a persistent source of friction rather than the differentiator it is for people who find that ambiguity engaging.

Your first hour

Pick one real, small friction you or a teammate has actually hit recently — not an imagined one — and scope a golden-path template that removes it. A good candidate is the setup steps for a new service: creating a repository, wiring a basic CI pipeline, and registering it somewhere discoverable. Build the smallest version that produces a working result end to end, even using a plain shell script rather than a proper templating engine, because the exercise that matters here is naming the specific friction and proving it's removable, not the sophistication of the tooling.

The artefact worth having at the end is small and specific:

Friction identified : "Setting up a new repo's CI pipeline takes about 40
                       minutes of copying and adapting an existing one, and
                       people get it subtly wrong often enough that it's a
                       recurring source of first-week bugs."
Template produces    : a repo with a working pipeline already correct
Time saved           : roughly 35 minutes per new service, once
What's still manual  : anything genuinely specific to that one service
Who would actually
use this             : name one real team, not "everyone eventually"

Then do the harder, more uncomfortable second step: actually ask that one real team whether they'd use it, before spending more time polishing it. If the honest answer is "probably not, we don't create new services often enough for this to matter," that's a more valuable outcome than a beautifully engineered template nobody needed, because it's the exact failure mode the discipline exists to catch early rather than discover a year into a bigger investment.

What this is not

It is not the same job as infrastructure or operations engineering, even though it depends heavily on that layer and many platform engineers come from that background. Infrastructure engineering is judged on whether the underlying compute, network and storage are available and performant; platform engineering is judged on whether the self-service layer built on top of that infrastructure is actually adopted, which is a different question that a perfectly reliable, unused platform answers just as badly as an unreliable one.

It is not DevOps in the narrower, more common usage of that title, though the boundary is genuinely blurry and the titles are often used interchangeably in job postings. DevOps as most commonly practised describes a smaller-scope role embedded with one or a few teams, owning their specific CI/CD and deployment automation; platform engineering describes a one-to-many relationship, building something many teams use without direct platform-team involvement in each one's day-to-day work. A platform engineer who has never had to think about adoption across teams they don't work alongside directly is probably doing DevOps work under a platform title, which is a fine job and simply a different one.

It is not a Kubernetes specialisation, despite how much of the discipline's tooling and vocabulary grew out of the Kubernetes ecosystem. The underlying problems — golden paths, self-service guardrails, catalog data staying current, CI fleets scaling with cost in mind — apply just as directly to an organisation running on a different orchestration platform, or none at all, and treating Kubernetes fluency as the whole of the skill undersells the parts of the job that transfer regardless of the underlying infrastructure choice.

And it is not primarily a security function, even though a large share of what a platform team ships is a security or compliance guardrail. The platform team usually builds and operates the mechanism — the admission controller, the pipeline gate, the signing step — while a security team decides what the rule should actually be; a platform engineer who can implement any policy handed to them but never questions whether it's the right one, or whether it's enforceable without becoming a bottleneck, is missing the judgement that the rest of the discipline depends on.