LinkedIn SRE / Production Engineer interview questions

The question that reveals whether someone knows what load average actually counts on Linux. It is not a CPU metric, and that single fact resolves the whole thing.

The classic ephemeral port exhaustion question. TIME_WAIT is a familiar phrase and the useful facts are narrower: which side accumulates it, and why the popular fix is dangerous.

The scripting round in disguise. The constraint is the question: it exists to see whether you stream or whether you load, and everything else is about whether the script is safe to run twice.

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.

Latency fine, loss low, link idle, yet a single copy takes hours. The arithmetic of bandwidth-delay product settles this question before any tool opens.

Sessions, locks and pub/sub are three very different contracts with the same server. Knowing which guarantees each one lacks is the difference between a cache and an outage.

Blue-green works for stateless apps because instances are disposable. Databases are shared state, so safe migrations ride on backward compatibility and an explicit rollback boundary.

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.

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.

Preview environments succeed or die on teardown: webhook destroys plus a nightly janitor with a TTL. Get the data policy and cost tagging right or the invoice ends the experiment before the demo does.

PDB governs voluntary disruptions only and does not gate rolling updates at all. Describing it as 'it keeps N pods alive' states the part it does not do, since it constrains voluntary eviction and not the machine that fails.

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.

Scale-downers mark a node removable only when every pod on it can leave safely. Your batch workload died because nothing marked it special. The mechanism is a filter cascade, and the fix is priorities, PDBs and annotations.

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.

Hard versus soft rules, topology keys, weights that lose to everything else, and the IgnoredDuringExecution half nobody remembers. Placement shapes blast radius only when paired with disruption budgets.

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.

The honest mechanics of merging to trunk many times a day: flags, fast CI, trunk locks, and the conditions under which you should not run it at all.

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.

Define the five delivery measures from explicit events, distinguish failure from rework, and expose uncertain attribution and small samples.

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.

The arithmetic takes ten seconds and is the part most often skipped. The stall is the signal: it means error budgets are something you have read about rather than used.

Alert fatigue is a design failure, not a discipline failure. The fix is a rule about what may page at all, and burn-rate alerting is how you implement it.

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.

Day-one telemetry is cheap and retrofitting it costs an incident. The answer that scores names the linking layer (trace IDs in logs, exemplars on metrics) that turns three tools into one story.

Choose what evidence must survive, then price the collection path. A tail policy can only inspect traces that reach it; low SDK sampling changes the guarantee before the collector sees a span.

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.

Where linear models break: compounding growth, step functions, peak days and saturation cliffs. Forecast per constrained resource, backtest, subtract lead time to get the real order-by date.

Detectors earn their keep on seasonal aggregates and fleets of similar series, run in shadow mode with measured precision. They lie on low-volume series, bursty workloads and regime changes.

Internal platforms hide a trap: the direct user is an engineer, but the real traffic belongs to their customers. Define SLIs from the consumer's vantage and turn the error budget into roadmap currency.

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.

Both can be right, which is the whole point. Retransmissions mean a segment was not acknowledged, and the network is only one of the places that can happen.

Repeated action items are a measurable defect with a mechanical cause. Answering 'culture' without a mechanism describes the symptom back rather than fixing it.

Load balancing makes a per-host fault look like a flaky library. The exact rejection string tells you which way the offending clock leans before you log into anything.

Self-healing unavailability is a timeout arithmetic story. Pull the balancer's removal timestamps, lay them against the GC log, and the pause that ejects the instance will be sitting there in plain sight.

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.

Slow leaks hide inside restart cycles and percentage thresholds. Plot weeks of absolute memory against deploys, prove it with profiler deltas, and alert on predicted time-to-limit instead.

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.

Champions programmes die as mailing lists with a name. Survivors protect the time, pay in career currency, keep the job description tiny, and measure outcomes rather than attendance.

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.

Type-ahead is a latency budget wearing a search costume: keystrokes arrive every 200 milliseconds, so anything slower feels broken. Prefix indexes, freshness tiers, and typo tolerance are the scored parts.

Dual-writing from application code is the answer that fails quietly six months in. Change data capture, per-entity ordering, and a reindex you could run on a Tuesday are what interviewers score.

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.

Cron fires at wall-clock times; a scheduler reasons about data intervals and blocked frontiers. The scored details are per-partition idempotency and catch-up semantics.

A published event is an API with no version negotiation and consumers you cannot enumerate. The design is a registry that refuses an incompatible change at publish time, because after publication your options are all bad.

Registration coverage tells you a script ran. It says nothing about whether an engineer has ever found the portal worth opening.

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

Complaints measure volume and confidence, not cost. The loudest team is usually the one most comfortable complaining, which is not the same as the one losing the most time.

Every capability a platform accepts is a permanent operational commitment. Teams that cannot say no end up operating six things badly instead of two things well.

Facilitate a disputed design by stopping personal attacks, separating testable assumptions from priorities and assigning a decision owner.

Turn difficult feedback into a testable improvement, while checking its factual basis and keeping unfair or inappropriate treatment separate.

Plan an on-call transition around service readiness, responder capacity and authority, with rehearsed escalation and evidence that the operating burden is sustainable.

The question that separates people who have debugged a hung rollout from people who have read about one. The interesting half is not the signal, it is PID 1.

Ordering and retransmission are what TCP adds, and both of them cost time. Naming something that deliberately gives them up, and saying why, is what turns a textbook answer into a real one.

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 staple of every networking round, and the follow-up is always about TLS termination. Knowing which layer sees what decides most of the answer.

The oldest question in systems interviewing and still the best, because it is unbounded: every layer you can describe is another layer you could debug.

Five stages, and which one you are stuck in tells you what to fix. A machine that reaches a GRUB prompt has a different problem from one that hangs waiting on a filesystem that no longer exists.

Compare proxy, hosted and group repositories. Trace a tested artifact into production, and understand when a cache can keep builds running during an upstream outage.

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.