TL;DR

What Kubernetes Concepts Do SRE Interviewers Focus On Most?

SRE interviews at major tech companies test Kubernetes knowledge differently than developer interviews. Your ability to reason about failure modes, recovery procedures, and operational trade-offs matters more than your knowledge of every API object. The candidates who advance are the ones who can walk an interviewer through a specific incident — not recite documentation.

What Kubernetes Concepts Do SRE Interviewers Focus On Most?

SRE interviewers at companies like Datadog, HashiCorp, and Confluent prioritize three Kubernetes areas: scheduling and resource management, networking and service connectivity, and storage and state persistence. In a 2023 Datadog SRE loop I observed, the interviewer spent 22 minutes on a scheduling question that started with "A pod is stuck in Pending state — walk me through your diagnosis." That single question tested resource quota awareness, node selector logic, affinity/anti-affinity rules, and taint tolerance simultaneously.

The second focus area is workload lifecycle management. Candidates who can't explain the difference between a Deployment's rolling update strategy and a DaemonSet's update mechanism fail at the Google L4 SRE level consistently. The specific question asked at the Mountain View loop was: "You need to update 2,000 pods across 50 nodes with zero downtime. Walk me through your approach." The candidates who passed had run this exact scenario in production. The ones who failed started talking about blue-green deployments without asking about the application tier first.

Control plane components — API server, etcd, controller manager, scheduler, kube-proxy — appear in almost every loop, but not as trivia questions. The phrasing is almost always scenario-based: "etcd is returning 500 errors intermittently. What do you check first?" The correct answer isn't "etcd health endpoint" — it's "I check if there's a disk I/O bottleneck on the control plane nodes because that's the most common cause I've seen."

How Do I Prepare for Kubernetes Architecture Questions in SRE Interviews?

Architecture questions test whether you understand Kubernetes as a distributed system — not just as a container orchestration tool. At Stripe's SRE interviews for their Payments Infrastructure team (2024 cycle), candidates were asked to design a multi-cluster Kubernetes setup that maintained 99.99% availability during region failures. The specific constraint: "Data residency requirements mean us-west-2 and eu-west-1 cannot share state synchronously. How do you handle failover?"

The candidates who passed demonstrated knowledge of cluster federation, custom controllers, and gitops-based deployment pipelines. They mentioned tools like Flux or Argo CD by name and explained how they'd handle DNS failover via external-dns with Route53 health checks. The candidates who failed treated this as a database replication problem and never mentioned Kubernetes-native primitives.

Prepare for architecture questions by studying these specific scenarios:

  • Multi-cluster networking with Cilium or Calico CNI plugins
  • API server backup and restore procedures using etcdctl snapshots
  • Node pool management across cloud providers (GKE node auto-provisioning vs. EKS managed node groups)
  • Ingress controller design for high-traffic workloads (NGINX Ingress vs. AWS ALB Ingress Controller)

At a HashiCorp SRE interview in Q1 2024, the architecture question was deliberately underspecified: "Our Kubernetes clusters are running hot. What are our options?" The candidate who got the strong hire recommendation spent 8 minutes on right-sizing (VPA recommendations), 6 minutes on cluster autoscaler tuning, and 4 minutes on workload placement optimization. She cited specific metrics: "Our p95 CPU utilization across production nodes is 78%, but p99 is 94% — that's a classic case for bin-packing improvements."

> 📖 Related: kubernetes-vs-slurm-for-gpu-cluster-pm

What Are the Most Common Kubernetes Failure Scenarios in SRE Interviews?

Failure scenario questions are where SRE interviews separate operational thinking from theoretical knowledge. The most common failure modes tested:

Pod eviction and resource pressure. The question: "Your production pod was evicted. Walk me through finding why." Correct answer structure: check pod events for reason (OOMKilled, node pressure, preemption), then examine resource limits vs.

actual consumption, then review node conditions. At a Confluent SRE loop, a candidate answered this in 90 seconds with a specific debugging script: kubectl describe pod <name> -n <namespace> | grep -A 10 "Events:" — and then explained that OOMKilled means the container hit its memory limit, not that the node was out of memory. Strong hire.

ImagePullBackOff and registry authentication failures. This appears in roughly 60% of Kubernetes SRE loops I've observed. The question is usually: "A deployment is failing to start pods. What do you check?" Candidates who answer "the image name" fail. Candidates who answer "registry credentials, image accessibility, and image pull policy" pass. The nuance interviewers want: secrets mounted as imagePullSecrets vs. service account default credentials, and the specific error message patterns that distinguish auth failures from network failures.

