Two things to know before interviewing for Zepto as a software engineer:

1. They don't have a good engineering department. Most of the codebase is randomly written without proper POCs, and they lack proper infrastructure in terms of CI/CD and security.
2. They don't have decent engineers yet who can revamp the issues mentioned in point 1.

So, if you are a good developer, you may be either rejected (read on to know more) or squeezed to work on their unstructured engineering team (read on to know how I know the above points, even if I didn't get selected).

Interview Process:

They have 3 to 4 rounds of interviews.

First Round: Problem Solving

It is outsourced to an external agency, Interview Vector. They interview on LeetCode with Easy to Medium level questions. Since I solved the question within 10 minutes, we continued having some good discussion on the technology.

Second Round: LLD

As most of the reviews read, and as per my point 2 above, they don't have engineers even for interviews. The developer who interviewed me had a decent experience in terms of years, but apparently, he was a hopper and never worked at any company for more than a year. Because of which, he lacked the basic understanding of manageable and scalable code.

Second Round in detail:

Requirements I proposed vs. Requirements he wanted:

• Source and destination tracking
• Driver details and reviews
• Vehicle type
• Passenger details and ratings

✔ Location of nearest driver ✔ Notification alerts

Since he had dumbed down the requirements to a level not even applicable for a LeetCode problem, I proposed him a modular design. Unfortunately, he had never worked with Maven or modular code before, and everything went over his head. He kept asking if these were different microservices, even when I said that for the given requirement, microservices are an overkill, but modular code is extensible.

I started with the bird's eye view of the LLD and asked him which module or code he was interested to know more about. Clueless with modern development, he just said, "Go ahead."

Gist of solution I proposed:

1. Decoupled business logic to handle search and allocation of cabs.
2. Decoupled notification system to be fail-safe.
3. Proposed why a message queue is overkill for the problem.
4. IDP or authorization-based login to identify user and driver.
5. Initially, I proposed Redis Cache for storing locations; later, I proposed a dedicated Geolocation DB to allow flexible and fast querying.
6. Separated user management (login, signup, profile) and the actual problem into different concerns.

His follow-up questions:

1. How will I find the nearest driver? By querying the DB. Again, he did not know how Geolocation DBs work, and he was totally confused on how we can query location data.
2. How will I manage notifications? I tried to clarify, but he couldn't clearly communicate what he was expecting.
3. How will the passenger know the driver details? To which I replied that he had rejected this requirement early on, but I still planned the solution. He got offended with the good design there.
4. How will the driver's location get updated? I proposed three solutions, which included user management, real-time tracking, and near real-time tracking. And yet again, he was blank. No acceptance, no denial, but just a total clueless reaction.

In short, he was trying to solve Zepto's 10-minute delivery problem with a solution around a dumbed-down cab service. I am still not sure how both of them related, other than a map and a driver. I hope he knew about the X-Y problem of communicating incorrect details.

Post Interview Discussion:

I have a habit of interviewing the interviewer indirectly so as not to end up with a bad team. And he revealed the whole engineering mess-up in the organization. Probably, he even got offended when I pointed out the lack of minimum basic stuff that are must in an engineering department. And the most shocking part was they don't even have a plan to fix them.

Summary:

Since the engineering team is not too stable, the opportunity for growth for a skilled developer is high, provided they have the patience. But for a fresher, it is a trap, as I did not feel enough learning potential within the team.

Recommendation:

It is better to outsource all interview rounds to third-party interviewers till a good engineering team is established.

1. Array-based medium difficulty LeetCode question.
2. OOPS and Design Basics.
3. Discussion on solving some basic problems in the day-to-day life of startups.

Design an application for cab reservation.