Uber SRE / Platform Engineer interview questions

A growing backlog of sockets waiting for the application to close its side usually points at lifecycle handling. Here is the hunt from ss output to the pool timeout that caused it.

The signature is unmistakable once seen: handshakes complete, then the connection freezes at the same byte count every time. Here is the probe sequence and the fixes, ranked.

Five commands separate people who have actually built this from people who read about it once. Here is the working sequence, plus the gotchas that break it.

Multiplexing removes application-level queuing and hands the problem to TCP. Here is where the blocking really lives, the loss math behind it, and the four levers that help.

Loss-based versus model-based congestion avoidance decides whether your WAN transfers fill the pipe or die on the first stray drop. Here is the operator's decision, not the RFC summary.

Turns the standard autoscaling definition into the problem it actually causes. Almost every candidate can define an HPA; far fewer can say why theirs did not save them.

Fleet-wide replacement is a traffic-shaping problem: bake once, wave through in controlled batches, watch the alarms, and keep the exit open. In-place patching is the alternative and usually the regret.

Queue, log and router solve different problems that all get called events. Picking by workload shape beats picking by whichever service the team already knows.

Postgres spends memory on a backend process per connection, and serverless fan-out treats that as an invitation. Pooling at the proxy layer is the standard cure; pinning is the catch.

Quotas are invisible until launch day. Treating them as tracked inventory with utilization alerts beats discovering them in a postmortem.

A dead-letter queue with no owner is a landfill with a nicer name. Triage discipline separates teams that recover messages from teams that archive regret.

Active-active replication moves writes but not truth. Last-writer-wins quietly discards one of the two orders your finance team expects both to exist.

Data transfer is charged in several unrelated ways and reported as one line, so the first job is decomposition. Most surprises are cross-zone chatter between services that never needed to be on different nodes.

Everyone recites that depends_on forces ordering. The stronger half of the answer is the graph you never see: implicit edges from references, why file layout orders nothing, and what explicit edges cost.

Stack boundaries follow blast radius and change frequency, not the org chart. The monorepo only pays for itself while a machine can answer, from a commit, exactly which roots need planning.

Idempotence describes one run; convergence describes the fleet across time. Scheduled check-mode sweeps with diff reporting, alerts above a learned baseline, and a hard rule that incident hotfixes become pull requests the same day.

Four-hour applies with throttling errors share one root cause more often than not. Diagnose which calls burn the quota, split the state along dependency seams, and touch the parallelism flag last, not first.

Registries live or die on upgrade ergonomics, not on publishing features. Green example plans gate every tag, automation delivers upgrade PRs with plan output to consumers, and retirement is a census plus a date.

A ReplicaSet keeps a count. A Deployment manages a sequence of ReplicaSets, and that is the entire difference: it is what turns a change into a rollout you can pause and undo.

The single most common Kubernetes interview question, and the one where a vague answer is most obvious. Every stage you name is a place the interviewer can ask you to debug.

Evaluate identity, traffic policy and telemetry against measured proxy overhead and operating responsibilities, then test the authorization boundary.

Both run pods, so the answer sounds obvious until an interviewer asks what happens when you delete one. The guarantees are narrower and more specific than most candidates think.

Everyone can recite the three. Explain what each failure causes, and why a badly configured liveness probe is more dangerous than none at all.

The pair everyone configures and few can explain. QoS hints at eviction risk, but usage versus requests and Pod priority determine node-pressure ranking, and CPU and memory behave completely differently when you exceed them.

The scheduler is behaving correctly, which is the part that confuses people. It optimises placement at admission time and never revisits, so a cluster drifts out of balance by design.

Compare the configured Service datapaths and their lookup and update mechanisms. The iptables datapath degrades with service count, and eBPF replaces a linear scan with a map lookup.

A specific configuration trap with a clean explanation. Both controllers act on the same signal from opposite directions, which can produce unstable feedback depending on their policies and workload.

Init containers are the easy half. The hard half is why plain sidecars race your app at both ends of the pod's life, and what restartPolicy Always changes about that.

The loop is easy; the statistics are not. This question finds engineers who can size a traffic slice against sample noise and name the false rollback that kills trust in automation.

