How to get hired as a platform engineer in 2026-27

Platform engineer is four different jobs, and the posting tells you which

This title is unusually unreliable, and that is the first thing to understand about the job market for it. Many employers renamed an existing DevOps, SRE or cloud infrastructure team "platform" without changing what the team does, because the word attracts candidates and reads as modern. A smaller set built genuine internal product teams whose users are their own engineers. Both post a requisition headed Platform Engineer, often with overlapping tool lists. Your first task is classification, not resume writing, because the resume, the preparation and the questions you ask are different for each.

Shape one is rebadged operations. The posting leads with cloud, Kubernetes, Terraform, CI/CD, monitoring, on-call, incident response and cost. Responsibilities are phrased around maintaining, supporting and ensuring. The work is running shared infrastructure for the company, and it is a good job. This is the shape you will see most often, and it is what "platform" almost always means at a company with a single infrastructure team and no separate internal customer base to serve. Hiring here is DevOps hiring: scale, reliability numbers, troubleshooting, a design round about a system rather than about an interface.

Shape two is internal developer platform product work. The posting uses product vocabulary: self-service, golden path or paved road, internal customers, developer experience, adoption, abstraction, platform as a product. It names a portal (Backstage, or a commercial one such as Port, Cortex, OpsLevel or Atlassian Compass), a composition or orchestration layer (Crossplane, Kratix, Radius, the Score specification, or a commercial platform orchestrator), reusable Terraform or OpenTofu modules treated as versioned products, Argo CD or Flux with templated application definitions, and custom Kubernetes controllers or custom resource definitions. A programming language usually appears as a first-class requirement rather than as scripting. This shape has the highest coding bar and the most interesting design round, and it concentrates at employers large enough that an internal platform pays for itself.

Shape three is developer productivity and build engineering, sometimes posted as Developer Productivity Engineer, Build Engineer or Developer Experience Engineer. The subject matter is the inner loop and the pipeline rather than the runtime: a monorepo, a build system such as Bazel, Nx, Turborepo, Gradle, Pants or Buck2, remote caching and remote execution, test selection and test impact analysis, flaky test detection and quarantine, merge queues, local and ephemeral development environments, and the wall-clock time of the slowest pipeline. The interview is noticeably different: profiling, caching correctness, hermetic builds, dependency graphs and the discipline of measuring before changing. If you like performance work, this is the shape to look for, and it is less crowded.

Shape four is a domain platform. Data platform, ML or AI platform, observability platform, security platform. Here the domain knowledge is the real gate and the platform skills are assumed. A data platform engineer posting is closer to data engineering than to Kubernetes administration, and an ML platform posting expects you to understand training and serving workloads rather than just the accelerators underneath them. Applying to these with a generic infrastructure resume fails at the screen, because the interviewer wants to hear the domain's failure modes.

You can classify a posting in about ninety seconds. Read the responsibilities and find the noun that follows the verb build: if it is a pipeline or a cluster, you are looking at shape one, and if it is an interface, an abstraction, a portal, a module or a self-service workflow, you are looking at shape two. Count how many times an internal audience is named. Check the required skills for a language stated as a language rather than as scripting. Look at whether on-call is described as production infrastructure on-call or as support for a platform other teams depend on. Notice whose satisfaction is named as the measure of success. Then open the employer's other postings on the same careers page, because a company with a real platform organisation posts several of these and names the stream-aligned teams they serve.

Getting this wrong is expensive in both directions. A strong operator who prepares a product narrative for an operations job sounds evasive about the pager. A strong builder who prepares scale numbers for a product-shaped team has nothing to say in the round that decides it. Classify first, then prepare one of two different candidacies.

• Shape one tells: "maintain and support our cloud infrastructure", "ensure high availability", "participate in an on-call rotation", "monitoring and alerting", "automate manual processes". Prepare a DevOps candidacy.
• Shape two tells: "treat the platform as a product", "internal customers", "self-service", "golden path", "reduce cognitive load", "developer portal", "drive adoption", plus Go, Java or Python in the required list. Prepare a builder candidacy with adoption numbers.
• Shape three tells: "build times", "CI reliability", "monorepo", "remote cache", "test flakiness", "inner loop", "local development environment". Prepare measurement and performance stories.
• Shape four tells: the domain appears before the word platform, and the tool list is domain-specific (Spark, dbt, Airflow, Iceberg for data; model serving and feature stores for ML; OpenTelemetry collectors and storage backends for observability). Prepare the domain's failure modes.
• A warning sign worth catching early: a posting that lists the whole of DevOps, the whole of SRE and the whole of internal platform product work for one person is describing an understaffed team, not a broad role. Ask in the screen how many engineers are on the team and how many engineers it serves.
• Ask the recruiter one question that resolves most of this: "Is this team building the platform, or running the infrastructure?" A good recruiter knows, and the answer tells you which of two interview preparations to do.

How platform engineering hiring differs from DevOps hiring

The difference fits in one sentence, and it is worth memorising because interviewers ask you to articulate it. DevOps hiring asks whether you can run the system. Platform engineering hiring asks whether you can build something other engineers choose to use. Both care deeply about production. Only one of them grades adoption, and the parts of a platform loop that surprise strong DevOps candidates all follow from that single difference.

