Flipkart SRE / Platform Engineer interview questions

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.

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.

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.

Table full is the symptom everyone knows. The interview answer lives one layer down: per-state timers, the five-day ESTABLISHED default, and what conntrack -S says about hash pressure.

The answer that lands is about one epoll loop per core, not config snippets. Master versus worker duties, the arithmetic of worker_connections, and the limits people forget to raise.

Most throughput tests measure the tester, not the network. Single stream versus parallel, slow start, sender-side retransmits, and the CPU ceiling: how to produce a number you can act on.

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.

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.

S3 access failures are rarely about the bucket policy alone. The caller, object ownership and network path determine which authorization checks apply. Start with the failed request and trace changes across those boundaries.

Spreading instances across availability zones is not the same as surviving an AZ failure. The candidates who know this can name the four coupling points that quietly re-unify your blast radius.

The cheapest storage class is rarely the cheapest answer. Retrieval pricing, minimum durations and per-transition fees decide whether a lifecycle rule saves money or manufactures waste.

Large object uploads are a reliability design problem, not a bandwidth one. Parts, retries and the completion call decide whether a flaky link costs one chunk or the whole night.

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

Origin access control pins the bucket to your distribution, and signed URLs or cookies decide who plays what. Get the expiry wrong and the leak comes back with a signature on it.

Strip the marketing and Aurora is a rewrite of the storage layer: the log is the database, committed to a quorum across three AZs. Know when that machinery pays and when it just bills.

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.

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

Guaranteed capacity and discounted capacity are different products. Peak season needs both, arranged in layers and verified with a game day before the traffic arrives.

A cluster boundary does not always create a new cloud identity. Inspect the workload pool and principal identifier before assuming a leaked key.

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.

A green plan is evidence, not proof. Build the pyramid: lint in seconds, policy on every PR, real-cloud verification only where shared modules and money justify the burn.

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.

Managed platforms sell governance, not execution: locked state with RBAC, plans on every pull request, and audit logs. Price them per resource under management against the engineering hours self-hosting quietly burns.

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.

Promote the same code version, then generate and approve a separate saved plan against each environment's state and inputs. Pin, apply each reviewed artifact in sequence, and let the gates rise as you approach production. Environment branches quietly undo all of it.

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.

Priority is one number with three separate effects: scheduling order, preemption victim selection, and eviction order under node pressure. Conflating those is the trap; designing tiers that survive both a full cluster and a hot node is the pass.

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.

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 interviewers want, 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.

Heartbeats, conditions and taints are the only vocabulary the control plane understands. NPD translates journald and kernel ring messages into that vocabulary; custom plugins carry your hardware's dialect.

Self-heal did exactly what it was configured to do. The senior answer is not switching it off; it is designing the Git path and the sync order so nobody bypasses the system at 3am again.

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.

Deployment and release are two decisions, not one. The flag patterns that buy you instant reversibility, and the retirement discipline most teams skip.

A freeze enforced by email is a suggestion. Tier services, put the window in deploy tooling, price exceptions honestly, and judge the policy by incidents prevented.

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.

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.

Most candidates recite the pull model and stop. The interviewer asking this wants the storage engine story, because that is where Prometheus hurts in production: crash recovery, cold queries, disk death.

The data-path question separates people who have sized a cluster from people who installed one. Shard sizing, refresh versus flush, and each ILM phase carry one specific failure mode apiece.

The roles question is really a delegation test: can you split commanding the incident from fixing it? Name the roles, the comms cadence, and the handoff discipline that keeps 3am coherent.

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.

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.

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.

The most-asked scenario question in DevOps interviews, and the one where candidates most often list commands instead of reasoning. 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.

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.

Automation can renew a certificate without deploying it correctly. Check the served leaf and chain, the client trust store and the exact verification failure.

An idle database with a starved application is the tell. The connections are held, not used. More database capacity does not release leaked connections.

One saturated core on a proxy is rarely about raw traffic volume. It is a parallelism failure with three usual suspects, and the per-thread view names the culprit in minutes.

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 reflex is rollback and it is usually right. There is exactly one class of failure where undo makes things worse, and knowing it is the entire interview.

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.