Repeated full-resource polling can make an operator an expensive API client. This question separates people who run controllers at ten-thousand-object scale from those who copied a tutorial: watch semantics, cache behaviour, and which LISTs touch etcd.

Anti-affinity is binary and falls over at scale; topologySpreadConstraints give you numeric skew control across labeled domains. The subtle parts are eligibility filtering before the skew math, and the fact that Kubernetes never rebalances anything for you.

Two cleanup mechanisms hide behind one taint: image garbage collection removes unreferenced images by LRU at threshold crossings, while eviction kills pods. Candidates who conflate them fail this question quietly.

The classic five-second stall is rarely CoreDNS being slow; it is UDP, conntrack races and ndots expansion. The diagnosis ladder and the NodeLocal DNSCache fix separate operators from readers of architecture blogs.

Three API servers behind one health-checked endpoint, etcd on its own quorum, leader election everywhere else. The scored part is naming what degrades quietly before anything alerts.

A ladder from health-checked global DNS through endpoint mirroring to mesh east-west gateways. The deciding axis is trust boundary and failure isolation, not any mesh's feature matrix.

A Job with a sidecar was broken by design for years: the workload finishes, the proxy does not, and the pod never terminates. Native sidecars fix it by making the container an init container that keeps running.

Changing pod resources historically required recreation, which made vertical autoscaling disruptive for workloads with expensive recovery. In-place resize changes that, with limits worth knowing.

An end-of-maintenance date changes the risk even while traffic stays healthy. The work is proving routing and security parity before moving a production hostname.

Clusters multiply for good reasons: regions, isolation, tenancy, blast radius. The problem is not creating them, it is that cluster seven diverges from cluster three and nobody knows until an upgrade behaves differently.

Compare a shared-library patch across forty services, including affected builds, staged releases, runtime inventory and source-access boundaries.

Redeploying the old tag reverses code and nothing else. What separates staff-level answers is a per-change map of what rolls back in seconds, what rolls back in days, and what only moves forward.

Quarantine is a holding cell with an expiry date, not a landfill. Per-test flake rates, entry evidence, an enforced expiry review, and the cap that turns fixing into priority.

Build graphs identify affected targets only when their dependencies are complete. The ladder from build-everything to content-addressed caching, hermeticity audits, and where undeclared inputs rot correctness.

For scheduled and stateful workloads the exposure unit is records and time, not requests: shadow runs on real input, row-level diff budgets, checkpoint compatibility, one-cycle warm standby.

Ownership files decay faster than org charts. What separates working CODEOWNERS from rubber-stamp theatre is hygiene: team aliases, stale-owner linting, and keeping review routing apart from paging.

Runner migration questions hide two different exams: whether a PR job can steal your cloud credentials, and why the fleet idles at half price all night. Isolation first, economics second.

The code did not change, the data did. That inverts what triggers the pipeline, what the tests assert, and what a rollback means.

Prometheus asks your service for numbers on a schedule rather than waiting to be told. That one design choice explains service discovery, exporters, staleness and why short-lived jobs are the awkward case.

Defining chaos engineering is easy. Far fewer can say what they would break first, and almost none volunteer the abort condition, which is the thing that makes it a programme rather than an incident.

The observability failure that scales with your success. Cardinality is the cost driver in every metrics system, and the fix has to be structural or it comes back next quarter.

A question with a right answer and a subtle reason. Histogram versus summary is the part that catches people, and it turns on whether you can aggregate across instances.

Tracing is the only telemetry that answers where the time went across services. The mechanism is context propagation, and the reason teams fail at it is that one uninstrumented hop breaks the chain.

Anyone can divide bad requests by total. This answer shows the aggregation mistakes that quietly corrupt SLO dashboards, the rate-versus-increase traps that make budgets lie, and when subqueries cost too much.

Spending the budget is arithmetic; enforcing consequences is politics plus automation. The answer that lands names trigger thresholds, the deploy gate that blocks releases, and the dated escape valve.

Forty healthy islands equal one blind estate. Compare the consolidation patterns honestly, keep alerting local, curate what crosses the WAN, and make the global view read-only and cheap.

