Uber Senior SDE VO 面试复盘｜实时动态加价系统设计 + BQ 技术分歧

Uber Senior SDE 的 VO 重点看两件事：系统设计能不能把一条真实链路讲透，BQ 能不能把一次分歧讲出协作过程。这篇文章按这两个环节拆开，把系统设计题的追问链和 BQ 的 STAR-L 结构都过一遍。

系统设计：实时动态加价系统

题目

Design a realtime surge pricing engine。接收司机定位和叫车请求，按地理区域计算加价乘数，结合历史需求、天气和大型活动，至少每 60 秒更新一次，供计价服务读取。

解题思路

先把数据链路讲完整：定位和叫车事件进入 Kafka，经纬度映射成 H3 网格，Flink 持续维护供需状态，再定期计算乘数并写入 Redis。乘客查询价格时直接读缓存。更新周期与处理延迟要分开讨论——每 30 到 60 秒输出一版价格是一个目标，链路 P99 低于 5 秒是另一个目标，两者不能混为一谈。

供给侧统计当前可用司机，按 driver_id 保存最新位置和接单状态，超时司机移出统计；同一司机上报多条 GPS 消息不能重复计数。需求侧按 request_id 去重，并说明窗口内请求是否包含取消和已完成订单。

H3 用来组织地理数据和查询邻近网格。网格粒度要结合司机密度和价格稳定性选择，邻近供需的融合还要考虑真实接驾时间，而不是简单按中心点距离。

追问一：加价乘数具体怎么算？

先用 max(1.0, demand / (supply * target_ratio)) 解释供需比，这是讨论用的简化公式，不是最终生产逻辑。供给为零时要单独处理，并给结果设置上限；target_ratio 要与统计窗口和供需口径一起校准，不能把 GPS 条数直接放进分母。

邻近区域的供需可以按接驾时间加权，避免网格边界导致价格突变。查询一跳邻居时，要确认返回结果是否包含中心网格，防止重复统计。历史基线、天气和活动信号再用于调整；价格平滑用于限制短时间内的波动。

def surge_multiplier(demand, supply, target_ratio, cap):
    if supply <= 0:
        return cap  # 供给为零按业务规则取上限或默认值
    ratio = demand / (supply * target_ratio)
    return min(max(1.0, ratio), cap)

追问二：Flink 任务中途崩溃怎么办？

从 checkpoint 恢复窗口状态和消费位置，再继续处理 Kafka 中的事件。写入 Redis 时带上结果版本和计算时间，防止恢复后的旧结果覆盖新结果。DLQ 用于隔离坏数据，它不会自动解决整个 Flink 作业崩溃。

读取端根据 computed_at 判断价格是否过期，允许在约定时间内使用旧值，超过阈值就执行预先配置的降级策略。若题目约定降级为 1.0x，就在此时生效；缓存 TTL 也要与这套规则协调，避免旧值已经被删除、降级却还没触发。

追问三：网格跨越城市边界，应该用哪套规则？

只说“每个城市单独配置”还不够。一个 H3 网格能跨越行政边界，要根据实际位置识别适用的 policy_id，再把规则版本送入计算和查询链路。邻居供需仍可作为信号使用，但最终价格要按该报价适用的区域规则限制。

缓存键可以加入 city_id、policy_id 和 H3 网格 ID，规则变化后重新计算或失效相关结果。不能只按网格中心决定整格的规则；边界处还要保留坐标级判断。具体价格上限由已核实的业务规则提供，不要把某个城市的限制写死成通用常数。

行为面试轮：团队技术决策分歧

题目

分享一次你与团队在技术决策上产生分歧的经历。

思路

用通知系统从定时轮询迁移到事件驱动的案例，按 STAR-L 讲：先交代数据库每 5 秒被轮询及 CPU 峰值问题，再说明为什么提出 Kafka。团队担心运维成本，就用三天做原型，对比延迟和资源消耗，并把新增维护工作讲清楚。

示例里的结果——事件链路平均延迟约 200ms、CPU 使用率下降 60%——只是示意数字，实际回答要换成自己的项目数据，并说明对应的测量方法。轮询间隔也不等于平均通知延迟，别把这两个概念混用。重点讲清楚双方各自担心什么、你用什么证据推进讨论、最终接受了哪些取舍。

备考建议

系统设计从「一条叫车请求从进入系统到拿到报价」开始完整走一遍，再补司机去重、事件乱序、价格过期和区域规则。每个组件都说明输入、输出以及失败后怎么处理，比堆组件名更有说服力。

BQ 不要停在“我说服了团队”，要把原型、测试结果和明确分工讲出来。数据必须有测量口径，避免为了量化而硬凑百分比。

FAQ

Uber Senior SDE 系统设计怎么练？

把一条叫车请求从进入系统到拿到报价完整讲一遍，再补上司机去重、事件乱序、价格过期和区域规则。每个组件都说明输入、输出以及失败后怎么处理。

加价乘数能直接用供给条数当分母吗？

不能。GPS 条数不等于可用司机数，供给需要按 driver_id 去重、剔除超时司机，并让 target_ratio 与统计窗口和口径一起校准。

BQ 怎么讲出技术分歧中的协作过程？

讲清楚双方各自担心什么、你用什么证据推进讨论，以及最终接受了哪些取舍。只说“我说服了团队”缺少过程；原型、测试结果和明确的分工更有说服力。

参考来源

联系 VOPathway

如果你希望把这套方法用于自己的 OA 或 VO 准备，可以把目标岗位、当前阶段、面试时间和主要难点发给 VOPathway，我们会据此安排针对性的练习与复盘。

微信：Coding0201
邮箱：[email protected]
Telegram：@OAVOProxy
WhatsApp：+86 178 6396 8105

可提供 OA辅助、OA辅导、VO辅助与 VO辅导。文章用于训练参考，不代表相关公司的官方流程；实际安排请以候选人收到的通知为准。