The first consequence is that your evidence changes shape. An operator's proudest resume line is a fleet upgraded across three Kubernetes minor versions with no customer-facing downtime, and that line is excellent. A platform engineer's proudest line is that most of the company's services moved onto the new deployment path within two quarters and the old path was then deleted. The first proves competence under risk. The second proves that engineers with other priorities, who could have ignored you, did not. Keep the reliability evidence, because the platform is production for internal customers and an unreliable platform is worse than no platform, but lead with the adoption evidence when the posting is product-shaped.

The second consequence is that the coding round is real. Platform loops at product-shaped teams include a software interview in a typed language, most often Go because the Kubernetes ecosystem is written in it, sometimes Java or Python to match the internal customers. You may be asked to implement a reconcile loop that converges on a desired state, a CLI with sensible flags and failure messages, a small HTTP API with a schema and tests, or a concurrency exercise with contexts, cancellation and errors. Candidates who are fluent in Bash and Python glue but have never written and tested a program with an interface fail here, and it is the most common single reason a good DevOps engineer does not convert on a platform loop.

The third consequence is an internal product conversation, whether or not it is on the schedule as one. Expect: how did you decide what to build, how did you find out what developers actually needed, what did you ship first and why the smallest thing, what did you refuse to build, how did you know it worked, and how did you get teams to migrate without a mandate. Candidates whose infrastructure career has been ticket-driven often have nothing to say here, because nobody ever asked them to choose. If that is you, the fix is to go and do one small piece of platform work as a product before you interview, which the section on entry routes covers step by step.

The fourth consequence is that interface and compatibility questions appear, and they are library design questions wearing infrastructure clothes. How do you version a Terraform module that two hundred repositories consume. What is a breaking change to a custom resource definition and how do you ship one. How do you deprecate v1 without stopping anyone's release. What leaks through your abstraction, and what happens to the team whose requirement it cannot express. Treat these as API design, because that is what they are.

The fifth consequence is who is in the room. A DevOps loop is usually infrastructure people throughout. A platform loop generally adds a staff or principal engineer from a stream-aligned product team, and sometimes an engineering manager whose team's delivery speed depends on the platform. That person is not assessing your Kubernetes depth. They are assessing whether you would become the bottleneck between their team and production, whether you would listen when their requirement does not fit your model, and whether you would say no clearly rather than disappearing for a quarter. Answer them in their terms: delivery speed, autonomy, and what they would stop having to care about.

What does not change is the part candidates hope will change. Platform engineering is not an escape from operations. You will still be asked to debug a pod stuck in CrashLoopBackOff, explain why a DNS lookup inside a cluster failed, read a Terraform plan and spot the destructive line, describe how you would cut a cloud bill, and tell an incident story where something you owned broke. A candidate who cannot do those does not pass either loop, and a candidate who presents platform engineering as the senior version of DevOps rather than a different problem sounds like they are avoiding the pager.

• Resume unit of value: DevOps rewards scale and reliability (clusters, services, deploys per day, availability against an SLO). Platform rewards those plus adoption and time removed (services onboarded, teams migrated, provisioning time before and after, old path deleted).
• Coding: DevOps accepts strong scripting plus one language used occasionally. Product-shaped platform roles test a typed language properly, usually Go, with tests and error handling, and sometimes ask you to read code in the languages your internal customers write.
• Design round: DevOps asks you to design a system that must stay up. Platform asks you to design an interface other teams will consume, and marks the escape hatch, the migration plan and the support model as heavily as the architecture.
• Stakeholders: a DevOps loop rarely includes a product engineer. A platform loop usually does, and that round is frequently the one that decides it.
• Success metric in the job itself: DevOps is judged on uptime, delivery speed and cost. Platform is judged on those plus whether anyone uses it, which is why interviewers push on adoption without authority.
• Vocabulary that signals you have worked this way: thinnest viable platform, golden path, escape hatch, cognitive load, self-service, platform SLO, deprecation plan, internal customer research. Use them only where you have the concrete story to back each one, because every one of these terms invites a follow-up.
• The honest overlap: at a company with one infrastructure team, platform engineer and DevOps engineer are the same job with different branding. Saying that out loud in an interview, then asking which shape this team is, reads as experience rather than cynicism.

What gates this job: no licence, a short credential list, and a coding bar people underestimate

Nothing legal gates platform engineering. There is no licence, no protected title, no required degree and no mandatory certification, and plenty of working platform engineers arrived from systems administration, support, backend development, QA, the military or a trade. Degrees still function as filters in graduate programmes at large employers, in parts of government and defence contracting, and in skilled-worker visa routes where a degree or an assessed equivalent counts toward eligibility. Outside those, after two or three years of production experience the credential that replaces any certificate is a system you personally built, operated and can describe in detail: who used it, what it cost, how it failed, and what you changed as a result.

On certifications, be clear-eyed about what each one buys. The Certified Kubernetes Administrator is the most portable because it is performance-based, sat in a live terminal against running clusters, so it cannot be passed by memorising a question bank, and a hiring manager reads it as evidence you have actually typed kubectl under time pressure. CKAD is the better fit if your platform work is application-facing, and CKS if the role leans toward cluster security and admission control, though CKS requires an active CKA first. A cloud certification matching the employer's cloud is mostly a filter pass rather than a signal to the engineers interviewing you. The HashiCorp Terraform Associate is cheap and quick and worth having if infrastructure as code is central to the posting. All of these have renewal windows, so check what you hold is still current before you put it at the top of a resume.