The backup is doing its job and the database is paying for it. Attribution first, then enforcement that actually binds on modern kernels, because priority support depends on the active kernel and IO scheduler.

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.

A public registry throttles by source IP and your whole fleet shares one. Why fifty nodes count as a single anonymous user, and authentication and caching changes that reduce upstream demand.

Mixed resolution after a transfer is not propagation voodoo. Compare the parent delegation, authoritative answers and validation results. NXDOMAIN and SERVFAIL are clues; neither names a unique cause.

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.

Most clusters fail an RBAC review on the same handful of patterns. Naming them concretely, plus the namespace-first design that prevents them, is what separates operators from tutorial readers.

Reciting injection classes you cannot fix is the trap. The scored move maps each risk category to a lever an ops or platform engineer owns, from response headers to metadata endpoints.

A WAF matches patterns in HTTP and stops there. Know exactly which classes it catches, which it cannot see, and what closes the gap, because block-dashboard confidence is how breaches happen anyway.

Break-glass exists to restore login when the identity provider is the thing that died. Few accounts, sealed hardware factors, an alert on every authentication, a printed runbook and a quarterly drill.

Volumetric floods die at the anycast edge; everything else reaches your origin anyway. The origin leak, expensive endpoints and unproxied surfaces decide whether a CDN is armour or decoration.

Most insider incidents are boring: a departing engineer copies a repo, a contractor keeps a token. Buy hygiene rather than surveillance, and protect the culture that makes people report their own mistakes.

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.

The catalog is the easy half. The scored half is stampede dynamics: one hot key expiring can multiply origin load by a thousand in a second, and there are three distinct fixes.

The most rehearsed design question, which is exactly why interviewers score the parts blog posts skip: redirect semantics, key generation under failure, and analytics kept off the hot path.

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.

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.

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.

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.

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

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.

Ladders and player logic are the warm-up. Cache topology, egress arithmetic, and knowing which quality metric actually predicts churn are what separate the answers.

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.

Everyone quotes the discount. Fewer candidates can describe what happens when a notice arrives late or a worker disappears without completing shutdown and why some workloads shrug it off while others lose hours of compute.

Data transfer appears on nobody's architecture diagram and reliably appears on the invoice. The strong answer enumerates the taxed flows, ranks the levers, and knows which tax is worth paying.

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.

Most of your rows are read rarely and cost the same as the ones read constantly. Tiering pays for itself only when access patterns are honest, which is why the audit comes before the architecture.

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.

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.

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.

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.

Burnout questions look soft but score systems thinking. Interviewers want the signals you watched, the structural fixes you made, and the number that proved the fix worked.

Noisy-neighbour questions score evidence, translation and patience. Show how the other team's fix becomes their idea, and when the risk needs immediate incident coordination.

A launch-versus-guardrail negotiation. Interviewers score whether you price the risk in the stakeholder's currency, offer a path that still serves the business goal, and leave the final call with a named owner.

A standards confrontation, not a mentoring story. Interviewers score whether you diagnose why the shortcut is rational, fix the system that rewards it, and confront the pattern privately with evidence.

Asked in almost every cloud screen, and most candidates recite the table without ever naming the failure it causes. The ephemeral port range is the whole answer.

The question that separates console users from people who have debugged a permissions failure across accounts. Evaluation order is deterministic and knowing it makes AccessDenied readable.

A design question with a clear answer at this scale, and the reasoning is what scores. The three options solve different problems and peering and Transit Gateway connect networks while PrivateLink exposes services.

Most candidates can sell serverless. The question asks you to argue against it, which needs a real understanding of the execution model rather than the marketing.

Trace the route and return path before changing rules. First establish whether the failing connection uses IPv4, IPv6 or a private service endpoint.

The junior-filter question that still separates candidates who understand the model from those who memorised a definition. The answer is three mechanical differences and one economic one.

Database redundancy still needs reconnecting clients. Distinguish the deployment type, then measure how promotion and DNS changes affect application requests.

The services-and-enterprise interview staple. There is a defensible answer and it is not 'always re-platform': the decision is a function of change tolerance, deadline reality and what the workload is worth.