Product design question

Design Dynamic Pricing for Lyft.

Practice this question out loud. An AI interviewer asks it, follows up like a real interviewer would, and scores your answer. Type or speak.

What this question tests

Tests designing an algorithmic pricing system, balancing marketplace liquidity against rider fairness and trust perception.

State the goal: use price to balance real-time supply and demand, pulling more drivers online when requests spike and smoothing demand when supply is thin.
Define inputs: real-time ride requests versus available drivers in a geofenced area, plus time-of-day and event-based demand signals.
Design the mechanism: a multiplier applied to base fare that increases as the request-to-driver ratio rises, capped to avoid extreme price shocks.
Address the fairness/trust problem: show riders the multiplier and reason before they confirm, and cap surge during emergencies or high-necessity trips.
Define success: reduced rider wait time and increased driver online-time during high-demand windows, measured against complaint and cancellation rate as guardrails.

Frames dynamic pricing as a liquidity tool (matching supply and demand in real time), not just a revenue lever, which is the core insight.
Proposes a cap and transparent surge display specifically to manage the well-known trust backlash dynamic pricing generates.
Uses an illustrative number, e.g. assume a 2x cap reduces extreme-surge complaints by half while still pulling in 80% of the supply response.
Balances rider-side (wait time, cost fairness) and driver-side (incentive to come online) success metrics, not just one side.

Designing a pricing algorithm without addressing the well-documented trust and PR risk of surge pricing.
Optimizing purely for revenue instead of the real goal, balancing marketplace supply and demand.

How would you handle surge pricing during an emergency, like a natural disaster?
How would you test a new pricing algorithm without disrupting live marketplace liquidity?