What no certification covers is the thing this job is actually about. There is no exam that demonstrates you designed an internal interface other teams adopted, ran a deprecation without breaking anyone, or decided what not to build. The developer portal ecosystem has no credential that carries hiring weight, and no hiring manager screens on one. That is why a candidate with three months to spend is almost always better off building and documenting one real piece of platform work with a before and after measurement than collecting a second certificate. The CNCF Platforms Working Group has published a platforms white paper and a platform engineering maturity model, and reading them is worth more in an interview than a certification, because they give you the vocabulary hiring managers now use for maturity, funding and measurement.

There are three real gates, and none of them is paperwork. First, cleared work: in US defence and federal contracting a security clearance genuinely gates the job, sponsorship requires an employer, and the timeline is measured in months, so if you have an active clearance, say so near the top of the resume. Second, an implicit experience gate: platform engineer is rarely anyone's first job, because the role assumes you have been an internal customer of someone else's platform and know which parts of it hurt. Third, a headcount gate: a genuine internal developer platform team only exists where there are enough internal engineers to justify it, so if you want shape two specifically, target larger employers and accept that at a small company the same work exists but is called something else and is one third of a broader job.

The coding bar is where good candidates are most often surprised, so be concrete about what to prepare. For Kubernetes-adjacent platform roles, be able to write Go without an assistant: structs and interfaces, errors as values and wrapping, goroutines with context cancellation, a channel used for something that is not a tutorial, table-driven tests, and a program that reads configuration, does work and exits with a useful message. Understand the controller pattern well enough to explain level-triggered reconciliation against desired state, why a controller must be idempotent and tolerate being restarted mid-operation, and what a finalizer is for. Be able to read Python, TypeScript and Java well enough to debug a build for teams who write them, because you cannot build a golden path for a language you cannot read. For portal work, enough TypeScript and React to write a Backstage plugin rather than only to configure one.

• Worth doing if you lack production Kubernetes: CKA, because it is the one certificate that changes how an engineer reads your resume. Practise against real clusters on a timer, not by watching videos.
• Worth doing if the posting is infrastructure-as-code heavy: Terraform Associate, measured in evenings rather than months.
• Worth skipping: a second cloud certification, Agile and Scrum certificates, and anything that certifies a vendor portal. None of these appear in a platform hiring decision.
• Worth reading instead: the CNCF platforms white paper and platform engineering maturity model, Team Topologies for the vocabulary of stream-aligned and platform teams and the thinnest viable platform, the four DORA delivery measures published in Google Cloud's annual DORA report, and the DevEx framework of feedback loops, cognitive load and flow state. Interviewers use these words and expect you to know what they mean.
• Put an active security clearance in the top third of the resume if you have one, with the level and the year of last investigation, because for cleared roles it is the first filter applied.
• If your production Kubernetes exposure is deploying to a cluster someone else runs, say exactly that and own the layer you did own. Interviewers probe control plane, upgrades, networking and etcd within two minutes and an inflated claim collapses immediately.
• Prove the coding bar on the resume, not in adjectives: name the thing you wrote, the language, and who used it. "Wrote the internal CLI in Go that wraps environment provisioning, used by every engineer who deploys, 40 commands, provisioning package covered by tests" is evidence. "Proficient in Go" is not.

How the loop actually runs, and who screens you

A platform engineering process in 2026 typically runs four to six conversations over three to six weeks. The set of things being tested is stable even when the number of calls is not: a recruiter screen, a hiring manager conversation, a technical screen, a practical stage, a platform design round, and a cross-functional round with somebody who would use what you build. Smaller employers compress that into two or three conversations rather than dropping stages, which usually means the design round carries the technical screen inside it. Ask the recruiter for the stage list and whether there is a take-home, because that answer changes how you spend the week.

The recruiter screen is a stack match plus logistics, and it is the cheapest place to find out what the job is. They will check your cloud, your orchestrator, your infrastructure-as-code tool, your language, your on-call expectations and your compensation range. Use your turn to ask whether the team builds the platform or runs the infrastructure, how many engineers are on the team, how many engineers it serves, and whether adoption is mandated or chosen. Those four answers determine everything about how you prepare, and recruiters answer them readily.

The hiring manager conversation is the scope round and it matters more here than in a DevOps loop. They are establishing whether you think in terms of internal customers at all. Expect to be asked what you own today, who depends on it, how you decide what to work on next, how you handle a team that wants something your platform does not do, and what you have deliberately not built. Have two prepared stories: one where you shipped the smallest useful thing and grew it, and one where you said no to a request and what you offered instead. Ask them what the team deleted most recently, because a platform team that has never retired anything is accumulating surface area it cannot support.

The technical screen is conventional and you should not lose it. Linux process, memory and networking fundamentals; why a pod will not start and how you would find out; DNS and service discovery inside a cluster; TLS and certificate rotation; how a rolling update actually proceeds and what a readiness probe does to it; what you look at first when deploys suddenly get slower. Many teams add a code reading exercise here instead of a code writing one, handing you a hundred lines and asking what is wrong with it. Read it out loud and name the assumptions, which is exactly what the job is.

