Measure Waymo Merge Politeness KPI | Dataford Interview Questions

Business Context

Waymo operates a fully driverless ride-hailing fleet in Phoenix and San Francisco, completing ~250k rider trips per week and logging billions of autonomous miles across simulation + on-road. The Safety & Trust team has noticed a rise in rider feedback like “the car cut someone off” and “it hesitated too long trying to merge,” especially during highway on-ramps and lane changes near congested interchanges. While collision and disengagement rates remain within targets, Waymo’s Public Policy team is concerned that perceived “rudeness” could trigger regulatory scrutiny and damage brand trust, even if it’s technically safe.

Metric Scenario

A new merging policy shipped two weeks ago to improve throughput (reduce time-to-merge). Since then:

Rider NPS is down 3 points in SF.
“Aggressive driving” support tickets increased 18% week-over-week.
Objective safety metrics (hard braking, near-collision alerts) are flat.

The Head of Product Analytics asks you to create a measurable, auditable metric for “politeness when merging” that can be tracked weekly, compared across software versions, and used as a release gate alongside safety and efficiency metrics.

The challenge: “Politeness” is subjective, but you must translate it into observable signals from telemetry and surrounding-vehicle behavior, while avoiding perverse incentives (e.g., the car becomes overly timid and blocks traffic).

Requirements (what you must produce)

Define “Merge Politeness” precisely for Waymo Driver. Clarify the unit of analysis (merge event), what counts as a merge, and which road types are in-scope (highway, arterial, on-ramp).
Propose a primary KPI (single composite score) and 2–4 supporting sub-metrics that capture distinct aspects (e.g., yielding behavior, gap acceptance, disruption to others).
Provide a calculation approach that can be implemented from logs: thresholds, time windows, normalization, and how you handle missing/uncertain perception.
Decompose the KPI to diagnose the post-launch change: where/when/for whom is politeness worsening?
Recommend actions you’d take if the KPI indicates the car is (a) too aggressive vs (b) too timid, and list guardrails to prevent optimizing politeness at the expense of safety or ETA.

Data Available

Source	Description	Granularity
`autonomy_trajectory_log`	Ego position/velocity/accel/jerk at 10–20Hz; planned trajectory; lane IDs	Time series
`perception_tracks`	Tracked objects (vehicles) with position/velocity, lane association, uncertainty	Time series
`merge_events`	Detected merge attempts with start/end timestamps, from_lane, to_lane, road_type	Event
`planner_decisions`	Yield/merge intent, target gap ID, cost components (comfort, progress, safety)	Decision step
`safety_triggers`	Hard brake, near-collision, time-to-collision alerts	Event
`rider_feedback`	NPS, tags (aggressive, hesitant), free-text, trip_id	Trip
`support_tickets`	Categorized complaints, severity, location	Ticket

Assume you can join on trip_id, timestamp, and map-match to road segments.

Constraints

Must be explainable to regulators and operations teams.
Must be stable across sensor upgrades and perception model versions.
Must be computable daily for dashboards and weekly for release decisions.
Must include explicit handling of confounding: traffic density, road geometry, and local driving norms (SF vs Phoenix).

Problem

Business Context

Metric Scenario

A new merging policy shipped two weeks ago to improve throughput (reduce time-to-merge). Since then:

Rider NPS is down 3 points in SF.
“Aggressive driving” support tickets increased 18% week-over-week.
Objective safety metrics (hard braking, near-collision alerts) are flat.

Requirements (what you must produce)

Define “Merge Politeness” precisely for Waymo Driver. Clarify the unit of analysis (merge event), what counts as a merge, and which road types are in-scope (highway, arterial, on-ramp).
Propose a primary KPI (single composite score) and 2–4 supporting sub-metrics that capture distinct aspects (e.g., yielding behavior, gap acceptance, disruption to others).
Provide a calculation approach that can be implemented from logs: thresholds, time windows, normalization, and how you handle missing/uncertain perception.
Decompose the KPI to diagnose the post-launch change: where/when/for whom is politeness worsening?
Recommend actions you’d take if the KPI indicates the car is (a) too aggressive vs (b) too timid, and list guardrails to prevent optimizing politeness at the expense of safety or ETA.

Data Available

Source	Description	Granularity
`autonomy_trajectory_log`	Ego position/velocity/accel/jerk at 10–20Hz; planned trajectory; lane IDs	Time series
`perception_tracks`	Tracked objects (vehicles) with position/velocity, lane association, uncertainty	Time series
`merge_events`	Detected merge attempts with start/end timestamps, from_lane, to_lane, road_type	Event
`planner_decisions`	Yield/merge intent, target gap ID, cost components (comfort, progress, safety)	Decision step
`safety_triggers`	Hard brake, near-collision, time-to-collision alerts	Event
`rider_feedback`	NPS, tags (aggressive, hesitant), free-text, trip_id	Trip
`support_tickets`	Categorized complaints, severity, location	Ticket

