How to pass the Meesho SDE 2 machine coding round

Landing an SDE-2 role at Meesho means you have to clear one of the most notoriously rigorous machine coding rounds in the Indian tech ecosystem. Algorithmic whiteboard interviews might let you slide by with pseudocode, but not here. The Meesho machine coding round demands a fully executable, object-oriented, and thread-safe solution written entirely from scratch in under two hours. Evaluators aren't just checking if your algorithm spits out the right output. They want to see production-grade code structure, a clean separation of concerns, and rock-solid handling of edge cases like concurrency.

Designing an in-memory car-pooling or ride-matching service is one of the most frequent prompts candidates face. It's a problem that perfectly tests what an SDE-2 should excel at—domain modeling, in-memory data structures, spatial logic, and thread safety. We'll break down exactly how the Meesho hiring process works and map out how to architect a bulletproof solution to this specific machine coding challenge.

The Meesho SDE 2 hiring process

Before we look at the code, let's look at where this round fits into the broader Meesho interview loop. Meesho moves incredibly fast. Their interview process leans heavily on practical engineering skills rather than abstract theoretical knowledge. You'll usually face the machine coding round as your very first technical hurdle. It acts as a strict filter to weed out candidates before moving on to high-level system architecture discussions.

The core problem: In-memory car-pooling service

The problem statement usually sounds something like this: 'Design and implement an in-memory ride-sharing application. Users can register as riders or drivers. Drivers can log in and broadcast their current location on a 2D Cartesian plane (X, Y coordinates). Riders can request a ride from a source coordinate to a destination coordinate. The system must find the nearest available driver within a specific radius, book the ride, and calculate the fare upon completion.' You're completely forbidden from using external databases. Everything has to live in memory. On top of that, your system must handle multiple booking requests simultaneously without accidentally assigning the exact same driver to two different riders.

How do you design the domain models for a car-pooling service?

Your domain model forms the absolute foundation of your solution. Meesho interviewers will heavily scrutinize your entity classes to check if you actually understand SOLID principles—especially the Single Responsibility Principle. A very common mistake here is creating massive 'God classes' that try to handle both data storage and business logic at the same time. You want to avoid that entirely. Instead, stick to anemic domain models that act as pure data containers, and let dedicated service classes manage the actual logic.

• Location: A simple class holding integer or double X and Y coordinates. Make sure it includes a utility method to calculate the Euclidean distance to another Location.
• User: An abstract base class or interface that contains common fields like ID, name, and contact info.
• Rider: This extends User and contains a list of past ride IDs so you can track history.
• Driver / Cab: This can either extend User or act as an entirely separate entity. It needs fields for the cab ID, current Location, availability status (ideally a boolean or Enum), and vehicle details.
• Ride: Your core transactional entity. It should contain the ride ID, rider ID, driver ID, source Location, destination Location, status (like REQUESTED, IN_PROGRESS, COMPLETED), and the final fare.

How do you implement spatial filtering in an in-memory datastore?

The moment a rider requests a cab, your system has to track down the nearest available driver. In a real-world production environment, you'd just lean on a spatial database with PostGIS or a Geohash index. But in this in-memory round, you have to build that filtering mechanism yourself from scratch. The mathematical core of this is the Euclidean distance formula: the square root of ((x2 - x1) squared + (y2 - y1) squared).

If you simply iterate through a List of all drivers to find the closest one, interviewers will see that as a naive O(N) approach—not ideal for an SDE-2. You should absolutely implement this brute-force method first just to get a working solution on the board, but immediately discuss optimizations afterward. A great way to optimize is by implementing a basic 2D Grid or spatial bucketing system. You divide the map into fixed-size grid cells. Whenever a driver updates their location, you place their ID into a Map where the key is the grid cell ID. Then, when a rider requests a cab, you only need to calculate distances for drivers in the rider's current grid cell and the immediately adjacent cells. This drastically reduces your search space.

How do you handle concurrency and prevent double-booking?

Handling concurrency is usually the make-or-break moment for an SDE-2 candidate. The interviewer will almost certainly ask what happens if two riders at the exact same location request a ride at the exact same millisecond. If your spatial filter returns the same nearest driver to both threads, and you simply check 'if (driver.isAvailable())', both threads might read true. They will both assign the driver, update the status to false, and you've just double-booked a cab.

