Career roadmap

Platform Engineer

Build the internal product that other engineers ship on: paved roads, self-service, and sane defaults.

Time: 7-10 months part-time
Entry bar: DevOps or backend experience. You are building a product, so software skills matter.
Stages: 5 · 25 topics

0/25 studied0%

Before you start Platform

4-5 weeks · 0/5 topics

The distinguishing idea: your users are engineers, and they can route around you.

Adoption is voluntary in practice. That single fact reshapes how the work is done.
- Identifying your users and their jobs
- Golden paths, not golden cages
- Measuring adoption and satisfaction
- Deprecating internal tools humanely
Time from idea to production is the metric platform teams are judged on.
- Lead time and DORA metrics
- Local development environments
- Feedback loop speed
- Cognitive load as a design constraint
The organisational theory that platform interviews reference constantly.
- Stream-aligned, platform, enabling teams
- Interaction modes and collaboration cost
- Conway's law in practice
- Ownership boundaries
Every ticket queue is a design failure. The interview asks how you remove them.
- Templates and scaffolding
- Provisioning APIs and portals
- Guardrails over gatekeeping
- Escape hatches for edge cases
For an internal platform, the docs are most of the product.
- Getting started in under ten minutes
- Runbooks and troubleshooting guides
- Reference vs tutorial vs explanation
- Keeping docs current automatically

BuildInterview five engineers about their delivery friction and write a prioritised platform backlog.

6-7 weeks · 0/5 topics

Build the machinery that takes a service from repository to production without a human gate.

You are not running apps on it, you are running a platform on it. Different depth required.
- Multi-tenancy and namespace isolation
- Resource quotas and limit ranges
- Cluster upgrade strategy
- Node pools and workload placement
Argo CD across hundreds of services needs structure that a single app does not.
- App-of-apps and ApplicationSets
- Repository structure for many teams
- Promotion between environments
- Handling drift and manual overrides
The paved road made concrete: a new service with everything wired up.
- Backstage software templates
- Cookiecutter and repo bootstrapping
- Template versioning and updates
- Opinionated defaults with overrides
Reusable pipelines that teams adopt instead of copying and diverging.
- Reusable workflows and shared actions
- Standard build, test, scan, deploy stages
- Pipeline versioning and migration
- Build caching across teams
Ephemeral environments per pull request are a signature platform capability.
- Preview environments and lifecycle
- Test data seeding
- Cost control and reaping
- Environment parity with production

BuildA scaffolding command that creates a repo, pipeline, environment and dashboard in one step.

6-7 weeks · 0/5 topics

Platform engineering is software engineering. This stage is where the title is earned.

The lingua franca of infrastructure software, and usually the coding round language.
- Go concurrency, contexts and errors
- Writing CLIs with good ergonomics
- Testing and dependency injection
- Distributing binaries
Extending Kubernetes is the most distinctive platform engineering skill.
- Custom resource definitions
- Controller runtime and reconciliation loops
- Idempotency and status subresources
- Finalizers and cleanup
Backstage or equivalent as the front door to everything you built.
- Service catalogue and ownership metadata
- Software templates and plugins
- Tech docs integration
- Scorecards and standards tracking
Treating infrastructure capability as an API is what makes it composable.
- Declarative APIs over imperative scripts
- Versioning and backwards compatibility
- Authorisation for platform actions
- Audit logging of platform operations
A bug in the platform breaks every team at once. Testing standards are higher.
- envtest and integration testing controllers
- Contract tests for platform APIs
- Canary rollout of platform changes
- Backwards compatibility guarantees

BuildWrite a Kubernetes operator or a provisioning API that another team uses in production.

4-6 weeks · 0/5 topics

You now have internal customers with expectations, and an SLO of your own.

When the platform is down, every team is down. Reliability requirements are strict.
- SLOs for platform services
- Blast radius of platform changes
- Staged rollout across tenants
- Degraded mode operation
Give teams telemetry by default rather than asking them to instrument from scratch.
- Auto-instrumentation and sidecars
- Default dashboards per service
- Standard alert bundles
- Telemetry cost attribution
The platform is the cheapest place to enforce security once for everybody.
- Workload identity by default
- Image signing and admission control
- Network policy defaults
- Secret injection patterns
Platform teams usually own the cloud bill conversation, whether they wanted to or not.
- Per-team cost attribution
- Right-sizing recommendations
- Idle resource reaping
- Showback dashboards
Without a support model, platform engineers become a human help desk.
- Office hours and support rotation
- Escalation paths and SLAs
- Turning repeat questions into docs or features
- Managing feature requests

BuildPublish a platform SLO, an on-call rotation and a support model, then run it for a month.

3-5 weeks · 0/5 topics

Platform interviews test coding, Kubernetes depth, and product judgement together.

Usually Go, usually something operational rather than an algorithm puzzle.
- Writing a small controller or CLI
- Concurrency and error handling
- API design in code
- Tests that demonstrate judgement
Expect internals questions, not just kubectl usage.
- What happens when you apply a manifest
- Scheduler and controller behaviour
- Admission webhooks
- Debugging cluster-level problems
Design an internal deployment platform for fifty teams. Adoption is part of the answer.
- Multi-tenancy model
- Self-service boundaries and guardrails
- Migration from existing tooling
- Measuring success
What distinguishes platform from DevOps interviews: they ask what you would not build.
- Prioritising a platform backlog
- Build vs buy decisions
- Handling a team that refuses the paved road
- Sunsetting a tool people still use
Influence and adoption stories, with numbers where you have them.
- A platform capability teams actually adopted
- A migration you drove across teams
- Reducing lead time measurably
- Handling internal customer conflict

BuildAn open-source operator or platform tool with documentation and tests.

The fastest-growing rebrand of infrastructure work. Companies past about fifty engineers hire for it explicitly, and it pays like senior backend.

Content last reviewed 2026-08-31. Guidance only — no institute or paid placement is endorsed anywhere in this book.