Request-shaped SLIs quietly fail on data platforms. The strong answer defines freshness, completeness and deadline SLIs on consumer-visible artifacts, not job success rates.

MTTR is three clocks hiding in one number. Profile detection, diagnosis and fix separately from incident timestamps; attack whichever clock dominates, which is almost never rollback speed.

Their green page, your red SLO. Separate their true failure rate from the amplification your own client adds, buffer at the boundary, then escalate with a client-side scorecard instead of feelings.

Assert on the shape of a trace: which spans ran, in what order, with which attributes. Catches the cross-service regressions unit and contract tests structurally miss, at the price of instrumentation discipline.

Agent per node, gateway per cluster, and one decision that shapes everything else: tail sampling needs every span of a trace in one place, which is why the topology has a tier that looks redundant until you need it.

Tracing tells you which service and which span. It stops at the function boundary, and that is exactly where a CPU regression lives. Continuous profiling is the layer most teams do not have when they need it.

There is no status code and no caller waiting, so latency and error rate stop meaning what they meant. The signals that replace them are age, lag and completion, and they answer a question the request-response set never had to ask.

HTTP success can carry a rejected-span count. Replaying that batch can duplicate accepted telemetry, while enlarging the queue cannot repair invalid data.

A common scenario question, and the one where a list of commands most often stands in for an argument about what each one eliminates. Empty logs is the clue, not the obstacle.

The gentlest scheduling question there is, and it still separates people who read the events from people who guess. Check whether the pod has a node before choosing between scheduling and startup diagnosis.

The pods are Running, the dashboard is green, and users get errors. The gap between Running and receiving traffic is where this question lives, and it has a precise answer.

A senior favourite, because the naive answer is to look at averages and the average is exactly what is hiding the problem. Tail latency has a short list of causes and they are all structural.

Tests whether you know that Kubernetes waits, and for how long. The default timings surprise most candidates, and they explain why a node failure hurts longer than people expect.

Intermittent DNS is the most-reported and least-understood Kubernetes failure. There are three well-known causes and each leaves a different fingerprint.

The classic gap between what the backend measures and what the user experiences. A 504 is emitted by something in front of the backend, which is exactly the part your service dashboards do not cover.

Low utilisation with terrible tail latency is not a contradiction. It is the CFS quota doing exactly what it was configured to do. Most candidates have never read nr_throttled.

Established traffic keeps working while new connections die at random, which is exactly why this one confuses people. The table is full of flows that will not be needed again for days.

A two-second dependency should cost you latency, not three services. The mechanics are arithmetic: Little's law plus retry amplification. The fix is a budget, not a ban.

Same-node good, cross-node bad is not a random clue, it is nearly a diagnosis. One short decision tree separates overlay reachability, encapsulation blocks, MTU and policy.

The kill was not random and it was not fair. Learn the scoring function the kernel actually uses, then bend it with oom_score_adj before your monitoring dies during the next leak.

More partitions should mean more throughput, so why did the backlog deepen? Because rebalance behavior depends on the group protocol, and the way consumers divide work decides who pays for it.

Split-brain writes are a fencing failure first and a data problem second. Freeze writes, read the divergence boundary from replication positions, and let the payment ledger arbitrate reality.

Wall-clock schedules meet daylight-saving transitions: spring forward deletes an hour of cron targets, fall back repeats one. Schedule in UTC, add idempotency keys, rehearse in staging.

Fork failures can reflect PID limits or memory allocation failure even when host RAM looks available. Find which ceiling broke, cap PIDs per cgroup so one team's leak costs one pod, and fix the unbounded spawn.

Queue time, prefill and decode fail for different reasons and the aggregate hides which. Split the metric first and the candidate list drops from twenty to three.

The automation stopped because it could not decide, which is the correct behaviour and an incomplete design. Somebody has to decide, and the interesting question is what evidence that decision needs.

Raising the limit buys hours and proves nothing. The six-hour periodicity is the diagnosis: something is opening descriptors on a code path that never closes them.

The pod's resolver is configured to try five search domains before the real one. An uncached external hostname can trigger several search-expanded queries before its absolute lookup, and the failures are what you are paying for.

