Site Reliability Engineer Interview Experience at Postman – 2026

This recruiter call confirms the role sits specifically on the Cloud Platform team, the group responsible for the infrastructure underlying Postman's API platform used by millions of developers, and clarifies that the team's current focus is deepening their GitOps/ArgoCD-based deployment model rather than a greenfield build.

This round covers GitOps fundamentals in depth - specifically how ArgoCD reconciles a live cluster state against a Git-declared desired state, and what happens when a manual, out-of-band change is made directly to a production resource. The expected answer explains that ArgoCD detects the resulting drift on its next sync cycle and, depending on the configured sync policy, either flags it for manual reconciliation or automatically reverts it back to the Git-declared state - and discusses why teams often deliberately disable auto-sync for certain sensitive resources to avoid accidentally reverting an emergency hotfix applied directly to the cluster.

Candidates are asked to design the infrastructure-as-code structure for onboarding a new microservice into an existing declarative, ArgoCD-managed platform, including how to keep the onboarding experience fast for engineers while avoiding environment drift between staging and production. A strong approach proposes a layered repo structure - a base layer of common Kubernetes manifests templated per-service, an environment-overlay layer for staging versus production differences, and a promotion workflow where a change merges into staging automatically but requires an explicit, audited promotion step to production. Interviewers typically push on how a new engineer unfamiliar with the platform would onboard a service without needing deep GitOps expertise; a solid answer proposes a scaffolding CLI that generates the correct manifest structure automatically from a short service spec.

The Cloud Platform team lead asks about a real incident where infrastructure drift caused a production issue, and how it was ultimately caught and fixed. A strong answer describes a case where a manually-applied config change was never reflected in Git, so a later legitimate deploy silently reverted it and reintroduced a bug, and how the postmortem led to introducing a drift-detection alert that flags any live resource that no longer matches its Git-declared state, rather than relying on someone noticing during a future deploy.