Zomato Interview Experience

At the time of writing this, Zomato was hiring only through referrals. I was fortunate to get one from a friend working there, and my interview was scheduled for the following week.

Zomato is known for diving deep into your resume, so I made sure to polish mine thoroughly before the interview.

Round 1

The first round started with a pleasant surprise — speaking in English wasn’t mandatory. In fact, the interviewer preferred speaking in Hindi.

After a few not-so-awkward exchanges where he asked questions in Hindi and I responded in English, I decided to switch to Hindi too. The smile on the interviewer’s face made it feel like the right call. 😄

Resume Discussion & SQL Design

We began with a brief discussion about my resume and my projects. This naturally led into a conversation about my understanding of relational databases.

I was presented with a complex SQL schema and a set of requirements. The task wasn’t to write queries immediately, but to explain how I would approach solving them. It felt open-ended, which I appreciated.

I started by simplifying the schema—essentially denormalizing the tables—which was exactly the kind of thinking the interviewer was looking for. From there, we discussed indexing strategies, query formulation, using views for complex joins, and even considered ideas like cold storage or removing older entries to boost performance.

DSA Question

The DSA part involved a standard 2D DP problem — something you’d be familiar with if you’ve gone through the CSES problem set. I explained my approach, wrote the code, and justified each part. Nothing too fancy here.

The round wrapped up on a positive note. In fact, I was given a green signal for Round 2 right there, and the next round was scheduled within a few days.

Round 2

Again, the interview was conducted in Hindi, and we dove straight into a deep resume-based discussion. The interviewer was especially interested in a project I had worked on involving MongoDB scaling and design choices.

MongoDB Design Question

The conversation shifted to comparing Replica Sets vs Sharding, and the trade-offs of each.

Then came the first question:

“Suppose you're using a Replica Set architecture. Now, because of tightly coupled read and write operations, there's a high chance of stale reads. How would you solve this?”

This was another open-ended question. I started by clarifying the requirements and then proposed building a custom abstraction layer to route requests more intelligently.

We discussed DB locks, their downsides, and alternatives like in-memory row-level locks scoped per session. Once the interviewer was satisfied with the brainstorming, I was asked to write a rough implementation.

I used a simple HashMap-based approach, and we explored ways to enhance it using TTL (Time-to-Live) for the locks. The interviewer seemed happy with this.

DSA Question

Next was a straightforward greedy + sorting problem. The goal was to get a correct solution as quickly as possible. I wrapped this up in around 15–20 minutes.

Bonus Design Question

Since we had time left, I was given another design problem:

“You’re given a key-value DB that can store only 100 keys. How would you store 1000 key-value pairs?”

This was essentially a hashing + string manipulation question, and I explained my approach clearly. The interviewer was satisfied.

Twist

At this point, the interviewer confirmed I was interviewing for an SDE-2 role and mentioned that the previous rounds were mostly at an SDE-1 level. So, they scheduled an additional round to assess my suitability for the SDE-2 position.

Round 3

Right off the bat, we did a quick resume overview, followed by some design discussion. Then came the main challenge:

System Design – Geohashing

The question was to design a system involving geohashing — something relatively standard in backend interviews. The catch? I hadn’t studied geohashing before.

So I tried approaching the problem with various optimization techniques, but the interviewer kept presenting edge cases that broke my solutions.

Eventually, with some very generous hints (honestly, almost the entire answer 😅), I got the hang of what geohashing was.

From there, I was able to design a functional system. The overall architecture was simple, but effective. The interviewer seemed content, though they did point out that I missed the geohashing concept initially.

Still, I got the thumbs-up for the SDE-2 role.

Verdict

The final round was onsite and focused more on cultural fit than technical depth. A few days later, I received the offer.

As for compensation — well, let’s just say Leetcode might have a pretty accurate idea. 😉