Platform Engineer Interview Experience at Swiggy – 2026

The recruiter screen is mostly CV-based rather than a generic background chat, matching what several candidates separately describe as Swiggy's early-stage style. The recruiter walks through the resume line by line, asking for each infrastructure project listed whether it was owned end to end or supported as part of a larger team — and typically pushes back on a vaguely described migration project, asking for the specific before-and-after architecture rather than 'we modernized it.'

This timed online assessment has roughly 15 MCQs on Linux fundamentals, container networking, and AWS core services, plus two coding problems. The first asks for a function that takes a stream of delivery-partner location pings and returns the current estimated position by interpolating between the last two known points and a timestamp — straightforward linear interpolation works, with the edge case of a ping stream with only one point (no interpolation possible, return the single known point) worth handling explicitly. The second is a more standard array problem: given delivery time windows for multiple orders, find the maximum number of non-overlapping windows a single rider could fulfill, solvable with a greedy approach sorting by end time.

This round opens with a deep CV-based discussion of a Kafka consumer-lag incident, walking through exactly how the lag was detected (a consumer-group lag metric crossing a threshold in monitoring), what gets checked first (whether it's a slow consumer versus a partition-count mismatch causing uneven load), and what the actual fix looks like (increasing partition count and consumer parallelism together, since increasing consumers alone without more partitions does nothing). From there the conversation moves into Kubernetes: how to structure a Horizontal Pod Autoscaler policy for a service whose load is driven by two distinct daily spikes (lunch and dinner rush) rather than a single steady pattern, and whether to use CPU-based scaling or a custom metric tied to incoming order rate specifically. The custom metric is the stronger argument, since CPU alone lags behind an order-rate spike by the time pods actually start feeling load.

This systems-oriented round focuses on geospatial dispatch infrastructure at a conceptual level — given a service that needs to find the three nearest available delivery riders to a new order within a city, the question is how to structure the underlying data access pattern to make that query fast at scale, without expecting the full matching algorithm to be designed. A geospatial index (geohash-based bucketing) so the query can narrow to nearby buckets first rather than scanning all riders citywide is the expected direction, along with discussing the tradeoff of bucket granularity — too coarse and too many irrelevant riders get scanned, too fine and a rider near a bucket boundary might be missed despite being genuinely closest. The round closes with an incident scenario: order-to-delivery latency has silently crept up over several days without any single alert firing — checking whether it's concentrated in specific cities or time windows first is the right instinct, since an averaged platform-wide latency metric can hide a problem that is severe in one region and invisible everywhere else.

This hiring-manager round covers team structure, on-call expectations specifically around meal-time traffic peaks, and a scenario question: how to prioritize a platform reliability improvement against a product team's request to ship a feature faster, when the two compete for the same sprint capacity. Quantifying the reliability risk in terms of expected incident cost (frequency times blast radius) and bringing that number into the same prioritization conversation as the feature's business value, rather than treating reliability work as an unquestioned default priority or an afterthought, is the stronger answer.