One partition has one consumer, by design. If the key distribution sends a third of the traffic to one partition, the parallelism you bought is unavailable to the work that needs it.

Warn forever becomes wallpaper; block on day one gets the gate switched off. The durable answer is a severity-and-fixability matrix plus suppressions that expire.

Push approval is a weak factor and fatigue is its predictable failure mode. Stop the campaign with number matching and rate limits; end the attack class with passkeys, device gating and a hardened helpdesk.

Choose by trust boundary, not fashion: mesh-issued mTLS inside a cluster, audience-bound tokens across teams and clouds, both together at scale. Static shared secrets are the thing being replaced.

The design round where the honest answer is mostly about data. Stateless traffic across regions is straightforward; the database is where active-active is either solved or pretended.

Cron is the most-deployed scheduler on earth and the worst-behaved at scale. The scored content is everything crontab cannot do: exactly-once firing, thundering herds, and what happens when the scheduler itself dies.

Two contracts in one system: an OTP with a 30-second promise and a sale announcement reaching fifty million phones without burning providers. Priority lanes and double-layer dedup decide the grade.

Sharding buys write headroom and bills you in joins, foreign keys, and every future migration. The key choice is a query-pattern bet; the resharding choreography separates operators from diagram artists.

Every overloaded system dies the same way: queues turn load into latency, latency into timeouts, timeouts into retry storms. Tiered shedding, deadline propagation, and retry budgets are the design.

Everyone sizes a metrics system by samples per second and everyone is wrong. The constraint that actually kills these platforms is a single label added on a Friday.

Leases prevent dead holders but not overlapping ones. The staff-level answer is fencing tokens and a candid account of why quorum lock services without downstream checks are still probabilistic.

Trace a retry through the broker, database and external provider. The guarantee changes at each boundary, and a recorded intent does not prove a payment or email completed.

The hard parts are not search. They are deciding what to keep before you pay to store it, isolating one team's query from everyone else's, and making the cost visible to the people generating it.

Queue time and build time are separate problems with separate fixes, and most teams spend a quarter optimising the one that is not hurting. Size the fleet from arrival rate, then attack the build with caching and graph awareness.

DNS time-to-live is a suggestion and nineteen minutes is what believing it costs. The mechanism you choose decides your failover time, and the health check you choose decides whether it fires at all.

A question about method, not about tactics. Candidates who open with a list of levers lose to candidates who open with one question about the bill itself.

A platform question that is really a product question. The design is the easy half; the answer that scores explains how you would know developers chose it rather than were forced onto it.

A shared cluster produces one bill and no answer. Attribution is a measurement problem first and a cultural one second, and the number that changes behaviour is not the one finance asked for.

The difference between scaling node groups and provisioning nodes is the whole answer. One picks from shapes you defined in advance; the other reads the pending pods and buys what they need.

Four purchase instruments, one fleet, and a finance team asking why you did not commit to everything at maximum discount. The scoring rubric rewards the arithmetic of being wrong, not the discount table.

Percentage savings make every quarter look like a win and tell you almost nothing. A denominator tied to revenue is the one that survives scrutiny, because it is the only one a finance conversation can act on.

Token spend has no natural ceiling. Every retry, every retrieved document, every chain step multiplies, and nothing in the system tells anyone until the invoice arrives.

The discount is real and so is the option you are selling. The question is what your usage looks like in year three, and the honest answer for most teams is that they do not know.

A budget miss can coexist with lower cost per request. Separate demand, usage intensity and price effects before assigning an efficiency target.

Announcing a deadline is not a migration plan. The teams that miss it are the ones who were never going to read the announcement.

The expensive part of these incidents is almost never the fix. It is the twenty minutes spent deciding whose incident it is.

Forty minutes is a symptom with at least four different causes, and three of them are cheaper to fix than moving everyone's development to a remote machine.

Operational load is not a discipline problem. It is the interest payment on everything the team shipped without an owner, and it compounds.

The question that separates people running GPU clusters from people running Kubernetes clusters that happen to have GPUs. The answer is that an integer count cannot express what a GPU workload needs.

