Zomato Interview Guide (2026)

1Snapshot, read this first#

The one thing to internalize about Zomato:

• They care that you can build something real and reason about how it behaves under load, not that you memorized a LeetCode list.
• Code quality and clear thinking beat clever tricks, every time.
• Your interviewers think in lakhs of orders, live maps, and payment settlement, so bring that vocabulary with you.

2Getting the call (the part most guides skip)#

Zomato now operates under the parent brand Eternal, which also runs Blinkit and Hyperpure. Four main doors in: campus placements, off-campus drives, referrals, and inbound applications on the careers page and LinkedIn.

Referrals are the strongest door.

• A referral routes your resume past the general pile and often gets a recruiter reply within days instead of silence.
• Find engineers on LinkedIn and send a short, specific note: "I'm applying for SDE-2 backend, here's my resume and a 2-line why-me."
• Make it effortless to forward: attach the PDF, name the exact req ID or team, write the two lines they can paste.
• One screenful, max. A wall of text gets ignored.

Resume rules.

• One page for anyone under about 6 years.
• Lead every bullet with impact and a number.
• If a bullet has no number, either find the number or cut the bullet.

Compare these two:

• Weak: "Worked on the backend of the order service."
• Strong: "Rebuilt the order-status service to cut p99 latency from 480ms to 110ms and handle 3x peak traffic during flash sales, using Redis caching and read replicas."

Why the strong one works:

• It names the system, the metric, the technique, and the scale.
• That is exactly the vocabulary a consumer-internet company recognizes.
• It is the difference between a skimmed bullet and one that earns a phone screen.

ATS keywords.

• Mirror the job description exactly.
• Backend roles usually mean Java or Go, Spring Boot, microservices, Kafka, Redis, PostgreSQL/MySQL, AWS, Docker/Kubernetes.
• Mobile means Kotlin/Swift, Jetpack Compose/SwiftUI.
• Put your strongest stack in a dedicated "Skills" line near the top so both the parser and the human see it in five seconds.
• Match the exact spelling ("PostgreSQL" not "Postgres" if that is what they wrote), because many first-pass filters are literal string matches.

How people actually get shortlisted here:

• Off-campus candidates usually start with an online coding test (often HackerRank or similar), 2-3 DSA problems in a 60-90 minute window.
• Clear it cleanly (all test cases pass, not just the samples) and a recruiter screen follows.
• Campus candidates go through a coding test plus back-to-back interviews on drive day.
• Keep your coding profiles (GitHub, a deployed side project) linked.
• A real shipped project with a live URL is a huge tiebreaker for a product company, because it proves you can finish, not just solve.

3The loop at a glance#

How the loop flexes by level:

• SDE-1: a machine-coding round or a second DSA round often replaces system design.
• SDE-2 and up: expect both a machine-coding and a system-design round.
• Every level: the bar-raiser or HM final can override a "they coded fine" signal if your ownership and judgment feel thin.

4The coding / technical rounds, patterns, not problems#

Zomato's DSA rounds sit squarely in the Medium-to-Hard band. No obscure competitive-programming puzzles. The questions test whether you reach for the right data structure and can argue complexity.

The patterns they reuse:

• Arrays, strings, hashing: frequency maps, two-pointer, sliding window (longest substring without repeats, subarray sum equals K, anagram grouping).
• Trees and graphs: BFS/DFS, level-order, lowest common ancestor, topological sort, shortest path (Dijkstra flavor). Delivery and routing make graph questions natural here ("shortest route for a rider across a city grid").
• Heaps and intervals: top-K (top restaurants by rating), merge intervals, meeting rooms, "schedule N deliveries" style problems.
• Dynamic programming: knapsack variants, longest common subsequence, edit distance, coin change, matrix path DP. Usually one DP question, medium difficulty. They rarely go hard-DP; they want a clean state and transition.
• Binary search: on arrays and on the answer space ("minimum capacity to ship in D days", which maps neatly onto delivery-batching).
• Stacks and queues: valid parentheses, next greater element, LRU cache (overlaps with design, and they do ask you to build it from scratch).

