Platform Engineer interview questions

A platform team builds reusable services and workflows that developers can consume without opening a ticket.

• DevOps is a way of sharing delivery and operations responsibility, not necessarily a separate product team.
• A platform team turns repeated tasks such as service creation into supported self-service capabilities.
• Its output is judged by developer use and reduced friction, not only by infrastructure uptime.

Platform engineering improves the supported path developers use, while SRE focuses on service reliability and operational risk.

• A platform engineer may provide a Kubernetes deployment template with safe defaults.
• An SRE may define an SLO, investigate error-budget burn, and improve incident response.
• The teams can share tooling, but their primary users and outcomes differ.

The platform provides working capabilities, while the portal is one interface through which developers discover and use them.

• The platform can include CI workflows, Kubernetes environments, secrets, and observability.
• A portal such as Backstage can show services, documentation, templates, and links to those capabilities.
• A polished portal without functioning workflows is not an internal developer platform.

It means treating internal developers as users whose recurring problems guide platform work.

• The team learns how developers create, deploy, and debug services before choosing a solution.
• Capabilities need documentation, support, ownership, and a usable lifecycle like external products.
• Feedback and adoption determine whether an addition solved the problem.

A capability is self-service when a developer can complete a supported task safely without waiting for a platform engineer.

• The input and result are clear, such as creating a repository and test environment from a template.
• Validation rejects unsafe values early and explains how to correct them.
• Documentation and observable status let the developer understand progress and failures.

They are well-supported ways to complete common work with working defaults and minimal decisions.

• A service template can provide CI, deployment, ownership metadata, and dashboards together.
• Developers may leave the path when their service has a valid need, so it is guidance rather than a trap.
• The platform team maintains the path as tools and developer needs change.

An escape hatch lets a team handle a legitimate exception without bypassing all platform safety controls.

• A service needing a special runtime may supply a reviewed custom manifest instead of the default template.
• The exception should have an owner and a documented reason so support boundaries stay clear.
• Repeated exceptions are evidence that the standard workflow may need a new supported option.

A service catalog gives one searchable record of software components and the people responsible for them.

• A developer can find the repository, documentation, dashboard, and support contact for a service.
• Ownership data shortens routing during a failed deployment or dependency question.
• Catalog entries must be updated with the service lifecycle or they quickly lose trust.

A useful entry names the service owner, lifecycle, system, repository, and support contact.

• The owner should be a maintained team identifier rather than one person who may leave.
• Lifecycle values such as experimental, production, or deprecated set user expectations.
• Links to a runbook and dashboard give developers a direct debugging path.

Backstage can combine a software catalog, documentation, templates, and links to engineering tools.

• Catalog descriptors connect components to owners, systems, and lifecycle metadata.
• Software Templates can create a repository and apply the platform team’s supported starting structure.
• Plugins can surface CI status or Grafana links without moving the underlying systems into Backstage.

Templates make common service setup repeatable and include platform defaults from the first commit.

• They can create CI configuration, ownership metadata, a container build, and deployment manifests together.
• Required inputs such as service name and owner are validated once instead of copied by hand.
• A template needs versioned maintenance because stale dependencies spread to every new service.

Platform documentation should let a developer complete one workflow and recover from its common failures.

• A quick start lists prerequisites, exact inputs, expected output, and a verification step.
• Troubleshooting maps visible symptoms to checks rather than saying only to contact the platform team.
• Examples should use the current template and be tested when the workflow changes.

I collect feedback immediately after a developer uses a workflow and attach it to the exact step that caused friction.

• A short form can ask whether the task completed, how long it took, and what blocked it.
• Support requests reveal repeated failures that developers may not report in a survey.
• I confirm proposed fixes with the affected developer before treating the issue as solved.

A useful first signal is the percentage of started service creations that reach a healthy test deployment without manual platform help.

• Completion shows more than page views because it measures the intended developer outcome.
• Time from template start to healthy deployment exposes slow or confusing steps.
• Support requests for the workflow add context when the completion rate falls.

A container is an isolated process packaged with the application files and runtime dependencies it needs.

• It shares the host kernel, so it is lighter than a full virtual machine.
• The same image can run in CI, a developer environment, and Kubernetes, reducing environmental differences.
• The platform still supplies runtime configuration, secrets, networking, and resource boundaries.

An image is an immutable package, while a container is a running instance created from that package.

• The platform build produces and tags an image once for later deployment.
• Kubernetes can start several containers from the same image for one service.
• Changes made inside a running container disappear when it is replaced unless data uses persistent storage.

Each Dockerfile instruction can create a cached layer, so stable steps should come before frequently changing source files.

• Copying dependency manifests before application code lets dependency installation reuse the cache.
• A small final image reduces registry transfer time and unnecessary packages.
• The same Dockerfile in CI makes image creation repeatable for every developer.

A Pod is the smallest Kubernetes unit that runs one or more tightly coupled containers together.

• Containers in a Pod share its network identity and can share mounted volumes.
• A service template usually creates Pods through a Deployment rather than asking developers to manage them directly.
• Pods are replaceable, so application state should not depend on one Pod surviving.

A Deployment maintains the requested number of application Pods and updates them from a declared Pod template.

• Its replica count expresses how many Pod copies the platform should keep running.
• Changing the image starts a controlled rollout and records a new revision.
• If a Pod disappears, the Deployment controller creates a replacement.

A Service gives a stable network address for a changing set of selected Pods.

• Its selector finds Pods through labels rather than fixed Pod IP addresses.
• The Service port is the port clients call, while targetPort is where the container listens.
• A platform template can create the Service consistently so teams do not hand-wire discovery.