I’d treat this as a reliability incident because a crash can interrupt an active trip and affect a driver’s earnings. I’d investigate the trigger while containing the impact of the recent release.
1. Clarify the product and scope
Ola’s driver app helps drivers accept requests, navigate to pickup and drop-off locations, manage trips, and review earnings.
For this case, I’d focus on the driver app. I’d clarify what drivers mean by “crashing”: does the app close unexpectedly, freeze, restart, or stop loading the map? These symptoms can have different causes.
The case says the issue affects devices across regions, with older Android phones experiencing the greatest impact. I’d keep other devices in scope while prioritising the most affected group.
2. Define the reliability metrics and verify the change
My primary reliability measure would be:
Crash-free session rate = Sessions without a crash ÷ Total sessions × 100
I’d also track the percentage of drivers experiencing at least one crash. A session-level average can hide a group of drivers who repeatedly encounter failures.
Since navigation is a suspected trigger, I’d examine crashes per 100 navigation hours as well. That helps distinguish a worsening experience from more exposure to navigation.
Before diagnosing the cause, I’d check:
Whether crash reporting or session tracking changed.
Whether logs are arriving reliably, including after connectivity returns.
Whether freezes and operating-system process terminations are captured separately.
When the increase began and which app versions are affected.
Whether support complaints match the technical evidence.
The case confirms that reporting is unchanged and crashes began immediately after the latest update. That makes the release the strongest lead, although timing alone does not prove the mechanism.
3. Segment by device capability and operating conditions
I’d break down the issue by app version, Android version, device model, available memory, storage, network conditions, and journey stage.
I’d also compare short sessions with long driving sessions and normal periods with busy periods.
“Older phone” is a useful clue, but it is not a diagnosis. I’d want to know whether the common factor is limited memory, an operating-system compatibility issue, a particular device family, or something else.
The case says navigation usage has increased, particularly during busy periods. I’d check whether that simply exposes drivers to the faulty feature more often or whether longer navigation sessions cause resource usage to accumulate.
4. Locate the failure in the driver journey
I’d map the journey as:
Open and log in → Go online → Accept a ride → Navigate to pickup → Start trip → Navigate to destination → Complete trip
The case provides a clear pattern:
Stage or condition | Evidence from the case | Implication |
|---|---|---|
Opening the app | Works normally | Startup is not the main failure point |
Starting navigation | Crashes become apparent | Navigation deserves priority |
Route recalculation | Crashes occur frequently | Repeated route processing may trigger the issue |
Poor connectivity | Failures become more common | Network handling may contribute |
Recent update | Introduced more real-time navigation features | The new behaviour may exceed available resources or contain a defect |
I’d inspect release changes, feature flags, experiments, map-library updates, and configuration changes associated with navigation. I’d also check whether ride acceptance and navigation overlap in a way that increases load.
5. Test the technical hypotheses
I’d work with engineering to reproduce the failure on representative affected devices, including under weak and changing network conditions.
Hypothesis | Evidence I’d look for |
|---|---|
Excessive memory use or a memory leak | Memory rises during navigation or repeated recalculations; relevant process-exit evidence |
Poor handling of network failures | Crashes follow timeouts, reconnects, or incomplete responses |
Too much concurrent work | Multiple route requests or retries accumulate, especially when connectivity is weak |
A route-recalculation defect | A repeatable failure tied to a particular route update or code path |
Device or OS compatibility issue | Failures cluster around specific versions or models |
I’d compare the new release with the previous stable version under the same conditions.
The interviewer identifies resource pressure and weak-network handling as the leading explanations. I’d retain both as hypotheses until logs and reproduction establish the failure mechanism.
Poor connectivity should be a condition the app handles. The actionable root cause would be how the updated navigation feature responds to it, rather than the existence of weak networks.
6. Understand the driver context without confusing it with the trigger
I’d briefly check shared network outages, operating-system changes, third-party mapping dependencies, and similar incidents at other services. The case gives no evidence of a broad external disruption.
Competitor promotions or negative publicity might change app usage, but they would not directly explain crashes beginning after a release.
The source also raises inflation, fuel costs, vehicle-loan repayments, increased driver supply, and reduced incentives. These could affect drivers’ ability to replace their phones.
I’d validate those economic assumptions through driver research and earnings data. More drivers joining does not automatically mean lower earnings; demand and working hours matter too.
This context explains why supporting lower-capability devices is important. It does not explain why an app that previously worked began crashing after an update. I wouldn’t make buying a new phone the primary solution.
7. Contain the incident and deliver a durable fix
For immediate mitigation, I’d pause the rollout and disable the problematic navigation enhancements where a feature flag allows it. Otherwise, I’d assess a compatible rollback or release a targeted hotfix.
The fix would address the demonstrated failure, such as reducing memory use, cancelling obsolete route requests, limiting retries, or handling network errors correctly.
I’d also verify that a restart restores the driver’s active trip accurately. Losing trip state or showing a completed trip as active would compound the original problem.
Once a fix is verified, I’d give drivers clear update instructions and an honest status message. Updates and troubleshooting should happen while parked, not during a journey.
Cached or offline maps could help where supported, but I’d verify their availability before recommending them. The app should make clear when traffic or route information is no longer current.
Longer term, I’d:
Set performance budgets for supported lower-memory devices.
Test long navigation sessions, repeated rerouting, and network transitions.
Build bounded caching and network-resilient behaviour.
Use staged releases with reliability checks by device group.
Monitor performance continuously and incorporate driver feedback.
The tradeoff is preserving useful navigation while reducing resource demand. A more stable app is not a sufficient fix if it provides unusable routing.
8. Measure recovery across reliability and trip outcomes
My primary measure would remain crash-free sessions, reported separately for affected devices and app versions.
Supporting metrics would include:
Drivers experiencing crashes.
Crashes per navigation hour.
Freezes and unexpected process restarts.
Successful route recalculation and recovery after connectivity loss.
Trip completion and interruption-related cancellations.
Performance complaints and driver satisfaction.
I’d monitor battery consumption, data usage, route quality, and restoration of active trips as guardrails.
Raw crash reports should fall, but I’d normalise them against usage. Fewer reports because drivers stopped using the app would not indicate recovery.
My leading diagnosis is a navigation regression that becomes more severe on resource-constrained devices and unstable networks. I’d contain the release, confirm the precise failure, and restore reliable navigation on the devices drivers already use.