Lyft Data Analyst Interview Guide

Lyft's data analyst role sits inside a marketplace that just posted record Q4 2025 gross bookings, up 17% year-over-year. That growth means you're not maintaining dashboards for a steady-state business. You're analyzing a system that's actively scaling, where the questions change quarter to quarter and the stakes of getting a metric wrong compound fast.

Lyft Data Analyst Role

Your job is to own metrics for a product surface (rider growth, driver supply, or micromobility) and turn those metrics into decisions. After year one, success looks like stakeholders pulling you into roadmap conversations because your analysis shifted a priority, plus at least one self-serve Looker explore you built that eliminated a recurring ad-hoc request.

A Typical Week

What stands out isn't the SQL time. It's that writing and communication eat 15% of the week, nearly as much as coding. You'll draft findings docs aimed at senior leadership, annotate presentation decks, and fix broken Airflow DAGs in the same afternoon. The role rewards people who context-switch between analytical depth and stakeholder clarity without treating either as beneath them.

Projects & Impact Areas

Supply-demand dynamics across Lyft's North American markets drive the highest-impact work, because a driver incentive tweak in one city can ripple into ride completion rates elsewhere. That analysis feeds directly into experimentation, where you might own the readout on a feature like the PIN verification rollout and present early results at the bi-weekly cross-functional sync with product and engineering. The quieter win is building reporting layers (Looker explores, clean metric definitions) that let PMs self-serve, which compounds your influence by freeing you for deeper analysis.

Skills & What's Expected

Business acumen is the skill that separates candidates who get offers from those who don't. Interviewers expect you to reason about two-sided marketplace tradeoffs (driver incentives vs. rider pricing) without prompting. SQL and data architecture proficiency are table stakes, while ML knowledge isn't part of the role. Visualization matters here not as chart aesthetics, but as whether an ops lead actually opens your Tableau dashboard every Monday.

Levels & Career Growth

The jump that stalls most analysts is the move from owning a single feature's metrics to owning how an entire product area's metrics are defined. Lyft's leaner post-restructuring headcount means individual analysts cover broad surface areas, which accelerates growth but comes with less mentorship scaffolding than you'd find at a larger analytics org.

Work Culture

From what candidates and current employees report, Lyft's San Francisco office follows a hybrid cadence with some in-office days expected midweek and flexibility on other days. Analysts tend to work roughly 9:30 to 6, with spikes around quarterly business reviews or major experiment readouts. The embedded team model gives you real influence on product decisions, but it also means you'll need to self-direct your technical development and actively seek out peer learning opportunities like the Friday knowledge-share sessions.

Lyft Data Analyst Compensation

Lyft's packages include base salary, annual bonus, and RSUs that vest over four years, often with a one-year cliff. Because RSUs make up a meaningful share of total comp, stock price swings between your grant date and each vest date can materially change what you actually take home. That's worth factoring into how you weigh the offer, and it's a reason to negotiate base salary aggressively as a more predictable component.

The source data confirms that both base salary and RSU grants are negotiable, with RSUs tending to offer the most flexibility. Your strongest card is a competing offer: from what candidates report, a written counter creates real room for recruiters to move on the equity number.

Lyft Data Analyst Interview Process

The take-home assignment is the scheduling bottleneck most candidates underestimate. It sits at round four, which means you've already invested in a recruiter call, a hiring manager screen, and a live SQL session before you even receive it. If your timeline slips here, the remaining onsite rounds can drift, so block time proactively.

Weak business reasoning is the most common rejection pattern, from what candidates report, even when SQL performance is strong. Lyft's embedded analyst model means interviewers are screening for people who can connect queries to marketplace dynamics (driver incentives, fulfillment rates, supply-demand imbalances) rather than just produce correct output. A technically clean take-home with sloppy visuals and no executive summary will hurt you, because communication quality is weighted alongside analytical correctness across the loop.

Lyft Data Analyst Interview Questions