The practical stage takes one of three forms, and the posting or the recruiter will usually tell you which. A take-home: write a reusable Terraform or OpenTofu module with variables, outputs, a pinned provider, remote state guidance, a test, a README with a working example and a stated upgrade path; or build a small Backstage software template or plugin; or write a controller that reconciles a toy custom resource; or write a CLI that provisions something and is pleasant to be wrong with. A live coding round: Go, usually around ninety minutes, with tests expected. A live debugging round: a deliberately broken environment where you are marked on method rather than speed, so narrate your hypotheses, change one thing at a time, and say what evidence would disconfirm you.

The platform design round is the round that decides product-shaped loops, and the next section covers it on its own because it is where most rejections happen. The cross-functional round that follows is often misread as a culture chat. It is not. A staff engineer from a stream-aligned team is deciding whether working with you would be faster or slower than working around you. Ask what their last three pieces of infrastructure friction were, listen properly, and resist the urge to design a solution in the room before you understand their constraints. The behaviour they are watching for is curiosity about their problem rather than enthusiasm about your model.

Two practical notes on the process. First, take-homes in this discipline are frequently over-scoped by the employer and under-timeboxed by the candidate: ask what the expected time is, hold to it, and write in the README what you would do next and what you deliberately left out, because that note is often read more carefully than the code. Second, if a loop contains no round where a potential internal customer talks to you, that is informative. It usually means the platform is funded as infrastructure and measured on uptime, which is a fine job but a different one from the posting's language.

• Bring to every round: one architecture diagram of something you built, one before-and-after number for provisioning or deployment time, one adoption figure, one incident you owned, and one thing you refused to build.
• Expected stage count: two to three conversations at a small employer, four to six at a large one. Ask whether a take-home is part of it rather than guessing, and ask what the expected effort is in hours.
• If the take-home is a Terraform module, the reviewer is looking for a versioned interface, no hardcoded account identifiers, no committed state, no plaintext secret, sane defaults, a test, and a README someone could use without asking you a question. Polish the README last and hardest.
• If the take-home is a Backstage template or plugin, scope it tiny and finish it. A working template that scaffolds a repository with CI, ownership metadata and a deployable manifest beats an ambitious half-built plugin.
• In the live debugging round, say your hypothesis before you type, and when evidence contradicts it, say so and change direction. Guessing confidently and then quietly reversing is the behaviour that fails this round.
• Ask every interviewer the same two questions and compare the answers: who gets paged when a service built on the platform breaks, and how does a team get something the platform cannot currently do. Inconsistent answers across a loop tell you the support model does not exist yet.
• Red flag in the process itself: a loop with no practical stage at all for a product-shaped platform role. It often means the team is not yet building anything and the title is aspirational.

The resume: which internal developer platform work to describe, and how

Platform resumes fail in a specific and predictable way. They contain the sentence "built an internal developer platform" with no indication of what was in it, who used it, or what got faster. A reviewer reads that as "we wrote some Terraform and a Confluence page", because that is what it most often means. The fix is mechanical: every platform claim gets a component, an internal customer count, a before and after, and where possible a thing that was retired as a result.

Use this bullet shape and fill in your own real figures, because the ones here are only a worked example. Component, who used it, what it replaced, the measured change, and the retirement. "Built a self-service environment provisioning workflow (Terraform modules behind a Go CLI and a Backstage template) used by 14 teams and 180 engineers; environment provisioning went from a ticket with a two to five day wait to a self-service action completing in about twelve minutes; retired the manual request queue and the runbook it depended on." Every element of that sentence survives a follow-up question, and each one invites the interviewer to ask about something you know well. Compare it to "responsible for internal developer platform and self-service tooling", which invites nothing.

The time metrics that reviewers actually respond to are narrow, so learn their names. Time from an empty repository to that service serving traffic in production, which some teams call time to first deploy and others call time to hello world. Provisioning lead time for an environment, a database, a queue, a bucket or a DNS record. Onboarding time to a new engineer's first merged change in production. Lead time for changes and deployment frequency from the DORA delivery measures, which your interviewer already thinks in. Pipeline p95 wall-clock time and pipeline success rate. Interrupt load, meaning how many support requests per week the platform team absorbed before and after you made something self-service. If nobody measured, state the shape honestly rather than inventing a figure: "from a ticket and a multi-day wait to the same day, self-service" is credible and survives questioning, and a fabricated percentage does not.

Adoption is the evidence that separates this resume from a DevOps resume, and retirement is the strongest form of it. Say how many services onboarded out of how many exist, how many teams migrated and over what period, how many repositories consume the current major version of your module, and what share of production deployments now go through the paved road. Then say what you deleted: the old pipeline, the hand-maintained cluster, the wiki runbook, the bespoke per-team Helm charts. Deleting the old path proves adoption was real rather than announced, and it is the single line most likely to get you asked to talk for five minutes.

Do not drop the operational evidence, because your platform is production for people who cannot choose another supplier. State the platform's own service level objective and attainment, not just the applications' SLOs: the availability of the control plane or provisioning API, the success rate of the deployment path, the availability of CI, and what happened when the error budget was spent. Include cost in two directions: the cloud and CI spend you removed, and the spend you made visible and attributable per team, because cost attribution is a platform capability that engineering leaders ask for constantly and few candidates mention.

