Platform Engineer Interview Questions

I treat an internal developer platform as a product with engineers as its users, which means applying the same user research, iteration, and feedback loops that product teams use externally. The most important thing a platform team can do is reduce cognitive load: every decision a developer does not have to make about infrastructure is a decision they can spend on their actual problem. A successful platform has a clear golden path, a well-documented, opinionated default way to deploy and operate a service, but it does not force developers to use it for every case. The golden path should handle 80% of use cases with minimal friction. For the remaining 20%, the platform should provide escape hatches that are well-documented and do not require a ticket to the platform team. The biggest failure mode I see is platform teams building infrastructure for themselves rather than for their users. I check adoption rates and developer satisfaction scores regularly and treat low adoption as a bug, not a criticism of developers.

A CI/CD pipeline that scales across teams has to balance standardisation with flexibility. My approach is to define a set of reusable pipeline templates covering the most common patterns: build and test a service, build and push a container image, deploy to a Kubernetes cluster with rollback capability. These templates are maintained centrally by the platform team and versioned, so teams consume a tagged version rather than a floating reference. Within each template there are well-documented extension points where teams can add custom steps without forking the entire pipeline. I also invest in fast feedback: pipelines that take 20 minutes to complete will be worked around rather than used. I target a 5-minute feedback loop for unit tests and linting, and reserve longer integration and end-to-end tests for pre-merge gates rather than blocking every commit. For deployment pipelines I use a progressive delivery approach: automatic rollout to staging, manual approval gate for production, and automatic rollback if error rates exceed a threshold within the first ten minutes.

I think about observability in terms of the three pillars, metrics, logs, and traces, but the goal is always to be able to answer "why is this slow or broken?" without having to deploy new code. For metrics I instrument services with RED metrics (Rate, Errors, Duration) as a baseline, because these three cover the most common failure modes and map directly to user experience. For logs I enforce structured logging across all services with a consistent schema including trace ID, service name, and severity, so logs from different services can be correlated in a single query. For traces I use distributed tracing with a sampling strategy that captures 100% of error traces and a configurable percentage of success traces. I also build service-level dashboards that any on-call engineer can read without deep knowledge of the specific service. The measure of a good observability setup is mean time to diagnosis, not mean time to recovery. If engineers cannot identify the root cause within minutes of an alert firing, the observability setup needs improving.

Kubernetes upgrades are one of the most operationally sensitive tasks a platform team does, and the key is treating them as a zero-downtime migration rather than a maintenance window. My approach starts three months before a target upgrade version by testing the new version in a dedicated test cluster with a representative workload sample. I run the new version in parallel with the existing cluster for four to six weeks, looking for deprecation warnings, API changes, and behaviour differences. I document breaking changes and communicate them to engineering teams at least six weeks in advance, with specific actions they need to take. The actual migration uses a blue-green cluster approach: I provision a new cluster at the target version, migrate workloads service by service with traffic shifting at the load balancer level, and keep the old cluster warm for two weeks in case rollback is needed. I treat every cluster upgrade as a rehearsal for the next one, and I document the runbook and update it after each migration.

I joined a team where engineers were spending an average of four hours setting up a new service from scratch, because there was no standard template and every service had different patterns for logging, configuration, and deployment. I ran five short interviews with developers to understand the biggest pain points, then built a service scaffolding tool that generated a production-ready service skeleton in under two minutes with opinionated defaults for all of these. I also wrote comprehensive documentation and ran internal workshops. Before the change I measured the setup time by observing engineers going through the process. Six weeks after launch I repeated the measurement and found average setup time had dropped from four hours to 25 minutes. The developer satisfaction survey showed the tooling was the most-improved area that quarter. The lesson I took was that the measurement framework mattered as much as the tool itself: without the before measurement, I could not have demonstrated the impact.

I pushed an update to our base container images that included a newer version of a shared library. I had tested it against our own platform services but had not checked all consumer services. Within two hours of the rollout, three teams reported broken builds because the library update introduced a breaking API change that was not backwards compatible. My immediate response was to revert the base image to the previous version and send a clear incident update to all affected teams within 15 minutes. Once the immediate problem was resolved, I ran a post-incident review to understand why the testing had been insufficient. The root cause was that we had no automated compatibility testing for shared library updates across consumer repositories. I built a testing pipeline that validates base image changes against the top 20 consumer services before any update is released. The process now catches this class of problem before it reaches teams.

I was managing a platform backlog where two teams had urgent competing needs: Team A wanted improved log querying performance because their debugging time had increased significantly, and Team B wanted self-service secrets rotation because their security audit had flagged a manual process. Both were legitimate and both were taking longer to address than I was comfortable with. I ran a structured prioritisation session with both teams, presenting the platform team's capacity honestly and asking each team to quantify the cost of the delay: debugging time lost per engineer per week for Team A, and audit risk for Team B. Team B's request had a compliance deadline that made it objectively higher priority. I committed to Team A with a specific delivery date four weeks out and gave them a temporary workaround in the meantime. I then delivered Team B's request in three weeks and Team A's in week five. The key was being transparent about constraints and giving both teams visibility into the queue.

Terraform at scale has three main challenges: state management, module reuse, and preventing drift. For state I use a remote backend with locking, typically S3 and DynamoDB on AWS, and I separate state by environment and by service boundary so that a failed apply in one area cannot corrupt state for another. I organise Terraform code into a modules repository and a configurations repository. The modules repository contains versioned, tested modules that encode organisational standards: a standard Kubernetes namespace module that includes RBAC, network policies, and resource quotas; a standard database module that enforces encryption at rest and automated backups. Teams reference specific module versions in their configurations, and module upgrades are reviewed by the platform team. I run automated Terraform plan in CI on every pull request so that infrastructure changes are visible in code review before they are applied. Drift detection runs on a nightly schedule, comparing the actual state of production against the Terraform state, and alerts on any unexpected differences.

Noisy neighbour problems in Kubernetes arise when one workload consumes more CPU or memory than expected and impacts other workloads on the same node. The primary defence is well-configured resource requests and limits, but setting these accurately requires data, not guesses. I use a combination of VPA (Vertical Pod Autoscaler) in recommendation mode to collect data on actual resource usage over two weeks before setting requests and limits, and I enforce that every deployment must have requests and limits defined using admission control policies. I also use Kubernetes namespaces with ResourceQuota and LimitRange to prevent any single team from consuming more than their allocated share of cluster capacity. For workloads with very different resource profiles, I use node selectors and taints to co-locate similar workloads on dedicated node pools rather than mixing batch jobs and latency-sensitive services on the same nodes. I monitor resource utilisation at the namespace level weekly and proactively discuss capacity with teams whose usage is trending toward their quota.

Secrets management at scale has to solve three problems: secure storage, controlled access, and rotation without service disruption. For storage I use a dedicated secrets manager, either HashiCorp Vault or AWS Secrets Manager, and I enforce that no secrets ever appear in environment variables at the Kubernetes level or in version control. Secrets are injected at pod creation time via a CSI driver or an admission webhook that pulls from the secrets manager, so developers do not need to manually manage secrets in deployment manifests. For access control I use policies that grant each service access only to the specific secrets it needs, based on Kubernetes service account identity. For rotation I automate it using the secrets manager's rotation feature with Lambda functions that update the secret and then trigger a rolling restart of affected deployments. The key test for any rotation implementation is that it completes without any service returning a 5xx error: I validate this in a staging environment before enabling rotation in production.