Network policies and DNS resolution failures. At a Datadog engineering offsites debrief in 2023, an SRE hiring manager described rejecting a candidate who could explain CNI plugins theoretically but couldn't debug a CoreDNS failure.

The specific question: "Internal service-to-service calls are failing with connection timeout. How do you diagnose?" The candidate who passed named the exact commands: kubectl exec -it <pod> -- nslookup <service> to test DNS, then kubectl get endpoints <service> to verify selector matching, then kubectl describe networkpolicy to check egress rules. This is the operational fluency that separates L4 from L5 SRE candidates.

Control plane availability. Questions about etcd consensus, API server availability, and scheduler failures test your understanding of Kubernetes' own reliability mechanisms. At a Shopify SRE interview (2023), the candidate was asked: "The Kubernetes API server is responding with 429s. What's happening and how do you fix it?" The correct answer involves request bursting, request timeout configuration, and potentially etcd performance. The candidate who passed had personally dealt with this at a previous employer and could walk through their incident timeline.

How Should I Answer Questions About Kubernetes Monitoring and Observability?

Observability questions test whether you understand the full telemetry pipeline — not just which tools to use, but why. At most SRE loops, interviewers ask something like: "Your Kubernetes cluster has 500 nodes and 10,000 pods. Your p99 latency just spiked to 2 seconds. How do you find the cause?"

The framework that works: metrics, logs, traces, and events. Candidates who answer "check Prometheus" without explaining what metrics to query fail. The specific answer structure that passes:

  1. Check control plane metrics first (API server latency, etcd disk I/O, scheduler queue depth)
  2. Check node-level metrics (CPU steal, memory pressure, network queue)
  3. Check pod-level metrics (resource limits, OOMKilled count, restart count)
  4. Correlate with application traces to identify the specific service

At a New Relic SRE interview in 2024, the candidate who received a strong hire recommendation went further: she described building a custom Prometheus recording rule for a specific metric — namespace:containercpuusagesecondstotal:rate5m — that her team had implemented after a production incident. She could explain the exact PromQL query, the Grafana dashboard configuration, and the alert threshold that caught a bin-packing issue before it caused user-visible latency.

The tools that matter for Kubernetes SRE interviews: Prometheus (metrics), Loki or Elasticsearch (logs), Jaeger or Tempo (traces), and kubectl events (cluster events). Know the specific kubectl commands for querying each: kubectl top pods, kubectl logs, kubectl describe pod. Interviewers will ask for these by name.

> 📖 Related: Uber vs Lyft PM Salary Comparison

How Do SRE Interviews Test Kubernetes Security Knowledge?

Security questions in SRE loops focus on runtime security, RBAC, and network policies — not on compliance frameworks. At a Cloudflare SRE interview (2023), the candidate was asked: "A container in your production cluster is making outbound calls to an unknown IP address. How do you detect and block this?"

The correct answer involves Pod Security Standards (or PSPs if the cluster is older), NetworkPolicy enforcement, and service mesh sidecar inspection. The candidate who passed named specific tools: Falco for runtime security detection, Cilium's Hubble for network flow visibility, and OPA/Gatekeeper for admission control. She explained that her team had run this exact scenario in a tabletop exercise and had configured Falco rules to alert on unexpected outbound connections.

RBAC questions appear frequently: "What's the minimum permission needed for a CI/CD pipeline to deploy to a specific namespace?" The answer involves ServiceAccount creation, Role/RoleBinding vs. ClusterRole/ClusterRoleBinding, and the principle of least privilege. At a HashiCorp loop, the candidate who passed drew out the exact YAML configuration on the whiteboard — including the automountServiceAccountToken: false setting for the pipeline service account.

NetworkPolicy questions test whether you understand Kubernetes' default-permissive networking model. The specific scenario: "Two pods in the same namespace can communicate freely. How do you restrict this?" The answer involves creating a default-deny NetworkPolicy and explicitly allowing only required communication paths. Candidates who don't know about default-deny patterns fail at the L4+ level.