The artefacts that survive screening are the ones a reviewer can picture. A versioned module with a documented interface, tests and an upgrade guide. A Backstage software template that scaffolds a service with CI, ownership metadata, observability wiring and a deployable manifest already correct. A custom resource definition and controller you wrote, with the reconciliation described in one sentence. A service catalog with ownership data accurate enough to page the right team. A production readiness scorecard that teams actually look at. A design document or internal RFC you wrote and got agreement on across teams. A deprecation plan you executed to completion. Each of these is a five-minute interview answer waiting to happen.

Now the parts that get ignored or actively cost you. A sixty-item comma-separated skills list is skimmed and discounted: group it by category and cut anything you would not want to be interviewed on. "Agile", "Scrum" and "stakeholder management" as skills add nothing. Responsibility statements with no result add nothing. A career objective paragraph is pure cost. Certifications belong in a short line near the end. Listing a developer portal you only ran the demo application of is a trap, because the first question is which plugin you wrote or which entity model you designed. And never let the resume and the LinkedIn profile disagree on a figure, which is an easy and common rejection.

• Summary format that works, with your own figures substituted for these: "Platform engineer, 7 years. Built and ran the internal deployment and provisioning platform for 220 engineers across 90 services on AWS and Kubernetes. Took time from new repository to production from 3 weeks to 1 day, moved 80 of 90 services onto the paved road and deleted the previous pipeline, on call for the platform throughout."
• Name the interface maturity rather than the tool: semantic versioning on modules, a documented upgrade path, deprecation warnings in plan output, policy checks in the pipeline, plan posted to the pull request, no manual console changes. These phrases tell a reviewer you have had real consumers.
• Name the self-service surface: what a developer can get without talking to you, how long it takes, and what still requires a human and why. Honesty about what is not self-service yet reads as maturity.
• Include a golden path line: the single supported route from repository to production, what it gives you for free (CI, ownership metadata, observability, secrets, a dashboard, an SLO starter), and the documented escape hatch for teams it does not fit.
• Include an identity and secrets line: workload identity federation instead of static cloud keys, short-lived credentials from OIDC in CI, a real secret manager rather than CI variables, least-privilege roles you actually tightened. This is standard in postings now.
• Include a supply chain line if you have one: SBOM generation, image signing, build provenance, base images pinned by digest, third-party CI actions pinned to a commit SHA, admission control rejecting unsigned images.
• Keep the portfolio to one page per project: a diagram, the interface, the before and after number, and the deprecation plan. For platform work a diagram plus a cost line plus a runbook communicates more than any prose.
• If your platform had low adoption, put it on the resume anyway with the honest reason and what you learned. "Built a deployment abstraction that three of eleven teams adopted; the blocker was that it could not express their batch workloads, so the second version exposed the underlying job spec and adoption reached nine" is a stronger interview story than a success with no obstacle in it.

The platform design round: what reviewers are actually marking

The prompts repeat across employers. Design the path from an empty repository to production for three hundred engineers. A product team needs a Postgres database in an hour rather than a week, design that. Design multi-tenant Kubernetes for fifty teams. We have eight hundred services and no reliable ownership data, what do you do first. Design the deployment experience so a team can release on their own on a Friday afternoon. Each of these is deliberately under-specified, and the first thing being marked is whether you ask who the users are and what they do today before you start drawing.

Six things are being scored, and in most loops the architecture is not the heaviest of them. First, scoping: can you identify the thinnest viable platform that solves the stated pain, rather than proposing a portal, a control plane, a service mesh and a multi-region active-active topology for a company with forty engineers. Second, the interface: what exactly does a developer type or click, what do they get back, what do they never have to know. Third, the escape hatch. Fourth, migration and deprecation: how the existing eight hundred services get there, in what order, and who pays for the work. Fifth, the operating model: who is on call, how support requests arrive, what the platform's own SLO is. Sixth, cost, both the cloud bill and the team size required to sustain what you just proposed.

The escape hatch deserves its own paragraph because missing it is the most common single fail. An abstraction with no documented way out gets abandoned by the first team with an unusual requirement, and that team builds a shadow platform, and now you support two. Say how the layer underneath stays reachable: the generated manifests are readable and reviewable rather than hidden, the module exposes the raw resource as an output, there is a documented path for a team that needs something the abstraction cannot express, and the platform does not forbid what it cannot yet model. Then say how you harvest those exceptions back into the product, because a well-run platform treats every escape as a feature request with evidence attached. Candidates who describe the platform as mandatory and complete sound like they have never had a real internal customer.

Build versus buy comes up in almost every one of these rounds, usually as a portal question: Backstage, a commercial portal, or nothing. The answer that scores is about team size and sustained maintenance, not product preference. A self-hosted Backstage deployment is a TypeScript application your team now owns, upgrades and extends, which is reasonable with dedicated engineers and unreasonable as a side project for two people. A commercial portal removes that maintenance and adds a procurement and lock-in conversation. And state the thing most candidates miss: the hard part of a developer portal is not the user interface, it is the catalog data, because ownership metadata goes stale the moment it is not generated from something that must be correct for another reason. A portal with wrong ownership data is worse than no portal, because people stop trusting it and you cannot page the right team.

Multi-tenancy comes up almost as often, so have a position. Namespace per team in a shared cluster is cheap and leaks: noisy neighbours, shared ingress blast radius, cluster-scoped resources like custom resource definitions and webhooks that one team can break for everyone, and a shared upgrade that must suit all tenants. Cluster per team is isolated and expensive in both money and upgrade toil, and it pushes you toward fleet management. Virtual clusters sit in between and buy control plane isolation without full duplication. Whatever you pick, be able to state the defaults you would set on day one: resource requests and limits, quotas, network policy denying cross-namespace traffic by default, pod security standards, who may create a cluster-scoped object, and how you upgrade without asking fifty teams for permission.