WITH recent_rides AS (
  SELECT
    r.ride_id,
    r.city_id,
    r.requested_at_utc
  FROM rides r
  WHERE r.requested_at_utc >= date_add('day', -14, date_trunc('day', current_timestamp))
),
-- Deduplicate events: keep the first occurrence of each event_type per ride_id.
ranked_events AS (
  SELECT
    e.ride_id,
    e.event_type,
    e.event_ts_utc,
    row_number() OVER (
      PARTITION BY e.ride_id, e.event_type
      ORDER BY e.event_ts_utc ASC, e.event_id ASC
    ) AS rn
  FROM ride_events e
  JOIN recent_rides rr
    ON rr.ride_id = e.ride_id
  WHERE e.event_type IN ('canceled', 'completed')
),
canonical_events AS (
  SELECT
    ride_id,
    max(CASE WHEN event_type = 'completed' AND rn = 1 THEN 1 ELSE 0 END) AS is_completed,
    max(CASE WHEN event_type = 'canceled' AND rn = 1 THEN 1 ELSE 0 END) AS is_canceled
  FROM ranked_events
  WHERE rn = 1
  GROUP BY 1
),
ride_outcomes AS (
  SELECT
    rr.ride_id,
    rr.city_id,
    date_trunc('day', rr.requested_at_utc) AS requested_day_utc,
    coalesce(ce.is_completed, 0) AS is_completed,
    coalesce(ce.is_canceled, 0) AS is_canceled
  FROM recent_rides rr
  LEFT JOIN canonical_events ce
    ON ce.ride_id = rr.ride_id
)
SELECT
  requested_day_utc,
  city_id,
  sum(is_completed) AS completed_rides,
  sum(is_canceled) AS canceled_rides,
  CASE
    WHEN (sum(is_completed) + sum(is_canceled)) = 0 THEN 0
    ELSE cast(sum(is_canceled) AS double) / (sum(is_completed) + sum(is_canceled))
  END AS cancellation_rate
FROM ride_outcomes
GROUP BY 1, 2
ORDER BY 1 DESC, 2;

WITH base AS (
  SELECT
    date_trunc('week', accepted_at_utc) AS week_start_utc,
    city_id,
    driver_id,
    ride_id,
    accepted_at_utc,
    completed_at_utc,
    CASE WHEN accepted_at_utc IS NOT NULL THEN 1 ELSE 0 END AS is_accepted,
    CASE WHEN completed_at_utc IS NOT NULL THEN 1 ELSE 0 END AS is_completed,
    CASE
      WHEN accepted_at_utc IS NOT NULL AND completed_at_utc IS NOT NULL
        THEN date_diff('second', accepted_at_utc, completed_at_utc) / 3600.0
      ELSE NULL
    END AS hours_accept_to_complete
  FROM rides
  WHERE accepted_at_utc IS NOT NULL
    AND accepted_at_utc >= date_add('week', -12, date_trunc('week', current_timestamp))
),
-- Driver-week funnel flags.
driver_week AS (
  SELECT
    week_start_utc,
    city_id,
    driver_id,
    max(is_accepted) AS active_driver_flag,
    max(is_completed) AS completing_driver_flag
  FROM base
  GROUP BY 1, 2, 3
)
SELECT
  dw.week_start_utc,
  dw.city_id,
  count_if(dw.active_driver_flag = 1) AS active_drivers,
  count_if(dw.completing_driver_flag = 1) AS completing_drivers,
  approx_percentile(b.hours_accept_to_complete, 0.5) AS median_hours_accept_to_complete
FROM driver_week dw
LEFT JOIN base b
  ON b.week_start_utc = dw.week_start_utc
 AND b.city_id = dw.city_id
 AND b.driver_id = dw.driver_id
 AND b.hours_accept_to_complete IS NOT NULL
GROUP BY 1, 2
ORDER BY 1 DESC, 2;

Experimentation and causal inference questions compound at Lyft because the same driver-side spillover that breaks a naive A/B test on rider coupons is also the identification problem you'd need to solve in a diagnostic question about airport cancellation spikes. The biggest prep mistake is treating these as separate study tracks when Lyft's two-sided marketplace makes them functionally the same skill. Product sense sits at the top of the distribution, but it's the questions that blend metric definition with causal reasoning (did the new upfront pricing experiment actually cause the completion rate drop, or did driver supply shift independently?) that eliminate the most candidates.

Sharpen that overlap by working through marketplace-grounded problems at datainterview.com/questions.

How to Prepare for Lyft Data Analyst Interviews

Lyft's stated priorities right now are improving profitability, expanding margins, and building what they call a "hybrid rideshare network" that blends human drivers with autonomous vehicles. The company reported record Q4 and full-year 2025 results on $6.3 billion in revenue, while simultaneously launching teen accounts and signing an autonomous shuttle deal with Benteler. For a data analyst, that means the measurement surface is expanding fast: you could be building a safety monitoring framework for teen rides one sprint, then designing metrics for AV shuttle fulfillment the next.

The biggest mistake candidates make in their "why Lyft" answer is treating it as a smaller Uber. Lyft's Q4 2025 prepared remarks emphasize margin expansion and AV acceleration as top goals, not just ride volume. Instead of saying "I'm excited about rideshare," talk about the analytical tension between driver incentive spend and profitability targets, or how you'd approach measurement for AV shuttle routes where there's no driver to incentivize at all.