How to practice.

• Do not grind randomly. Pick about 120 problems across these buckets (NeetCode 150 or the LeetCode patterns list are good spines).
• Solve each, then re-derive the pattern a day later without looking at your old solution.
• Depth beats volume: 120 you can rebuild cold beats 400 you half-remember.
• Time yourself: medium in about 25 minutes, hard in about 40.
• If a medium takes you 45 minutes, that is a bucket to drill, not a problem to skip past.

How to win the round (this is where offers are made or lost):

1. Clarify first. Restate the problem in your own words. Ask about input size, duplicates, empty input, negative numbers, output format. This signals maturity and prevents you from confidently solving the wrong thing for 20 minutes.
2. State a brute force, then optimize. Say the naive approach and its complexity out loud, then "we can do better by..." Interviewers want the path, not just the destination. Jumping straight to optimal with no explanation often scores lower than walking the ladder clearly.
3. Narrate while you code. Silent coding is the single top reason strong coders get mid scores here. "This map holds the last-seen index, so when I hit a repeat I jump the left pointer."
4. State complexity. Give time and space in Big-O before they ask. "This is O(n) time, O(k) space where k is the window size."
5. Test your own code. Walk a normal case, an edge case (empty, single element, duplicates, all-same), and a large case. Catching your own bug before the interviewer points at it is one of the strongest signals you can send.

5Machine-coding / low-level design, the round that separates candidates#

This is the most Zomato-flavored round and the one most candidates underprepare. You get a real-world prompt and 60-90 minutes to build a working, runnable mini-application from scratch in your language of choice, with clean object-oriented design.

What you are graded on:

• Correctness, class modeling, extensibility, and code hygiene.
• Not fancy algorithms. A clever algorithm earns you nothing if your classes are a mess and the thing does not run.

Classic prompts in this space:

• Design a food-ordering / restaurant management system (menu, cart, order, payment states).
• Design a splitwise / expense-sharing app (users, groups, balances, settle-up).
• Design a parking lot (slots, vehicle types, ticketing, pricing).
• Design an elevator or ride-matching dispatcher.
• Design an in-memory key-value store or a rate limiter.

A framework that works:

1. Clarify scope and nail the core use cases. Write them down. Agree out loud on what is in and out of scope so you are not punished for skipping something you deliberately deprioritized. "I'll build order placement and payment state, I'll stub notifications, agreed?"
2. Model the entities first. Identify nouns (User, Order, MenuItem, Payment) and give each a clean class with clear responsibilities. Favor composition over deep inheritance. One class, one job.
3. Apply the obvious design patterns, named out loud. Strategy for interchangeable pricing or payment methods, Factory for object creation, Observer for notifications, State for order lifecycle (PLACED to PREPARING to OUT_FOR_DELIVERY to DELIVERED). Naming them shows intent and saves the interviewer from guessing.
4. Code it to run. Write a small main or test driver that exercises the happy path plus one edge case. "Working code I can run" beats "elegant code that doesn't compile." Running low on time? Cut scope, not correctness.
5. Leave room to extend. Mention how you would add a new payment method or order type without touching existing classes. That is the open/closed principle, and interviewers love hearing you reach for it unprompted.

Hygiene that quietly earns points:

• Keep classes small and avoid the god-class that holds all the logic.
• Use enums for fixed sets (order status, vehicle type).
• Manage shared state (concurrency, if asked) with clear locking around the critical section.
• Practice by building two or three prompts above end to end under a timer first. The first time you build Splitwise should not be in the interview; by fight day your fingers should already know the entity layout.

For SDE-2 and senior candidates there is also a system design round. Use this structure:

1. Scope and scale. Clarify functional requirements and estimate QPS, data size, read/write ratio. For a food-delivery feature, call out lunch and dinner peaks explicitly: traffic is spiky, not flat. Separate the read-heavy parts (search, menu) from the write-heavy parts (orders, location pings).
2. High-level design. Draw clients, API gateway, services, databases, caches, and queues. Keep it legible before you go deep.
3. Deep dive where asked. Data model, how you shard, cache strategy, how you handle consistency.
4. Scale and failure. Replication, partitioning, rate limiting, idempotency for payments, graceful degradation when a downstream is slow (serve stale menu from cache rather than fail the page).
5. Trade-offs. Say what you optimized for and what you gave up (consistency vs availability, latency vs cost, freshness vs load). Naming the thing you sacrificed is what separates a senior answer from a confident wrong one.

A simple shape for a real-time order-tracking deep dive:

Prompts they realistically ask:

• Design the restaurant search and discovery service.
• Design real-time order tracking (location updates at scale).
• Design a surge/dynamic-pricing system.
• Design the notification service.
• Design a rate limiter.
• Design a payment/wallet ledger with idempotency.

Study caching, sharding, consistent hashing, message queues (Kafka), and idempotent writes, because the payment and tracking prompts turn on exactly those.

6Behavioral & culture fit#

Eternal/Zomato's culture leans hard on extreme ownership, bias for action, frugality, first-principles thinking, and customer obsession.

• Founder-led and famously direct. They value people who ship, take a problem fully on themselves, and argue a decision from first principles rather than "because that's how it's done."
• The company's public writing celebrates high-agency people who do more with less.
• The interview reflects it: expect to be pushed on who exactly did the work and why you chose what you chose.

Prep 5-6 STAR stories before your interview:

• A time you owned something end to end.
• A time you shipped fast under ambiguity.
• A time you disagreed and committed.
• A time you failed and what you learned.
• A time you dug into a hard bug or metric.
• Always end with a number. Use "I" statements, not "we", because the whole game is telling them what you personally drove.

One full worked STAR example:

• Situation: Our checkout service was timing out during weekend peaks, and roughly 4% of orders were failing at the payment step.
• Task: As the owning engineer I had to cut the failure rate without adding infra cost, within one sprint.
• Action: I traced the failures to synchronous calls to a slow third-party payment gateway. I made the payment confirmation asynchronous with a retry queue, added idempotency keys so retries couldn't double-charge, and set a short circuit-breaker so a slow gateway degraded gracefully instead of cascading into timeouts across the service.
• Result: Payment-step failures dropped from 4% to 0.3%, we recovered an estimated ₹12 lakh in weekly orders that were previously lost, and the pattern was reused by two other teams.

Why this shape wins:

• Ownership (you owned it), first-principles trace to root cause, frugality (no new infra), and a quantified result.
• Build each of your stories to hit those same four beats.

Also prepare thoughtful questions for them:

• Ask about on-call culture, how decisions get made when two engineers disagree, what a great engineer on this team shipped in their first six months.
• Having no questions reads as low interest.
• For a founder-led company that notices agency, low interest is a quiet reject.

7Your prep plan#

4-week plan

• Week 1: DSA foundations, arrays, strings, hashing, two-pointer, sliding window. 5-6 problems/day. Re-derive patterns, don't just read solutions.
• Week 2: Trees, graphs, heaps, intervals, binary search, DP. Start timing yourself (medium in 25 min). Begin one machine-coding build (parking lot or splitwise).
• Week 3: Machine-coding/LLD, build 3 full apps under a timer; drill Strategy/Factory/Observer/State until you reach for them without thinking. If SDE-2+, start system design (one design/day).
• Week 4: Mock interviews, behavioral STAR stories written and rehearsed out loud, revisit weak DSA buckets, read Zomato/Eternal engineering blogs and shareholder letters so the culture tone is in your voice.

2-week plan