A workable structure for forty-five minutes. Spend the first five on clarifying questions: how many engineers, how many services, what languages, what they do today and how long it takes, what hurts most, who funds this. Spend five stating the one or two outcomes you will optimise and how you would measure them, which immediately separates you from candidates who optimise nothing in particular. Spend twenty on the interface and the end-to-end flow, drawing what the developer does and what happens behind it. Spend ten on migration, support model and cost. Keep the last five for what you would not build, what you would kill, and what you would measure after three months to decide whether this was worth it.

• Open with the users, not the architecture: "Before I draw anything, who are the developers, what do they do today to get to production, and how long does it take them?" This single habit lifts the round.
• Name the one metric the design optimises, out loud: time from repository to production, provisioning lead time, or change failure rate. Then design against it, and say what you are trading away.
• Always state the escape hatch explicitly, and how exceptions feed back into the roadmap. Omitting it is the most common fail in this round.
• Always state who gets paged. The defensible answer is that the owning team is paged for their service and the platform team is paged for the platform, with a clear boundary written down and a shared channel for the cases where the boundary is unclear.
• Always state a migration order and who does the work: a pilot team, then the ten easiest services, then the hard ones with the platform team doing the first few migrations by hand to learn what breaks, with a named date for deleting the old path.
• Always state the sustaining cost: how many engineers this needs to run, what the support rota looks like, and what you would drop if the team lost a person.
• Avoid: proposing a service mesh, a bespoke framework, a custom orchestrator or a new programming interface when sensible defaults in a template and a module would do. Over-building is read as a risk to the hiring team's roadmap.
• Finish with what you would not build and what you would measure in ninety days. Interviewers remember the ending, and judgement about scope is the scarcest quality in this round.

The questions that decide it, and how to answer them

"What is the difference between platform engineering and DevOps?" This is a screening question for whether you understand the job you applied to. The answer that works is short and then specific: DevOps is a set of practices for getting software to production safely and the title usually means operating shared infrastructure, while platform engineering means building and running an internal product whose users are your own engineers, so it is measured on adoption and on developer time saved as well as on uptime. Then add the honest caveat, which marks you as experienced: at many companies the two titles are the same job, so you would want to know which this team is. Avoid the answer that platform engineering is the evolved or senior form of DevOps, which sounds like a status claim rather than a distinction.

"Your platform has low adoption after a year. What do you do?" They are testing whether your instinct is to mandate or to investigate. Start with measurement: who is not using it and what they use instead, because the alternative teams chose tells you what your product is missing. Then go and sit with two of those teams and watch them deploy, which finds things no survey does. Then pick the single biggest blocker and fix it rather than adding features. Then reduce the switching cost, usually by doing the first migration for a team yourself. Mandates are the last resort and only work with executive sponsorship and a deadline for deleting the old path, and even then they produce compliance rather than advocacy. Have a real story here if you possibly can, including one where the answer was that you had built the wrong thing.

"A team needs something your abstraction cannot express. What do you do?" The answer is a sequence, not a principle. Unblock them now through the escape hatch, with a review rather than a refusal. Write down the requirement as evidence. If a second team asks for the same thing, it belongs in the product. If no second team asks, leave it as an exception and do not grow the interface for one consumer. Say the quiet part: every option you add to a platform interface is permanent, because somebody will depend on it, so the bar for adding one is higher than the bar for allowing an exception.

"How would you deprecate v1 of a module two hundred repositories depend on?" This is the interface design question and a weak answer costs the round. Ship v2 alongside v1 rather than in place of it. Announce with a timeline that is realistically a quarter or more, not a sprint. Make the migration mechanical: a documented upgrade path, an automated change where possible, and a pull request raised by you against the busiest consumers. Add deprecation warnings into the output engineers already read, which for Terraform means plan output rather than a wiki page. Measure remaining v1 consumers weekly and publish the number. Stop new adoption of v1 first, which is cheap and immediate. Keep a hard removal date and move it only once, publicly. Do not break anyone's release to make a point about hygiene.

"Who gets paged when a service built on your platform breaks?" The expected answer is the owning team for their own service and the platform team for the platform, with the boundary written down in advance and a defined path for the cases where nobody can tell which it is. Then add the thing that distinguishes a candidate who has lived it: the platform team's real failure mode is absorbing other teams' debugging because the platform makes failures hard to attribute, so you invest in error messages, logs and dashboards that tell a developer it was their code rather than your platform. That investment is the difference between a sustainable platform team and one that becomes a help desk.

"How do you know whether the platform is working?" Give three families and one caution. Delivery outcomes: deployment frequency, lead time for changes, change failure rate, time to restore service. Platform-specific measures: adoption and the share of production deployments through the paved road, time from repository to production, provisioning lead time, self-service ratio, and the platform's own availability against its SLO. Experience measures: a short periodic developer survey plus interrupt and support volume, which the DevEx framework organises as feedback loops, cognitive load and flow state. The caution that earns credit: none of these should become an individual performance metric, because the moment deployment frequency is used to rank engineers it stops measuring anything.