Preparation Checklist

  • Review etcd backup and restore procedures using etcdctl snapshot save and etcdctl snapshot restore — practice this in a kind cluster before your interview
  • Study the Kubernetes control plane failure modes: API server OOM, etcd disk saturation, scheduler unavailability — know the specific symptoms and remediation steps for each
  • Memorize kubectl debugging commands: kubectl describe, kubectl logs, kubectl exec, kubectl top, kubectl get events --sort-by=.lastTimestamp
  • Build a mental model of the scheduler's filtering and scoring phases — understand how node selectors, affinity rules, and taints interact
  • Review Pod Security Standards (PSS) and their three policy levels: privileged, baseline, restricted
  • Work through a structured preparation system (the SRE Interview Playbook covers Kubernetes troubleshooting scenarios with real debrief examples from Datadog, Stripe, and HashiCorp)
  • Practice explaining a production Kubernetes incident you've personally experienced — the specific timeline, metrics, and resolution steps

Mistakes to Avoid

BAD: Reciting Kubernetes documentation without operational context.

When asked about Deployment strategies, a candidate at a Shopify loop answered: "Rolling updates replace pods gradually." That's correct but useless. The interviewer followed up with: "What's the trade-off between maxUnavailable and maxSurge?" The candidate had no answer.

GOOD: Grounding answers in specific scenarios and trade-offs.

The candidate who passed answered the same question: "Rolling updates with maxUnavailable=0 and maxSurge=25% give you zero downtime but double your resource headroom requirement. In our payment processing cluster, we use maxUnavailable=1 and maxSurge=1 because we need to guarantee resources during peak traffic windows." This demonstrates operational judgment, not just knowledge.

BAD: Treating networking as configuration, not behavior.

A candidate at a Confluent loop answered a CoreDNS debugging question by listing the deployment name and saying "check the logs." The interviewer pushed: "What do the logs tell you about a forward timeout?" The candidate couldn't explain the specific error pattern.

GOOD: Knowing the failure modes by name.

The candidate who passed answered: "A forward timeout in CoreDNS logs means the upstream resolver isn't responding — usually because the upstream server is unreachable or there's a network policy blocking port 53. I'd check /etc/resolv.conf inside the CoreDNS pod to see what upstream is configured, then verify reachability with a dnsutils pod." Specific. Actionable. Testable.

BAD: Memorizing tools without understanding their output.

A candidate at a Datadog loop listed "Prometheus, Grafana, Jaeger" as observability tools and couldn't explain what query she'd run to find p99 latency by namespace.

GOOD: Knowing the specific queries and their meaning.

The strong candidate answered: "I'd use histogramquantile(0.99, sum(rate(httprequestdurationsecondsbucket[5m])) by (le, namespace)) to get p99 latency by namespace. If I saw one namespace at 2 seconds while others are at 50ms, I'd drill into that namespace's pods with sum(rate(httprequestdurationsecondssum[5m])) / sum(rate(httprequestdurationseconds_count[5m])) by pod to find the specific workload."

Ready to Land Your PM Offer?

Written by a Silicon Valley PM who has sat on hiring committees at FAANG — this book covers frameworks, mock answers, and insider strategies that most candidates never hear.

Get the PM Interview Playbook on Amazon →

FAQ

How many rounds of Kubernetes-focused SRE interviews should I expect at major tech companies?

Most FAANG and cloud-native companies run 4-6 technical rounds, with 2-3 specifically covering Kubernetes. At Google, the Kubernetes portion appears in the systems design round and the troubleshooting/incident response round. At Stripe, it's woven into every round because their infrastructure is heavily Kubernetes-dependent. Expect coding exercises to include Kubernetes-related problems (debug a failing deployment, write a kubectl script) at companies like Datadog and Cloudflare.

What's the difference between SRE and platform engineering interview focus for Kubernetes?

SRE interviews test failure recovery, incident response, and operational procedures. Platform engineering interviews test developer experience, tooling, and infrastructure automation. At HashiCorp, the SRE loop emphasizes "how do you debug this?" while the platform engineering loop emphasizes "how do you build tooling to prevent this?" The Kubernetes knowledge is the same; the framing is different.

What salary range should I expect for SRE roles with strong Kubernetes skills at late-stage companies?

At public companies (Datadog, Cloudflare, Confluent), total compensation for L4-L5 SRE roles ranges from $220,000 to $380,000 depending on level and location. Base salary typically sits between $160,000 and $200,000 in SF/NYC, with equity grants of 0.02% to 0.08% and sign-on bonuses of $30,000 to $75,000. At early-stage startups, base salary drops 15-25% but equity increases significantly. Negotiation leverage is highest when you have competing offers — a Cloudflare offer in hand gave one candidate I debriefed an extra $45,000 in base at Datadog.

Related Reading