• Days 1-5: Blast the highest-frequency DSA patterns (hashing, sliding window, BFS/DFS, heaps, one DP family). Medium difficulty, timed.
• Days 6-9: Build two machine-coding apps end to end; name your design patterns out loud as you go, exactly as you will in the room.
• Days 10-12: System design basics (if SDE-2+): caching, sharding, queues, idempotency, two full mock designs.
• Days 13-14: Write STAR stories, do 2 mock interviews, rest the night before.

2-day crash plan

• Day 1 morning: Review Big-O, re-solve 6 medium problems across your weak buckets.
• Day 1 afternoon: Build ONE machine-coding app (splitwise or parking lot) fully, running, with a driver that prints output.
• Day 2 morning: Skim a system-design cheat sheet (if relevant); write 4 STAR stories with numbers.
• Day 2 afternoon: 1 timed mock DSA + 1 timed machine-coding. Sleep early. A rested brain narrates better than a crammed one.

8Why people get rejected at Zomato#

1. Silent coding. They solved the DSA problem but never explained their thinking, so the interviewer couldn't assess reasoning and marked it a no.
2. Brute force with no optimization. Stopping at the naive solution and never discussing or reaching the optimal time complexity, which reads as "can't improve code under pressure."
3. Messy machine-coding. A single god-class, no clear entities, hard-coded logic, and nothing that actually runs at the end. The most common silent killer, because candidates feel busy the whole hour and still fail.
4. No product/scale sense. Designing as if traffic is uniform, ignoring the dinner-rush peak or payment idempotency. For a consumer company that lives on spiky load, that is a red flag.
5. Weak ownership stories. Behavioral answers that are vague "we did X" team summaries with no personal action and no number.
6. No curiosity. Zero questions back, no interest in the product, treating it like a generic interview rather than a company they actually want to build at.

9The offer, comp & negotiation#

Zomato/Eternal compensation is typically base + a joining bonus + equity (RSUs/ESOPs), with the equity component meaningful at mid and senior levels given the listed parent.

• Rough India ranges: SDE-1 total around ₹18-32 LPA, SDE-2 around ₹32-55 LPA, senior/SDE-3 higher and more equity-weighted.
• Exact numbers vary by team, level, and your current comp.

Negotiation tips tuned to this context:

1. Negotiate total, not just base. Ask how base, joining bonus, and equity split, then push on the lever with the most room, often equity or the joining bonus rather than base, since base bands are tighter.
2. Use a competing offer honestly. A real competing number is the strongest lever you have. Share it plainly and do not bluff, because the recruiting team is experienced and a caught bluff costs you all your goodwill.
3. Anchor on level, not rupees. If your scope and system-design depth argue for SDE-2 over SDE-1, make that case first. A level bump moves every component at once and compounds across every raise and refresh for years, worth far more than squeezing the base.

Always get the final offer in writing with the equity details (number of units, vesting schedule, current value, cliff) spelled out before you accept anything verbally.

10FAQ#

Q: How hard is the DSA bar? A: Medium to Hard LeetCode, with an emphasis on reaching the optimal solution and clearly explaining it. Clean, communicated code beats clever, silent code every time.

Q: Is the machine-coding round really that important? A: Yes. For a product company it's often the deciding round. Practice building 2-3 full apps end to end so your class design and running code are second nature and you spend the hour thinking, not remembering syntax.

Q: Do I need system design as a fresher? A: Usually not for SDE-1, that round typically appears from SDE-2 up. Freshers should be solid on OOP, DBMS, OS, and networking basics instead, which do come up in the HM and bar-raiser chats.

Q: Which language should I use? A: Whatever you're fastest and cleanest in, commonly Java, Go, C++, or Python. For machine-coding, pick a language whose OOP and standard library you know cold, this is not the day to try a new one.

Q: How long does the process take? A: Typically 2-4 weeks end to end; campus and some off-campus drives compress everything into a single day.

Want a personalized, dated prep plan built around your interview date and target level? Map your available weeks to the 4-week, 2-week, or crash plan above and start today.