What to Expect in the Ola System Design Interview

Expect two design rounds at Ola, not one. Experienced candidates report a machine coding round, where you build a working program, and a separate design discussion that one report describes as longer than 90 minutes. Reported design questions include a file uploader service similar to Dropbox, an LRU cache you design and then implement, a redesign of in-app support around search, and a distributed database that runs in either a consistent or an available mode. The machine coding round is the step most candidates from a service based company have never faced, so it is covered first below.

The Machine Coding Round

A machine coding round is a session of roughly one to two hours where you build a small working program from a written requirement, usually a console application. Reports at Ola place it early in the onsite loop. The result is graded on three things: whether the program runs against test input, how the classes are organized, and whether a new requirement can be added without rewriting.

Reported problems at Ola include the following.

• A publish and subscribe system. Multiple senders and multiple receivers subscribe to topics, and every event reaches all subscribers of its topic. A bonus requirement adds subscriber groups, where one member of a group receives each event.
• A bowling game. Score a full game with proper object oriented design, in about one hour.
• Cache implementations. Candidates report writing an LRU cache and an LFU cache with the required time costs.
• A graph problem with a class structure. One report describes a routing style problem solved with a hash map and a set, written as working code rather than pseudocode.

This round tests low level design rather than architecture, and the difference between the two is explained in system design versus low level design, while the general format is described in what a machine coding round is.

The System Design Round

This round is a discussion rather than an implementation, and the reported questions fall into three groups. Product designs, such as a file uploader similar to Dropbox, test storage choices, indexing and read heavy traffic. Infrastructure designs, such as a distributed database with a selectable consistency mode, test replication, sharding and failure handling. Data structure designs, such as an LRU cache, ask you to design the structure and then write it. One report describes a detailed resume discussion inside the first part of the same round.

A Walkthrough: Show Available Cabs Near a Rider

Reports do not name one location question that repeats at Ola, although this one is worth rehearsing because it is the question type closest to the company's own product. Here is one workable plan.

1. Requirements (5 minutes). A city is covered by service areas, each drawn as a polygon, and a user opening the app must see nearby available cabs within about one second. Drivers send location updates every few seconds.

2. Find the service area. Decide which polygon contains the user's point, since a test against every polygon in the city is too slow at scale. Precompute the polygon for each grid cell instead, using geohash cells or a similar grid, where a geohash is a short string that names a square on the map.

3. Store driver locations. Keep the current location of each available driver in an in memory store, keyed by grid cell, and write every update there while never reading from durable storage in the request path.

4. Answer the query. Convert the user's point to a cell, collect drivers in that cell and its neighbors, then filter by service area and by road distance.

5. Handle failure. Drivers lose network in tunnels and basements, so expire a location after a short timeout and never show a stale cab, because an empty result returned honestly is better than a wrong one.

6. Scale. Shard by city, cache polygon lookups, and keep the write path separate from the read path so a burst of updates cannot slow queries.

What the Interviewer Grades

State the requirements and the scale before drawing anything, and name each trade-off out loud, because silent choices earn no credit. Tie decisions to the business: a cab shown outside its service area produces a canceled ride. Hiring managers also probe operational topics, and reports name circuit breakers, schedulers, load balancing, and scaling a database and a cache, so be ready to defend each choice with a reason rather than a preference.

Common Mistakes in This Round

• Treating machine coding as competitive programming. A clever algorithm inside one large function fails this round, because separate classes and clear interfaces are what is graded.
• Not finishing a running program. A partial design that compiles and runs scores better than a complete design that does not.
• Skipping requirements in the design round. Candidates who draw boxes first usually solve the wrong problem.
• Ignoring stale data. Location systems fail on old updates more often than on load, so say how you expire them.
• No capacity estimate. Give rough numbers for updates per second and storage, even approximate ones.

How to Prepare

• Practice object oriented design under a timer. Grokking the Object Oriented Design Interview covers the class structures the machine coding round rewards.
• Learn the architecture building blocks. Grokking the System Design Interview covers the caches, queues and indexes these questions use.
• Rehearse the location walkthrough. Practice the six steps above out loud in under 40 minutes.
• See where the round sits. The design rounds are part of the Ola interview process, alongside the motivation question and the reported waits between rounds.