Try a Real Interview Question

| driver_online_sessions |
|------------------------|
| session_id | driver_id | city_id | start_ts           | end_ts             |
|-----------|-----------|---------|--------------------|--------------------|
| 1         | 101       | 1       | 2024-01-01 08:00:00| 2024-01-01 10:00:00|
| 2         | 102       | 1       | 2024-01-01 09:30:00| 2024-01-01 11:00:00|
| 3         | 101       | 1       | 2024-01-02 08:00:00| 2024-01-02 09:00:00|
| 4         | 201       | 2       | 2024-01-01 08:00:00| 2024-01-01 09:00:00|

| rides |
|-------|
| ride_id | driver_id | city_id | requested_ts       | pickup_ts          | dropoff_ts         | status    |
|---------|-----------|---------|--------------------|--------------------|--------------------|-----------|
| r1      | 101       | 1       | 2024-01-01 08:10:00| 2024-01-01 08:15:00| 2024-01-01 08:35:00| completed |
| r2      | 101       | 1       | 2024-01-01 09:50:00| 2024-01-01 09:55:00| 2024-01-01 10:20:00| completed |
| r3      | 102       | 1       | 2024-01-01 10:40:00| 2024-01-01 10:45:00| 2024-01-01 11:10:00| completed |
| r4      | 201       | 2       | 2024-01-01 08:20:00| 2024-01-01 08:25:00| 2024-01-01 08:55:00| completed |

-- Write a query that outputs:
-- week_start (Monday), city_id, active_drivers, total_online_minutes, utilization
-- Assume timestamps are in the same timezone and dropoff_ts > pickup_ts.
-- Hint: you need to attribute each ride to online time using interval overlap logic.

WITH sessions AS (
  SELECT
    session_id,
    driver_id,
    city_id,
    CAST(start_ts AS timestamp) AS start_ts,
    CAST(end_ts AS timestamp) AS end_ts,
    date_trunc('week', CAST(start_ts AS timestamp)) AS week_start
  FROM driver_online_sessions
  WHERE CAST(start_ts AS date) >= DATE '2024-01-01'
    AND CAST(start_ts AS date) < DATE '2025-01-01'
),
ride_events AS (
  SELECT
    ride_id,
    driver_id,
    city_id,
    CAST(pickup_ts AS timestamp) AS pickup_ts,
    CAST(dropoff_ts AS timestamp) AS dropoff_ts
  FROM rides
  WHERE status = 'completed'
    AND CAST(pickup_ts AS date) >= DATE '2024-01-01'
    AND CAST(pickup_ts AS date) < DATE '2025-01-01'
),
online_by_week_city AS (
  SELECT
    week_start,
    city_id,
    SUM(date_diff('minute', start_ts, end_ts)) AS total_online_minutes
  FROM sessions
  GROUP BY 1, 2
),
ride_minutes_by_week_city AS (
  SELECT
    s.week_start,
    s.city_id,
    SUM(
      date_diff(
        'minute',
        GREATEST(s.start_ts, r.pickup_ts),
        LEAST(s.end_ts, r.dropoff_ts)
      )
    ) AS total_ride_minutes,
    COUNT(DISTINCT r.driver_id) AS active_drivers
  FROM sessions s
  JOIN ride_events r
    ON r.driver_id = s.driver_id
   AND r.city_id = s.city_id
   AND r.pickup_ts < s.end_ts
   AND r.dropoff_ts > s.start_ts
  GROUP BY 1, 2
)
SELECT
  o.week_start,
  o.city_id,
  COALESCE(r.active_drivers, 0) AS active_drivers,
  o.total_online_minutes,
  CAST(COALESCE(r.total_ride_minutes, 0) AS double) / o.total_online_minutes AS utilization
FROM online_by_week_city o
LEFT JOIN ride_minutes_by_week_city r
  ON r.week_start = o.week_start
 AND r.city_id = o.city_id
WHERE o.total_online_minutes > 0
ORDER BY 1, 2;

Lyft's SQL rounds lean on marketplace-specific modeling decisions, not syntax tricks. You'll need to think carefully about grain (ride-level vs. session-level vs. driver-shift-level) because picking the wrong unit of analysis for a fulfillment or pricing question will silently produce wrong numbers. Build that muscle at datainterview.com/coding, focusing on problems where the schema design choice matters as much as the query itself.

Test Your Readiness

Lyft's product sense round will ask you to reason about supply-demand dynamics and metric cascades specific to their marketplace. Sharpen those skills at datainterview.com/questions.