Expect a review exercise too, because reviewing is now the scarce skill. You will be handed a Terraform plan or a pull request and asked what concerns you. Name the dangerous lines out loud: destroy and replace on anything stateful, "forces replacement" on a database or a volume, a count or for_each change that re-indexes existing resources, a security group rule opened to the whole internet, an IAM policy with a wildcard action, a removed lifecycle protection, a resource limit deleted to stop an out-of-memory kill, a pinned dependency silently floated to a tag. Then say what guardrail you would add so that class of mistake becomes impossible rather than merely noticed, which is the platform engineer's answer rather than the reviewer's.

• Have one story about something you built that nobody used, and what you concluded. Interviewers ask for it directly now, and a candidate with no failed platform project has either not built much or is not being straight.
• Have one story about saying no, including what you offered instead and whether the relationship survived.
• Have one incident story where the platform itself was the cause, with the blast radius, how you found it, and the guardrail that followed. Never blame a named person, and never present a flawless record.
• Have one cost story with a mechanism and a before and after, in your own real numbers: idle non-production capacity, cross-zone traffic between chatty services, oversized requests on every pod, CI minutes burned by a test suite nobody had profiled.
• Prepare the Team Topologies vocabulary if the employer uses it: stream-aligned, enabling, complicated-subsystem and platform teams, and the difference between collaborating with a team and offering them something as a service. Several hiring managers interview straight out of this model.
• When you do not know something, say so and say how you would find out. In this discipline the admission costs almost nothing and the bluff is detected within two follow-up questions.

Getting in without a platform title yet, and reading the offer

Platform engineer is rarely a first job, and the reason is structural rather than gatekeeping: the role assumes you have been somebody else's internal customer and know which parts of that experience hurt. The realistic routes in are four. From DevOps, SRE or cloud operations, which is the shortest hop and where the gap to close is the coding bar and product thinking rather than infrastructure. From backend development, which is the strongest route into product-shaped platform teams because the coding bar is already met and the gap is production operations, and the move is often immediate. From QA, test infrastructure or release engineering into developer productivity and build engineering, which is a natural and under-contested path. From data engineering into data platform work, where your domain knowledge is the scarce part.

The highest-yield move is internal, at an employer that already has a platform team. You already know the friction, you already have credibility with the teams the platform serves, and platform teams preferentially hire people who have felt the pain they are solving. The practical approach is to do platform work before you have the title: find the piece of friction your own team complains about most, and fix it as a product rather than as a favour.

That last sentence is the whole strategy, so here is the concrete version. Pick one friction, for example that creating a new service takes two weeks of copying from another repository and asking three people for help. Interview three colleagues about what they actually do, and write down the steps and the waiting. Measure the current time properly. Ship the smallest thing that removes most of the waiting, which is usually a template plus a module plus a page of documentation, not a portal. Measure again. Get one other team to adopt it and watch them use it without helping, which is where you learn what is wrong. Write it up in one page with the before and after. You now have the exact artefact the design round and the product conversation are asking for, and you can say the words adoption, escape hatch and deprecation with a real story behind each. This is worth considerably more than a second certification, and it is usually two to six weeks of work.

Public evidence helps if it is small and finished. A Terraform or OpenTofu module published with a versioned interface, tests, a README and an upgrade note. A Backstage plugin or software template. A Crossplane composition or a Kratix promise that provisions something real. A controller built with kubebuilder that reconciles one resource properly, including idempotency and status conditions. A contribution to an infrastructure project, which carries extra weight because it proves you can work inside someone else's code review standards. One finished small thing beats three abandoned ambitious ones, and a README that explains the design decision is read more often than the code.

On the offer, ask the questions that reveal what the job actually is, because this title hides more variation than most. Is adoption of the platform mandated or chosen, and what happens when a team refuses. How many engineers are on the team and how many engineers does it serve. Who is on call for what, is there a support rota or do interrupts land on whoever is free, and how many interrupts does a typical week contain. Does the team control its own roadmap or is the roadmap a ticket queue. What has the team deleted in the last year. How is the platform funded, and whose budget. What fraction of the team's time goes to running existing infrastructure versus building. A clear answer to that last question is the single best predictor of whether this is shape one or shape two.

The warning signs are consistent. A platform team of three serving four hundred engineers with a mandate and no support rota is a burnout posting whatever the compensation. A team whose roadmap is entirely a ticket queue is an internal help desk with a better title. A platform with no evidence of internal customer research will have adoption problems you will be blamed for. A posting that lists every technology in the cloud native landscape is either copied from somewhere or describing three jobs. And a team that has never retired anything is carrying surface area it cannot support, which becomes your on-call.

One narrow point about levelling and pay. Because product-shaped platform teams sit on the software engineering ladder at many employers and operations-shaped teams sit on an infrastructure ladder, the same person with the same skills can be banded differently by two companies using the same job title. Ask which ladder and which level the role maps to before you discuss numbers, and verify the posted range where pay-transparency law requires one. That question is routine and nobody will think less of you for asking it.

