PhonePe SRE / Platform 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.

Interviewers use this to sort memorised trivia from people who have chased a slow lookup. Three roles, one bit, and the caching rules most candidates repeat incorrectly.

Everyone knows ulimit -n. The interview question is which process inherits which value, why limits.conf did nothing for your service, and how you size the ceiling honestly.

One round trip versus two is the headline, but the ops-relevant differences hide in what stays plaintext, how resumption works, and which middlewares the change broke.

A reset at a suspiciously round number is a fingerprint, not a bug. Matching client keepalives to the lowest timer in the path is the fix; here is the full ladder of knobs.

Transparent versus explicit hugepages is a control question, not a size question. Fork-heavy stores suffer THP copy-on-write amplification while large-resident databases gain TLB reach.

Volume choice is IO-shape matching: burst buckets, provisioned IOPS and throughput designs behave very differently under mixed OLTP-plus-batch load. Average latency graphs hide the failure entirely.

A busy date key can throttle while table capacity remains available. Check the actual key distribution and throttling reason before adding capacity or shards.

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.

Four tiers, four bills. Stating RTO and RPO per tier turns a vague resilience wish into a decision leadership can actually price, and the testing story is where candidates fold.

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.

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.

One ForceNew attribute turns an edit into a destroy. Know the schema mechanics, the four lifecycle levers, and why create_before_destroy trades downtime for name collisions.

Static INI files die somewhere near two hundred hosts. Point inventory plugins at the systems that already know the truth, derive groups from tags with constructed inventory, and plan for stale hosts before they page you.

Terraform shapes the world; images define what boots inside it. Bake contents into versioned artifacts on a patch cadence, roll fleets by replacement, and keep user_data for identity and wiring only.

Distinguish a gated Terraform run workflow from a cloud controller that reconciles continuously. Both can start from Git, but they expose different approval, drift and credential boundaries.

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 two ideas that decide whether an operator is safe are level-triggered reconciliation and finalizer semantics. The partition question separates people who have written a controller from people who have installed one.

Multiple schedulers are supported, rarely understood, and dangerous in a specific way. The strong answer names the deadlock that gang scheduling fixes and the capacity race it can open.

Utilization-based scaling is the wrong sensor when work arrives as backlog. The design questions are threshold math against drain rate, reaction-time bounds from polling, and why lag-driven fleets oscillate without generous targets and idempotent consumers.

The gating instinct is right and the cardinality is wrong: init containers make every new replica race the same migration. Here is the once-per-release shape, plus the rollback rule that shapes all DDL review.

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.

Volumes grow online and never shrink; StatefulSet template changes normally replace pods ordinal by ordinal; supported in-place pod resize is a separate path. The craft is expanding storage first, gating rolls with partition, and letting replication lag set the pace.

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.

A billion-row backfill is a deployable, throttled, resumable job with checkpoints and verification gates. Ad-hoc scripts against prod are how it becomes an incident.

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.

Pipeline credentials are the keys to production and git history is forever. Scoping per stage, runtime-minted short-lived identities, expiry-enforced rotation, and a revoke-first leak playbook.

kubectl-edit happens when no designed emergency path exists. What an expedited lane may drop, what it must never drop, and how pre-authorization plus follow-up tickets keep it honest.

Metrics quantify impact, traces expose instrumented request paths, and logs describe individual events. Follow a slow checkout across all three while accounting for missing evidence.

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.

Metrics describe the server's experience; synthetics describe the user's. The strong answer designs a few money-path journeys from real geographies, pages only on persistent failure, and budgets for script rot.

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.

Status codes describe an HTTP failure category. Locate the component that emitted the response, then use its logs to distinguish connection, capacity and application failures.

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.

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.

One disk metric explaining a whole cluster's weirdness is the point of this question. Restarting etcd first turns a slow cluster into a down one, because a restarted member has to catch up before it can vote.

The reflex is rollback and it is usually right. Shared state, changed credentials and unavailable old artifacts can make an undo incomplete or unsafe. Verify those dependencies before choosing the recovery.

