DevOps Engineer Interview Experience at Zomato – 2026

This brief recruiter screen is notably faster-paced than most other companies' opening rounds, matching what several candidates describe as Zomato's rapid scheduling style. The recruiter asks about current infrastructure responsibilities, specifically whether the candidate has direct experience with high-throughput, low-latency systems given the quick-commerce vertical's tight delivery-time SLAs, and confirms availability to interview later that same week rather than scheduling weeks out.

This round opens with a project-based discussion, going through what infrastructure was personally owned versus supported, then moves into designing a rate limiter for an API gateway backed by Redis — a sliding-window counter using a Redis sorted set keyed by client ID, with old entries evicted lazily on each check rather than via a separate cleanup job, is the expected direction. Two DSA-style questions grounded in the same domain typically follow: one array problem on finding the maximum number of non-overlapping delivery time windows a single rider could fulfill (solved with a greedy approach sorting by end time), and a string problem involving grouping restaurant names by a normalized key (solved using a hash map keyed by sorted character counts). The round closes with basic SQL and NoSQL discussion and a short segment on network throttling.

Candidates are asked to design the infrastructure supporting order-to-delivery latency tracking for a quick-commerce vertical where delivery-time SLAs are much tighter than traditional food delivery. Instrumenting each stage of the order lifecycle (placed, accepted, picked up, delivered) with timestamped events flowing into a stream processor, computing rolling p95 latency per dark-store location rather than a single citywide average, is the strong approach — since a citywide average would hide a specific store or zone falling behind its SLA. A common follow-up probes how to alert on this without generating excessive noise during genuinely high-demand periods where some latency increase is expected and not itself a problem — a dynamic threshold based on the store's own recent rolling baseline rather than a single static SLA number applied uniformly regardless of current load addresses this well.