Assume you can join on trip_id, timestamp, and map-match to road segments.

Constraints

Must be explainable to regulators and operations teams.
Must be stable across sensor upgrades and perception model versions.
Must be computable daily for dashboards and weekly for release decisions.
Must include explicit handling of confounding: traffic density, road geometry, and local driving norms (SF vs Phoenix).

Problem

Business Context

Metric Scenario

A new merging policy shipped two weeks ago to improve throughput (reduce time-to-merge). Since then:

Rider NPS is down 3 points in SF.
“Aggressive driving” support tickets increased 18% week-over-week.
Objective safety metrics (hard braking, near-collision alerts) are flat.

Requirements (what you must produce)

Define “Merge Politeness” precisely for Waymo Driver. Clarify the unit of analysis (merge event), what counts as a merge, and which road types are in-scope (highway, arterial, on-ramp).
Propose a primary KPI (single composite score) and 2–4 supporting sub-metrics that capture distinct aspects (e.g., yielding behavior, gap acceptance, disruption to others).
Provide a calculation approach that can be implemented from logs: thresholds, time windows, normalization, and how you handle missing/uncertain perception.
Decompose the KPI to diagnose the post-launch change: where/when/for whom is politeness worsening?
Recommend actions you’d take if the KPI indicates the car is (a) too aggressive vs (b) too timid, and list guardrails to prevent optimizing politeness at the expense of safety or ETA.

Data Available

Source	Description	Granularity
`autonomy_trajectory_log`	Ego position/velocity/accel/jerk at 10–20Hz; planned trajectory; lane IDs	Time series
`perception_tracks`	Tracked objects (vehicles) with position/velocity, lane association, uncertainty	Time series
`merge_events`	Detected merge attempts with start/end timestamps, from_lane, to_lane, road_type	Event
`planner_decisions`	Yield/merge intent, target gap ID, cost components (comfort, progress, safety)	Decision step
`safety_triggers`	Hard brake, near-collision, time-to-collision alerts	Event
`rider_feedback`	NPS, tags (aggressive, hesitant), free-text, trip_id	Trip
`support_tickets`	Categorized complaints, severity, location	Ticket

Assume you can join on trip_id, timestamp, and map-match to road segments.

Constraints

Must be explainable to regulators and operations teams.
Must be stable across sensor upgrades and perception model versions.
Must be computable daily for dashboards and weekly for release decisions.
Must include explicit handling of confounding: traffic density, road geometry, and local driving norms (SF vs Phoenix).

Problem

Business Context

Metric Scenario

A new merging policy shipped two weeks ago to improve throughput (reduce time-to-merge). Since then:

Rider NPS is down 3 points in SF.
“Aggressive driving” support tickets increased 18% week-over-week.
Objective safety metrics (hard braking, near-collision alerts) are flat.

Requirements (what you must produce)

Define “Merge Politeness” precisely for Waymo Driver. Clarify the unit of analysis (merge event), what counts as a merge, and which road types are in-scope (highway, arterial, on-ramp).
Propose a primary KPI (single composite score) and 2–4 supporting sub-metrics that capture distinct aspects (e.g., yielding behavior, gap acceptance, disruption to others).
Provide a calculation approach that can be implemented from logs: thresholds, time windows, normalization, and how you handle missing/uncertain perception.
Decompose the KPI to diagnose the post-launch change: where/when/for whom is politeness worsening?
Recommend actions you’d take if the KPI indicates the car is (a) too aggressive vs (b) too timid, and list guardrails to prevent optimizing politeness at the expense of safety or ETA.

Data Available

Source	Description	Granularity
`autonomy_trajectory_log`	Ego position/velocity/accel/jerk at 10–20Hz; planned trajectory; lane IDs	Time series
`perception_tracks`	Tracked objects (vehicles) with position/velocity, lane association, uncertainty	Time series
`merge_events`	Detected merge attempts with start/end timestamps, from_lane, to_lane, road_type	Event
`planner_decisions`	Yield/merge intent, target gap ID, cost components (comfort, progress, safety)	Decision step
`safety_triggers`	Hard brake, near-collision, time-to-collision alerts	Event
`rider_feedback`	NPS, tags (aggressive, hesitant), free-text, trip_id	Trip
`support_tickets`	Categorized complaints, severity, location	Ticket

Assume you can join on trip_id, timestamp, and map-match to road segments.

Constraints

Must be explainable to regulators and operations teams.
Must be stable across sensor upgrades and perception model versions.
Must be computable daily for dashboards and weekly for release decisions.
Must include explicit handling of confounding: traffic density, road geometry, and local driving norms (SF vs Phoenix).