这轮从电话筛选到 VO 间隔不长，现场安排里最不一样的是 90 分钟 Laptop Programming Test。允许用自己熟悉的 IDE 和查资料，反而更考验能不能把需求拆开、把代码跑起来，再留时间补测试。
我把准备重点放在可运行的实现、设计时的边界取舍，以及和 HM 讲清一段项目经历。第一轮的算法题不该拖太久，Laptop Round 要预留最后二十分钟处理异常输入和回归测试。
第一面：窗口内的司机供给统计
题目：给定按时间到达的司机上线、下线和接单事件，写一个接口返回任意时间窗口内可派单司机数的最大值；事件会乱序，重复上报不能重复计数。
解答思路：先按时间排序，同一时间戳按“下线、接单结束、上线”固定顺序处理。用 Map<driverId, state> 保存司机当前状态，只有状态真正从不可派单变为可派单时才让计数加一。扫描事件时维护窗口左端，过期事件撤销对应状态；若撤销的是已被后续事件覆盖的旧状态，就按版本号跳过。这样不会因为重试消息把同一位司机算两次。复杂度：排序后时间 O(n log n)，扫描 O(n)。
第二面：90 分钟 Laptop Programming Test
题目：在本地完成一个小型任务分发服务：读入任务和执行器配置，暴露创建任务、领取任务、上报结果三个接口，并输出未完成任务的汇总。
解答思路：开场先确认领取接口是否要求幂等、任务失败后是否重试、执行器断开连接怎样处理。实现时把 HTTP 层、任务状态和内存存储拆开：请求层只做解析和参数校验，状态层负责 queued → leased → done/failed 的合法迁移，存储层按 taskId 和 workerId 建索引。先写一条从创建到完成的闭环测试，再补重复领取、过期 lease、未知 taskId 和多次上报。Laptop Round 允许查文档不等于可以跳过测试，提交前我会用一个故意失败的执行器跑完整条链路。
第三面：司机端定位更新怎么扛峰值
题目：设计司机定位更新服务。高峰时大量司机每几秒上报一次坐标，乘客端需要看到附近可用车辆，调度服务也要拿到新位置。
解答思路：入口先按司机 ID 做限流和顺序校验，只保留时间戳更新的坐标。写入流按城市或 geohash 分区，热位置放在带 TTL 的地理索引中；调度服务消费位置流并维护自己的供给视图。乘客查询先取相邻格子，再按距离过滤，避免全城扫描。要说明旧消息、GPS 漂移和司机下线：旧时间戳直接丢弃，跳变位置进入校验队列，下线或超时让索引记录过期。设计讨论里可以参考这份 Lyft 面试流程说明，把数据流、读写路径和故障恢复讲完整。
第四面：HM Round 追问上线后的判断
题目：讲一次上线后发现指标异常的经历。若修复会影响下一次版本节奏，怎么和产品、值班同学一起做决定？
解答思路：用一个具体项目开场，先交代异常指标、用户范围和当时的告警。回答不要只说“快速排查”，要讲清先做的止血动作、怎样缩小问题范围、为什么选择回滚或开关、以及修复后补了什么监控。HM 会顺着责任边界和沟通方式继续问，准备时把自己做过的取舍、没有做成的方案和后续复盘分开记，现场更容易讲得稳。
准备时怎么分配
- 算法轮先练状态维护和乱序事件处理，写完主逻辑再补重复消息、空窗口和边界时间戳。
- Laptop Round 用本地 IDE 模拟一次：从空项目开始，先写最小闭环，再逐步补接口和测试。
- 系统设计准备位置流、过期数据和读热点三件事，容量估算不需要铺得很大，关键是每个组件有明确职责。
FAQ
Laptop Round 能用网络，准备方式要变吗？
要。平时就用目标语言和真实 IDE 做小项目，练习查文档后马上写测试验证，而不是把时间耗在搜索替代方案上。
Lyft VO 里系统设计该从哪开始？
先问清读写量、数据新鲜度和失败后的表现，再画最小链路。随后补缓存、分区和降级，面试官更容易跟上你的判断。
参考来源
- Lyft's Interview Process (2026)｜TechPrep
- Lyft Interview Guide (2026)｜TechInterview
- Lyft Software Engineer VO 经验｜LeetCode Discuss
关于 CSOFFERPREP
无论是 OA辅助、OA 辅导、VO 辅助、VO 模拟面试、VO 辅助还是系统设计辅助，都可以到 CSOFFERPREP 服务页 做针对性练习。准备 Lyft VO 时，把本地实现、系统设计表达和项目故事放在同一周里演练，进步会更快。