The default scheduler places pods one at a time, which is exactly wrong for a job that needs all sixteen or none. Two half-placed jobs can hold each other's GPUs forever without either ever starting.

Hard quotas strand idle GPUs and soft quotas mean the loudest team owns the cluster. Borrowing with reclaim is the shape that works, and the interesting decisions are all about what happens when the lender comes back.

GPU capacity is not elastic the way CPU is. On-demand means whatever is left after the reservations, and in a tight region that is nothing, so the availability problem and the cost problem are the same problem.

The fastest-growing design round in infrastructure hiring. GPU economics break the assumptions CPU autoscaling is built on, and the answer has to start from that rather than from Kubernetes.

Scale to zero is correct for some workloads and an outage generator for others, and the deciding number is what the first request after idle experiences. Cold start turns an availability promise into a queue.

A model provider is a single dependency with a shared failure domain across every customer they have. Treating it like a database you cannot fail over from is how a product goes down for four hours.

The utilisation number everyone quotes means at least one kernel was resident, not that the hardware was doing useful work. A GPU at 95 percent can be doing five percent of what it is capable of.

The training part is a job. Everything around it is the pipeline: data snapshots that are immutable, an evaluation gate with a threshold set in advance, and adapters versioned so a bad one is a routing change away from gone.

Expensive accelerators waiting on cheap storage is the most common form of waste in a training cluster, and it looks exactly like a code problem on every dashboard.

A model is an artifact with a lineage, an evaluation record and an owner, or it is a file somebody copied to a bucket. The registry exists so that the second one cannot reach production.

Before blaming the model, check whether it is being fed the same thing it was trained on. Most of the gap is a pipeline difference, and pipeline differences are a platform problem with a platform fix.

Per-token pricing looks expensive until you compute what an idle GPU costs at 3am. Break-even depends on workload volume and duty cycle, measured throughput, and the engineering cost on both sides.

GPU cost attribution needs allocation records as well as utilization. Separate exclusive reservations from borrowable quota, then reconcile team charges and idle capacity to the actual bill.

Nobody is waiting, which changes every constraint. Latency stops mattering, throughput per dollar becomes the only metric, and the design converges on something that looks like a data pipeline rather than a service.

A notebook holds a GPU while somebody thinks, which is most of the day. The utilisation on an interactive fleet is the worst in the building, and the fix is a queue people do not hate.

Use shared evidence and an agreed experiment to resolve a cross-team production problem, while containing impact and escalating time-sensitive risk.

Resolve competing urgent requests using consequences, deadlines, uncertainty and real capacity, with explicit decisions about deferred work.

Build a reliability proposal with observed impact, uncertain risk, implementation cost and a verification plan that supports an explicit priority decision.

Retire an internal tool through verified user needs, compatibility evidence and an owned cutover, while treating its maintainer as a source of context rather than a barrier.

Handle a slipping dependency through a tested interface, honest integration status and an early decision about scope, resources or the external commitment.

Keep incident coverage working while investigating missed notifications, with private conversation, tested escalation and appropriate management support.

A deceptively deep question, because there are at least six places a version can get stuck and they span the pipeline, the cluster and the edge. Work the path in order.

A pod is a shared network and storage boundary that happens to contain containers. Once you can say what the containers inside one share, sidecars and init containers stop needing separate explanations.

Service types choose how an application is exposed. Follow the actual traffic path: cloud controllers can target nodes or pods, and internal exposure differs from public exposure.

A Service moves connections and an Ingress reads requests. The gap between those two sentences is hostname routing, path routing and TLS, and it is also why an Ingress object alone does nothing.

The Indian e-commerce interview question, and autoscaling is the wrong first answer. A 10x spike arriving in seconds outruns any scaling loop, so the design has to absorb rather than scale.

Follow a Deployment change through the API server, controllers, scheduler and kubelet. Each handoff gives you a different place to investigate when a pod never starts.

Almost always a finalizer, and the fast fix is the one that loses data. The safe answer explains what the finalizer is protecting against before removing it.

Build instructions depend on earlier inputs, so changing source can invalidate a dependency installation placed after it. Ordering the Dockerfile by how often things change is the whole optimisation, and multi-stage is how the compiler stops shipping to production.