How to pass Ola's SDE-2 machine coding interview

Ola's SDE-2 machine coding round is infamous for pushing candidates to their absolute limits. They don't want a basic CRUD application. Instead, they expect you to build a highly concurrent, thread-safe, and spatially aware matching engine in a tight two to three hours. Working code isn't enough to secure an offer. You need production-grade, extensible low-level design (LLD) that handles race conditions gracefully. To pass this round, you have to move past simple object-oriented principles. You'll need to demonstrate a rock-solid grasp of concurrency controls, in-memory data structures, and practical design patterns. Let's break down exactly how you can architect and communicate a winning solution.

The Mechanics of Ola's SDE-2 Hiring Process

Before we get into the technical weeds of the driver matching engine, you need to know where this fits into the broader Ola SDE-2 interview loop. Ola generally runs a rigorous four-to-five round process. They focus heavily on pure problem-solving, low-level design, and scalable architecture. Understanding exactly what each round tests will help you pace your preparation effectively.

Core Requirements: Functional Bounds and Concurrency Constraints

In the machine coding round, interviewers typically hand you a broad problem statement like 'Design a cab booking system.' To succeed, you have to immediately clarify the scope. A real-world, production-grade cab booking engine has hundreds of features. Since you only have a two-hour interview window, you need to nail down specific functional and non-functional bounds. Doing this ensures you can actually finish writing the code.

• A rider can request a ride by providing their current location as x and y coordinates.
• The system must find the nearest available drivers within a specific radius.
• Drivers can accept or reject rides, and their availability status must update concurrently.
• Multiple riders might request the same driver simultaneously, so the system must prevent double-booking.
• The entire solution must run in-memory without external databases or caches like Redis.

Domain Modeling: Designing Clean Entities and State Machines

Candidates frequently make the mistake of tightly coupling their core entities. In a cab booking system, your primary entities are Rider, Driver, Ride, and Location. The state of a Driver and a Ride changes constantly. Because of this, modeling those state transitions cleanly becomes absolutely critical for an SDE-2 level evaluation.

How do I model the state transitions for drivers and rides?

You should define strict enums for statuses. A Driver can be AVAILABLE, ON_TRIP, or OFFLINE. A Ride can be REQUESTED, ACCEPTED, IN_PROGRESS, COMPLETED, or CANCELLED. Instead of scattering messy if-else checks throughout your service layer to validate these changes, encapsulate the state transition logic right inside the entity itself. Alternatively, use a State design pattern. For example, a ride can only transition to IN_PROGRESS if its current state is ACCEPTED. Throw custom exceptions like 'InvalidRideStateException' if an illegal transition is attempted. Doing this proves to the interviewer that you actively think about data integrity and robust domain modeling.

In-Memory Spatial Indexing: Fast Driver Discovery Without Databases

Efficiently finding nearby drivers is often the most technically challenging part of the Ola LLD round. In a high-level system design interview, you'd probably just say 'I will use Redis Geospatial or PostGIS.' In machine coding, however, you have to build the underlying logic in-memory. Iterating through all drivers in a list to calculate the Euclidean distance is an O(N) operation. That approach will quickly fail the performance expectations of an SDE-2 round.

How do I implement an in-memory spatial index for driver matching?

You'll need to implement a spatial partitioning strategy. A simplified Quadtree or a Grid-based spatial index works perfectly for this task. In a Grid-based approach, you divide the city into a grid of fixed-size cells. This technique drastically reduces your overall search space.

• Map the (x, y) coordinates to a specific Grid ID using a mathematical hash function (e.g., x/10 + y/10).
• Maintain a ConcurrentHashMap where the key is the Grid ID and the value is a thread-safe Set of available Driver IDs.
• When a rider requests a cab at (x, y), calculate their Grid ID.
• Fetch drivers from the rider's specific grid cell. If you don't find enough drivers, expand the search to the immediately adjacent 8 cells.
• Calculate the exact Euclidean distance only for this small subset of drivers. This reduces the time complexity from O(N) to O(K), where K is the number of drivers in local cells.

Concurrency Controls: Preventing Double-Booking with Thread-Safe Locks

Ola's interviewers heavily scrutinize your concurrency handling. Imagine Rider A and Rider B both request a ride in the same grid at the exact same millisecond. The spatial index might return Driver 1 as the nearest option for both users. If you aren't careful with your locks, both rides might get assigned to Driver 1. That results in a disastrous double-booking scenario.

What is the best way to handle concurrent ride requests and prevent race conditions?

You absolutely must implement fine-grained locking. Using a global lock (like synchronizing the entire matching method) destroys system throughput and guarantees a rejection. Instead, rely on Optimistic Locking or ReentrantLocks at the individual driver level.

• Assign a ReentrantLock to each Driver object in your application.
• When attempting to book a driver, use the tryLock() method with a short timeout instead of a blocking lock().
• If you acquire the lock, double-check the driver's status. If they are still AVAILABLE, change their status to ON_TRIP and instantiate the Ride object.
• If tryLock() fails or the driver is no longer AVAILABLE, immediately release the lock and attempt to book the next nearest driver from your spatial index.
• Use ConcurrentHashMap for all in-memory repositories. This ensures thread-safe reads and writes across the application without relying on explicit synchronization blocks.

Applying Design Patterns: Strategy and State Patterns for Extensibility

Extensibility serves as a major grading rubric in SDE-2 interviews. The interviewer will likely throw a curveball halfway through the round. They might say, 'Now, add a feature where VIP riders get matched with top-rated drivers first, regardless of distance.' If your matching logic sits hardcoded inside a single massive service class, you're in trouble. You'll have to rewrite major chunks of your application while the clock aggressively ticks down.

Which design patterns should I use to make the matching engine extensible?

The Strategy Pattern is your absolute best friend here. You should isolate the algorithm that determines which driver gets selected so it can be swapped dynamically at runtime.

• Define an interface called 'DriverMatchingStrategy' with a single method: findDrivers(Rider, List<Driver>).
• Implement a 'NearestDriverStrategy' that sorts the filtered drivers primarily by Euclidean distance.
• Implement a 'HighestRatedDriverStrategy' that sorts them primarily by driver rating.
• Inject the appropriate strategy into your RideService at runtime using a Factory Pattern based on the rider's profile (e.g., standard vs. VIP).
• This approach adheres strictly to the Open/Closed Principle (OCP) of SOLID design. You can freely add new matching algorithms without ever modifying the core booking service.

Acing the Live Interview Under Pressure

Knowing the architecture is only half the battle. Executing it in a live, high-pressure environment is where most candidates stumble. You need to write clean, modular code, build unit tests for the core logic, and explain your trade-offs clearly. Never code in silence. Treat the interviewer as a collaborator. Explain why you chose a Grid over a Quadtree. For instance, a Grid is faster to implement in two hours and handles uniform density well. A Quadtree handles sparse density better, but it's notoriously complex to code bug-free under a strict time limit.

How AcePrompt Helps You Code Live LLD Solutions

Managing time, recalling exact syntax for concurrency controls, and structuring your patterns while being watched is incredibly stressful. That's where modern interview preparation and real-time assistance make a massive difference. AcePrompt acts as your real-time AI interview copilot. It listens to the conversation and provides structured, personalized guidance right on your screen. When the interviewer asks you to implement a thread-safe matching engine, AcePrompt instantly suggests the optimal locking strategy. It can even remind you to apply the Strategy pattern for driver matching. It takes the cognitive overload out of the equation, allowing you to focus completely on communication, logical flow, and flawless execution.