To solve this issue, your in-memory repositories absolutely need to use thread-safe data structures like ConcurrentHashMap. Just remember that a ConcurrentHashMap only ensures thread safety for basic map operations like put and get. It doesn't protect complex check-then-act business logic. For that, you have to implement locking at the entity level.

• Pessimistic Locking: Add a ReentrantLock directly to your Cab entity. When a thread selects a cab, it can call cab.getLock().tryLock().
• Try-Lock Advantage: Relying on tryLock() instead of synchronized() or lock() is a crucial detail. If another thread already holds the lock, tryLock() returns false right away. This allows your thread to gracefully move on to the next nearest cab in the list instead of blocking indefinitely.
• Atomic Updates: If explicit locks aren't your style, you can use an AtomicReference or AtomicBoolean for the cab's availability status. Using compareAndSet(true, false) ensures that only one thread can successfully claim the cab.

How do you structure the executable solution?

Your code has to be highly modular. Never dump all your logic into the main method. A standard Controller-Service-Repository pattern works beautifully here, even when you aren't using a framework like Spring Boot. Structuring it this way proves to the interviewer that your code is actually ready to be integrated into a real web framework.

Start by creating a CabRepository class that wraps your ConcurrentHashMap. This repository should provide methods like 'addCab', 'updateLocation', and 'getAllAvailableCabs'. Then, create a RideService class to handle all the orchestration. It will call the repository to fetch cabs, apply the spatial filtering logic, attempt to acquire a lock on the best cab, create a Ride object, save it to a RideRepository, and finally return the result. Your Main class (or Driver class) should then instantiate these dependencies, wire them together using constructor injection, and run a series of simulated requests to prove everything works.

How do you handle dynamic pricing and routing follow-ups?

Once your core flow works smoothly, expect the interviewer to throw some curveballs. Dynamic pricing is a very common one. They might ask you to implement a base fare, a per-kilometer fare, and surge pricing based on high demand. The Strategy Design Pattern handles this elegantly. You just create a PricingStrategy interface with a 'calculateFare(Ride ride)' method, and then implement different strategies like StandardPricingStrategy and SurgePricingStrategy. Your RideService can accept a PricingStrategy at runtime, which makes your system highly extensible without forcing you to modify the core logic.

Car-pooling, where multiple riders share a single cab, is another frequent follow-up. This requires swapping out your Cab entity's 'isAvailable' boolean for an 'availableSeats' integer. Booking a ride then involves decrementing that integer using a thread-safe operation like AtomicInteger.decrementAndGet. You'll also have to update your spatial logic to make sure the cab's current route doesn't deviate too far to pick up the new rider. You can model this by checking if the new rider's source falls within a bounding box of the cab's current trajectory.

Acing the live review and demo

The last 15 to 20 minutes of the machine coding round are always reserved for a live code review. The interviewer will ask you to run your main method. You absolutely must have pre-written test cases—or at least a robust main method execution block—that demonstrates the happy path, the edge case of no cabs being available, and the concurrent booking scenario. As you explain your code, start right from the entry point and follow the natural data flow. Be sure to explicitly point out exactly where you made engineering trade-offs.

If you ran out of time and couldn't implement a specific feature like the optimized grid spatial filter, own up to it immediately. Just say, 'I implemented an O(N) linear search for cabs to ensure I had a working end-to-end flow within the time limit. If I had more time, I would refactor the CabRepository to use a 2D spatial bucket map to reduce the search time complexity.' Interviewers highly respect candidates who recognize their code's flaws and can clearly articulate the exact path to fixing them.

Final thoughts on the Meesho SDE 2 round

Cracking the Meesho machine coding round ultimately comes down to balancing speed with architectural integrity. You simply don't have the time to build a perfect, enterprise-ready application. But you do have to lay down a foundation that proves you know how to build one. Keep your focus on clean domain models, thread-safe data structures, and a clear separation of concerns. Practice building in-memory systems from scratch with a timer running. Do that, and you'll walk into the interview with the exact confidence you need to succeed.