Spikes that march in step with BGSAVE are a page-size story, not a network story. Check actual huge-page usage, fork duration and copy-on-write pressure on the deployed kernel.

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.

Stop the source before tuning anything: kill the runner, revoke its credentials, shed test-shaped traffic at the edge, protect checkout. Forensics and guardrails only after customers stop feeling it.

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.

Running pods already have their images, so a credential expiry is invisible until something needs to start. That gap is why this always surfaces during an unrelated incident, at the worst moment.

Encryption is the part people focus on and the least interesting part. What you are buying is short-lived credentials, a revocation path and an audit trail, none of which an environment variable can give you.

Naming the replacement is the floor of this question. What scores is the audit-then-warn-then-enforce sequence and an honest answer about the vendor chart you cannot fix.

Tool selection is the shallow half of secrets questions. Senior answers live in the mechanics: dual-validity windows, consumer caching, and revocation you have actually tested rather than assumed.

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.

Trace who can read ciphertext, who can decrypt it and who can administer the keys. Key rotation, rewrapping and data re-encryption solve different problems.

Adoption is a product problem: templates with tested safe defaults, guardrails that start in audit mode, and metrics on paved-road share. Remove reasons to leave the road rather than writing memos.

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.

Every candidate says replication and failover. The scoring answer names the replication mode, states the resulting data loss window, and explains how the cluster avoids two primaries.

The Google-style NALSD round in miniature. The boxes are easy; what is being scored is whether the numbers fall out of Little's law before you draw them.

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.

CAP is not a menu of two letters per system. The scored answer knows what the theorem claims (narrowly), what most engineers misquote, and what a split-brain costs when both halves accept writes.

Timeouts guarantee uncertainty, not failure: the first request may have succeeded after the client gave up. The idempotency key pattern is the industry answer; the scored details are storage, expiry and concurrency.

The vocabulary question hiding real depth: which primitive replaces ORDER BY, why sharding by player is wrong, and what a 45,000 updates-per-second storm actually costs.

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.

Size stored sessions from expiry and creation rates, then decide how quickly logout must take effect and what failover may forget.

The difficult decisions are preserving offline intent and enforcing rules that span devices. Name the conflict classes and handle each deliberately rather than proposing a CRDT framework on instinct, because most of these conflicts have a domain answer that no merge algorithm can supply.

Listing the match job is table stakes. The scored material is the breaks taxonomy, the suspense account, and why every match must be replayable from immutable raw files.

Turning on strict mTLS across two hundred services in one change breaks everything that talks to something outside the mesh. Permissive mode exists so the migration can be observed instead of guessed at.

The tool emits recommendations; the programme is everything around it. Interviewers use this question to see whether you can turn a dashboard into landed changes without breaking production or trust.

Over-requested CPU and memory can prevent efficient node packing. Cutting them safely is a measurement problem with a reliability trap sitting in the middle of it.

CPU memory intuition fails on inference servers. The scarce resource is KV-cache, requests arrive with unseen context lengths, and the fix is queue-depth scaling plus admission control, not bigger pods.

Code rollouts ask 'does it work'; model rollouts ask 'is it better', and the second question has no HTTP status code. Shadow traffic, offline eval gates and quality canaries replace the 500-rate dashboards you cannot use.

Investigate on-call workload with responder feedback and paging evidence, then verify that relief and alert changes preserve service coverage.

Correct mistaken incident attribution with evidence, protect the response from a false diagnosis and follow through on the shared record.

Explain a reliability objection through the failing mechanism, a feasible alternative and an explicit decision about the remaining service risk.

Write an accurate incident review that examines the triggering action and contributing conditions, with corrective actions whose effectiveness can be checked.

Reduce a critical knowledge dependency with funded transfer work, tested operating documentation and demonstrated backup capability, without inventing personal motives.

Report an unnoticed production problem promptly through the right channel, distinguish actual impact from a near miss and verify the control or detection gap it reveals.

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.

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.

The arithmetic takes thirty seconds to learn and gets asked constantly. What it is really testing is whether you have ever had to size a VPC that could not be resized later.