How to pass the Zomato SDE-2 low-level design interview

Getting an SDE-2 offer at Zomato means surviving one of the toughest technical loops in the Indian tech scene. While plenty of companies just test you on abstract algorithmic puzzles, Zomato cares a lot more about practical, production-ready engineering. The real make-or-break moment is the Low-Level Design (LLD) or Machine Coding round. You get 90 to 120 minutes to design, code, and demo an optimal, thread-safe, in-memory system that actually works. A classic, notoriously tricky archetype they love to ask is the concurrent restaurant timing and live status engine. We are going to break down exactly how you should approach, optimize, and talk through your solution so you can clear this hurdle.

The Zomato SDE-2 Interview Process

Before we get into the technical weeds of the LLD round, you need to know exactly where it sits in Zomato's broader hiring loop. They designed the SDE-2 process to rigorously test your coding speed, architectural foresight, and overall cultural fit.

Deconstructing Zomato's LLD Expectations

Zomato's Machine Coding round definitely isn't a whiteboard pseudocode exercise. You'll be writing executable code right in your IDE, and it has to compile and pass test cases before the clock runs out. The interviewers are hunting for four main pillars of solid software engineering. They want to see clean separation of concerns using standard design patterns, smart data structure choices tailored to specific read/write access patterns, bulletproof concurrency handling for multi-threaded environments, and smooth edge-case management. Ultimately, you're proving you can write code they could merge into production tomorrow.

How do I design a high-throughput restaurant timing engine?

The core problem usually hits you like this: design an in-memory system where restaurants can update their operating hours (say, Monday 09:00 to 17:00, or Tuesday 18:00 to 23:00). Meanwhile, millions of users are concurrently querying to see if a specific spot is open or closed. Your system has to handle massive read throughput from users checking statuses, alongside occasional write throughput from restaurants updating their hours. The rookie move here is storing a list of start and end time objects for each day, then iterating through them for every single query. Doing that gives you an O(N) read time per query. For a high-throughput system, that's completely unacceptable.

How should I choose between interval trees, segment trees, and minute bitmaps?

The moment candidates hear the phrase 'time intervals', they usually jump straight to Interval Trees or Segment Trees. Yes, an Interval Tree gives you O(log N) search time for overlaps. But trying to implement a perfectly balanced interval tree from scratch in 90 minutes is a huge unforced error. It's incredibly bug-prone and just overcomplicates everything. A much better, senior-level approach leans on a very simple, hard constraint: there are exactly 1440 minutes in a day.

Forget the complex trees. You can represent a single day for any restaurant using a simple boolean array of size 1440. Each index maps to a specific minute of the day, running from 0 to 1439. If a place opens at 09:00 AM (which is minute 540), you just set the array at index 540 to true. Suddenly, your read complexity drops to O(1). Want to check if they're open at 14:35? Convert the time to minutes—14 * 60 + 35 equals 875—and check if array[875] is true. To handle a full week, you just scale up to a 2D array of size 7 by 1440. The space complexity is basically nothing. We're talking 7 * 1440 booleans, which comes out to roughly 10 kilobytes per restaurant. Even with 100,000 restaurants, the whole thing easily fits into a few megabytes of RAM. Choosing this data structure proves you value pragmatic, working engineering over pure academic complexity.

How do I optimize concurrent read-write access for thread safety?

Handling concurrency is what actually separates SDE-2 candidates from the SDE-1s. In the real world, thousands of users could be reading a timing array at the exact same moment a restaurant owner decides to update it. If you just slap a generic synchronization block on the entire read and write method, you'll create a massive bottleneck. You'd effectively be single-threading your read operations, which kills performance.

A much better approach uses a Read-Write Lock mechanism—think ReentrantReadWriteLock in Java or sync.RWMutex in Go. Since your system is heavily read-biased, you want to let multiple threads acquire the read lock simultaneously so they can check that boolean array without waiting on each other. When a restaurant actually updates its timings, the system grabs the write lock. This temporarily blocks any new reads, updates the 1440-minute array, and then releases the lock. You get strict consistency, and you don't have to sacrifice your read throughput to get it.

• Read Path: Convert the current time to a specific day and minute. Acquire the Read Lock. Return the value located at array[day][minute]. Finally, release the Read Lock.
• Write Path: Acquire the Write Lock. Iterate straight from start_minute to end_minute, setting those values to true. Release the Write Lock.
• Advanced Alternative: If you want completely lock-free reads, try using an AtomicReference pointing to an immutable boolean array. When a write happens, create a brand new array, apply your updates, and then swap the reference atomically. This is the Copy-on-Write pattern, and it's absolutely perfect for workloads that are read-heavy but write-rare.

How should I handle edge cases like crossing midnight and timezones?

Interviewers love to deliberately poke at your design to see how it handles edge cases. The biggest trap in the timing engine problem is dealing with shifts that cross midnight. Say a restaurant opens at 22:00 on Friday and closes at 02:00 on Saturday. If your code just blindly loops from start_minute to end_minute, it's going to fail. The end minute (120) is numerically less than the start minute (1320), so a basic loop breaks entirely.

Your write logic has to catch this condition natively. If the end time is smaller than the start time, you need to split the interval into two distinct operations. First, fill out the Friday array from 22:00 up to 23:59. Next, fill the Saturday array from 00:00 to 02:00. You also have to normalize timezones. The cleanest practice is requiring every incoming read and write request to be in UTC. Alternatively, you can store a timezone offset at the restaurant level, then normalize the incoming query time to that specific local time before doing the array lookup.

How do I implement and communicate this in a 90-minute live round?

Poor time management will kill your chances in a machine coding round faster than anything else. Don't just start hacking together logic the second the timer starts. Spend your first 10 minutes strictly defining your core models and interfaces. Sketch out a Restaurant class, a TimingService interface, and an InMemoryTimingEngine implementation. Talk through these contracts with your interviewer so you know you're both on the exact same page.

Once you're aligned, build out the core 1440-minute array logic without any concurrency. You need a working baseline first. Prove you can map times to indices correctly and handle that tricky midnight crossover. Only after your single-threaded version passes basic test cases should you start dropping in ReadWriteLocks or AtomicReferences. Finally, spin up a quick multi-threaded test using an ExecutorService or Goroutines. This proves your locks actually prevent race conditions. Talking through this phased approach shows real engineering maturity, and it guarantees you always have a working piece of code to fall back on if the clock runs out.

Acing the Zomato Machine Coding Round

Clearing the Zomato SDE-2 LLD round takes a mix of pragmatic data structure choices, rock-solid concurrency fundamentals, and fast execution. Choosing a minute-level bitmap instead of complex trees saves you precious interview time. It also shows you deeply understand memory and cache efficiency. When you successfully implement read-write locks, you're proving you can build production-ready systems capable of handling real-world traffic patterns.

The only way to really guarantee success here is by practicing these specific patterns under strict time pressure. Put your energy into mastering in-memory concurrency, clean interface design, and rigorous edge-case handling. If you nail those concepts, you'll be more than ready to tackle whatever machine coding challenge Zomato decides to throw your way.