Interview experience
Ola Interview Questions and Answers (2026)
Overview
Section titled “Overview”Ola’s fresher SDE loop is a 4-5 stage process where system-design questions are consistently mapped onto its actual mobility-platform product - ride matching, real-time location tracking, surge pricing, payments.
Ola interview process at a glance
Section titled “Ola interview process at a glance”| Round | Duration | What they test |
|---|---|---|
| Online Assessment | 90-120 min | 2-3 coding problems (DSA) |
| Technical Round 1 | 45-60 min | DSA + detailed project discussion |
| Technical Round 2 | 45-60 min | DSA / system design basics |
| Hiring Manager / HR | 30-45 min | Behavioural + team fit |
Online Assessment
Section titled “Online Assessment”A 90-120 minute HackerRank test with 2-3 DSA problems plus a debugging section where you identify and fix bugs in provided code.
Common questions
- Maximum-sum subarray (Kadane’s algorithm variant)
- Lowest common ancestor in a binary tree
- Shortest path in a weighted graph (Dijkstra’s algorithm)
- Debugging exercises on provided code snippets
Technical Round 1
Section titled “Technical Round 1”Opens with project discussion, then a coding problem - often with a follow-up asking you to optimize for a different constraint (e.g. space instead of time).
Common questions
- Design a data structure supporting insert, delete, and getRandom in O(1)
- Optimize your solution’s space complexity, and justify the trade-off
- Design a ride-matching system for Ola (scalability, load balancing, real-time matching)
- Detailed walkthrough of your resume project
Technical Round 2
Section titled “Technical Round 2”Pairs more DSA with system-design questions scoped directly to Ola’s mobility-platform domain.
Common questions
- Implement an LRU cache (HashMap + doubly linked list) or a rate limiter
- Design Ola’s real-time location-tracking system (WebSockets, Redis caching, Kafka events)
- Design a surge-pricing system - real-time demand calculation, pricing algorithm
- Design a payment gateway with transaction safety (ACID properties, idempotency, retries)
Round-by-round narratives are on the Ola interview experience page.
Managerial / Team Fit Interview
Section titled “Managerial / Team Fit Interview”Checks alignment with Ola’s values - ownership, customer focus - often through a specific incident-response scenario rather than abstract questions.
Common questions
- Describe a time you demonstrated ownership
- How would you handle a production issue at 2 AM?
- Describe a conflict you resolved in a team
- Architecture decisions and trade-offs from your technical rounds, revisited
HR / Offer Discussion
Section titled “HR / Offer Discussion”A closing conversation on background, motivation, and logistics.
Common questions
- Why Ola, and what do you know about its business?
- Are you willing to relocate to Bengaluru?
- What are your salary expectations?
- Joining timeline
Sample answer frameworks for each of these are on the Ola HR interview questions page.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: Explain Kadane’s algorithm for maximum-sum subarray and its complexity.
Kadane’s algorithm makes a single pass, maintaining current_sum = max(num, current_sum + num) at each index and best = max(best, current_sum). The insight is that a prefix with a negative running sum can never help a later subarray, so you discard it and restart at the current element. Time is O(n) and space is O(1). If all elements are negative, initialise best to the first element rather than 0, otherwise you incorrectly return 0 for a non-empty array.
Q: How do you find the lowest common ancestor of two nodes in a binary tree?
For a general binary tree, recurse from the root: if the current node is null or equals either target, return it. Recurse left and right; if both sides return non-null, the current node is the LCA, otherwise return whichever side is non-null. This is O(n) time and O(h) space for the recursion stack, where h is the tree height. In a binary search tree you can do better - walk down from the root and the first node whose value lies between the two targets is the LCA, which is O(h) time and O(1) space iteratively.
Q: How does Dijkstra’s algorithm work, and when does it fail?
Dijkstra maintains a distance array initialised to infinity except the source at 0, and repeatedly extracts the unvisited node with the smallest known distance from a min-heap, relaxing each outgoing edge by checking whether dist[u] + weight(u,v) improves dist[v]. With a binary heap it runs in O((V + E) log V). It fails on graphs with negative edge weights, because once a node is finalised it is never revisited - use Bellman-Ford (O(VE)) there instead. For road-network routing like Ola’s ETA problem, A with a geographic heuristic is the practical refinement.
Q: Design a data structure supporting insert, delete, and getRandom in O(1).
Combine a dynamic array (list) with a hash map from value to that value’s index in the array. Insert appends to the array and records the index in the map. Delete looks up the index, swaps that element with the last element of the array, updates the swapped element’s index in the map, pops the array tail, and erases the key. getRandom picks a uniform random index into the array. Every operation is O(1) average, and the swap-with-last trick is what avoids the O(n) shift a naive array removal would cost.
Q: How do you implement an LRU cache, and why those specific data structures?
Use a hash map from key to node plus a doubly linked list ordered most-recently-used at the head and least-recently-used at the tail. On get, look up the node in O(1) and move it to the head. On put, insert at the head, and if size exceeds capacity, remove the tail node and delete its key from the map. The doubly linked list is required because removing an arbitrary node in O(1) needs both prev and next pointers; a singly linked list would force an O(n) scan to find the predecessor. Both operations are O(1) with O(capacity) space.
Q: How would you design a real-time driver-location tracking system?
Drivers push a location ping every few seconds over a persistent WebSocket (or MQTT) connection to a gateway layer, which publishes each ping to a Kafka topic partitioned by driver_id so ordering per driver is preserved. A consumer writes the latest position into Redis using a geospatial index (GEOADD/GEORADIUS) keyed by city or geohash cell, so a nearby-driver query is a sublinear radius lookup rather than a full table scan. Raw pings stream to cold storage such as S3 for analytics and trip replay rather than sitting in the hot path. The core trade-offs are ping frequency versus battery and bandwidth, and accepting eventual consistency on location because a driver position a second out of date is acceptable.
Q: How would you design a surge-pricing engine?
Divide the city into geohash or S2 cells and, per cell, compute a rolling window of open ride requests versus available drivers - typically over a 2-5 minute tumbling window from the same event stream that feeds dispatch. The surge multiplier is a function of that demand-supply ratio, clamped to a floor of 1.0x and a regulatory ceiling, and smoothed so it does not oscillate between consecutive windows. Cache the multiplier per cell in Redis with a short TTL so fare quotes read it in single-digit milliseconds, and lock the quoted multiplier to the booking for a fixed validity period so the rider is not charged a different price than they were shown. Log every multiplier decision for audit, since pricing is regulated.
Q: What does idempotency mean for a payment API, and how do you implement it?
An idempotent API returns the same result and causes the same single side effect no matter how many times the client retries the same request - essential because a network timeout leaves the client unsure whether the charge went through. Implement it by having the client send an Idempotency-Key header (a UUID) with the request; the server does an atomic insert of that key into a unique-indexed table inside the same database transaction as the charge. If the insert succeeds, process the payment and store the response against the key; if it violates the unique constraint, return the stored response instead of charging again. This relies on the ACID guarantees of the transaction - doing the check and the charge in two separate steps reintroduces the race.
Frequently asked questions about Ola interviews
Section titled “Frequently asked questions about Ola interviews”What is the Ola interview process for freshers?
Ola’s SDE process (from student reports) typically runs 4-5 stages: 1. Online Coding Assessment (90-120 min) - 2-3 DSA problems plus debugging questions on HackerRank. 2. Technical Interview 1 (45-60 min) - a coding problem plus detailed project discussion. 3. Technical Interview 2 (45-60 min) - more DSA plus system-design questions scoped to Ola’s domain (ride matching, real-time location, surge pricing, payments). 4. Managerial/Team Fit Interview (45 min) on Ola’s values (customer focus, ownership). 5. HR/Offer Discussion (20-30 min). Total timeline is roughly 2-4 weeks from application to offer.
What questions are asked in Ola interviews?
DSA problems reported include maximum-sum subarray, lowest common ancestor in a binary tree, Dijkstra’s shortest path, an O(1) insert/delete/getRandom data structure, and LRU cache implementation. System-design prompts are consistently scoped to Ola’s actual product - design a ride-matching system, a real-time location-tracking system (WebSockets, Redis, Kafka), a surge-pricing engine, or a payment gateway with transaction safety (ACID, idempotency, retries).
How many rounds are there in the Ola interview?
Most fresher SDE drives run 4-5 stages: an online assessment, two technical interviews (DSA/project, then DSA/system-design), a managerial/team-fit round, and a closing HR round. Some drives compress the managerial round into the final technical interview - confirm the exact structure from your placement cell.
What system-design questions does Ola ask?
Ola’s system-design prompts map directly onto its mobility-platform product: ride-matching algorithms, real-time driver-location tracking (candidates report using WebSockets/Redis/Kafka in their answers), surge-pricing calculation, and payment-gateway transaction safety. Expect to discuss scalability, fault tolerance, and consistency trade-offs (CAP theorem, database sharding) even at a fresher-appropriate depth.
How should I prepare for Ola interviews?
Practice medium-to-hard DSA (arrays, trees, graphs, LRU-cache-style problems) since both technical rounds lean on live coding. For system design, practice mapping generic patterns (rate limiters, distributed caches, real-time tracking) onto ride-hailing-shaped problems specifically - ride matching, surge pricing, location tracking. Prepare STAR-format stories for ownership, handling ambiguity, and a production-issue scenario, since Ola’s managerial round asks for these directly.
Is this page about ride-hailing Ola or Ola Electric?
This page covers ride-hailing/mobility-platform Ola (ANI Technologies), not Ola Electric, which is a separate, now-publicly-listed company focused on electric vehicles. The interview content here - ride matching, surge pricing, location tracking, Bengaluru-based roles - reflects the mobility-tech business.