Site Reliability Engineer Interview Experience at GitHub – 2026

Recruiter screen covering the candidate's Kubernetes and incident-response background, with the recruiter noting the team's scope covers infrastructure underlying both github.com and GitHub Actions, and confirming comfort with a remote-India setup given the role's US-based team.

Candidates are given access to a deliberately broken Kubernetes cluster with a service failing to serve traffic, and asked to diagnose and fix it live. The expected approach starts with pod status and recent events rather than jumping straight to application logs, finds the pods in a CrashLoopBackOff state, and traces it to a readiness probe configured with too short a timeout for the service's actual startup time under the test cluster's resource constraints - increasing the probe's initial delay and timeout resolves it. The interviewer then introduces a second, related issue: a subset of pods being OOM-killed under load, diagnosed by checking pod resource limits against actual memory usage patterns from historical metrics; raising the memory limit is preferable to assuming a memory leak when usage is consistent with legitimate load rather than an ever-growing footprint.

Candidates are asked to design infrastructure for running a large volume of untrusted, customer-defined CI/CD jobs (as GitHub Actions does) in a way that prevents one customer's job from affecting another's, both for security isolation and for the 'noisy neighbor' resource-contention problem specifically named in the prompt. A strong answer proposes ephemeral, single-use compute environments per job run rather than any shared long-lived worker pool, with strict per-job resource limits, and discusses the tradeoff between ephemeral-environment cold-start latency and the isolation guarantee it buys - the isolation guarantee is non-negotiable given the untrusted-code context, so the right lever to pull is optimizing cold-start time itself rather than compromising on isolation.

Candidates are asked to walk through leading a real incident postmortem from detection to resolution to follow-up, with explicit emphasis on the process change that resulted, not just the technical fix. A strong answer describes a sev-2 incident caused by a config change that passed all automated checks but had an unanticipated interaction with a downstream service, and how the postmortem led to introducing a canary-based rollout gate specifically for that class of config change, rather than just fixing the immediate bug and considering the incident closed.