• Shortest route from DevOps or SRE: close the coding gap deliberately. Write one real Go program with tests and one controller, and get one piece of internal tooling adopted by a team that is not yours.
• Shortest route from backend development: close the operations gap. Carry a pager for something, own one production incident end to end, and learn the cloud account and the cluster rather than only the application.
• Shortest route from QA or release engineering: aim at developer productivity rather than runtime platform. Build times, flaky test quarantine, test selection and CI reliability are measurable, under-contested and highly valued.
• Search these titles, not only Platform Engineer: Internal Developer Platform Engineer, Developer Experience Engineer, Developer Productivity Engineer, Infrastructure Engineer, Build Engineer, Production Engineer, Systems Engineer, Data Platform Engineer, ML Platform Engineer. Restricting the search to one title misses a large part of the market.
• Ask for the on-call details in writing before you accept: rotation size, frequency, compensation or time back, paging volume in the last month, and who is secondary.
• If you are moving internally, ask the platform team for one small piece of work as a loan or a fixed-term rotation. It converts into a transfer far more often than an application does.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Platform Engineer
• Platform Engineering
• Internal Developer Platform
• IDP
• Developer Experience Engineer
• Developer Productivity Engineer
• Infrastructure Engineer
• Build Engineer
• Production Engineer
• Site Reliability Engineer
• DevOps Engineer
• Cloud Engineer
• Data Platform Engineer
• ML Platform Engineer
• Platform as a product
• Golden path
• Paved road
• Self-service infrastructure
• Developer self-service
• Thinnest viable platform
• Cognitive load
• Developer experience
• DevEx
• DevEx framework
• Internal customer
• Platform adoption
• Escape hatch
• Deprecation plan
• Internal RFC
• Design document
• Backstage
• Software templates
• Scaffolder
• Backstage plugin
• Service catalog
• Ownership metadata
• TechDocs
• Port
• Cortex
• OpsLevel
• Atlassian Compass
• Developer portal
• Scorecards
• Production readiness review
• Crossplane
• Composition
• Kratix
• Radius
• Score specification
• Platform orchestrator
• Control plane
• Custom resource definition
• CRD
• Kubernetes operator
• controller-runtime
• kubebuilder
• Operator SDK
• Reconciliation loop
• Admission webhook
• Cluster API
• Multi-tenancy
• vcluster
• Namespace isolation
• Resource quota
• LimitRange
• Network policy
• Pod Security Admission
• Gateway API
• Kubernetes
• EKS
• AKS
• GKE
• OpenShift
• Helm
• Kustomize
• Argo CD
• Flux
• GitOps
• App of apps
• Progressive delivery
• Argo Rollouts
• Canary release
• Blue/green deployment
• Feature flags
• Infrastructure as code
• Terraform
• OpenTofu
• Terraform modules
• Module versioning
• Remote state
• State locking
• Terragrunt
• Pulumi
• AWS CDK
• CloudFormation
• Ansible
• Packer
• Policy as code
• Open Policy Agent
• Rego
• Conftest
• Kyverno
• Drift detection
• CI/CD
• GitHub Actions
• GitLab CI
• Jenkins
• Buildkite
• CircleCI
• Azure DevOps
• Merge queue
• Monorepo
• Bazel
• Remote caching
• Remote execution
• Nx
• Turborepo
• Gradle
• Pants
• Buck2
• Hermetic builds
• Test selection
• Test impact analysis
• Flaky tests
• Build times
• Inner loop
• Devcontainers
• Ephemeral environments
• Preview environments
• Coder
• Gitpod
• GitHub Codespaces
• Go
• Golang
• Python
• TypeScript
• React
• Java
• Bash
• Linux
• systemd
• Networking
• DNS
• TLS
• AWS
• Amazon Web Services
• Azure
• Google Cloud Platform
• VPC
• IAM
• Least privilege
• OIDC federation
• Workload identity
• SPIFFE
• SPIRE
• HashiCorp Vault
• External Secrets Operator
• Secrets management
• Short-lived credentials
• Machine identity
• Audit trail
• Observability
• OpenTelemetry
• Prometheus
• Grafana
• Distributed tracing
• Structured logging
• SLO
• SLI
• Error budget
• Platform SLO
• Incident response
• Blameless postmortem
• Runbook
• On-call
• PagerDuty
• Toil reduction
• Support rota
• DORA metrics
• Deployment frequency
• Lead time for changes
• Change failure rate
• Time to restore service
• Time to first deploy
• Provisioning lead time
• Onboarding time
• Self-service ratio
• FinOps
• Cloud cost optimization
• Cost attribution
• Showback
• Kubecost
• OpenCost
• Karpenter
• Spot instances
• Autoscaling
• Capacity planning
• GPU scheduling
• Accelerator quota
• Inference serving
• Model serving
• vLLM
• KServe
• Ray
• LLM gateway
• Rate limiting
• Spend caps
• Evaluation pipeline
• MLOps
• Vector database
• Retrieval
• AI coding agents
• Agent identity
• Human approval gate
• Sandboxed environments
• Software supply chain
• SBOM
• Sigstore
• Cosign
• Build provenance
• SLSA
• Image signing
• Trivy
• Team Topologies
• Stream-aligned team
• Enabling team
• Platform team
• Migration plan
• Semantic versioning
• Backward compatibility
• API design
• CNCF
• Platform engineering maturity model
• CKA
• Certified Kubernetes Administrator
• CKAD
• CKS
• HashiCorp Terraform Associate
• AWS Certified Solutions Architect
• AZ-104
• AZ-400
• SOC 2
• FedRAMP
• Change management

Mistakes that cost people this job

Questions people ask