面经周报（10/19—10/25）：OpenAI 实时系统、Anthropic 前端与 Databricks 路线规划

本期整理 2026 年 10 月 19—25 日的面经资料，覆盖截至 10 月 25 日收录批次可见的内容，未宣称覆盖周日全天。重点是实时状态、既有项目修改、路线状态建模，以及时间限制下的需求理解。

资料口径：选用本地 10 月 21 日、22 日、23 日、25 日收录的公开论坛文字快照。它们的收录日期不等于实际面试日期。以下内容是候选人的单次报告与本站训练建议，不代表公司统一流程、完整题库或通过门槛。部分图片与隐藏内容没有进入文字快照，对这些缺口不作补写。

本期题型索引

一条系统设计记录描述实时多人打字竞赛，包含匹配、进度同步、错误惩罚和观众。正文提供了需求，但没有候选人的完整架构或面试反馈。OpenAI 实时竞赛系统设计记录。

我们的建议：练习时先区分三类状态：比赛生命周期、选手输入进度、观众展示数据。说明哪些信息由服务端裁定，客户端上报哪些事件，再讨论通信协议和分区方式。

重点追问可以是：重复或乱序事件是否改变结果？短暂断线后如何恢复进度？客户端本地时钟能否影响惩罚计时？观众增加时，如何避免让每个选手承担额外广播压力？这些是从需求延伸的训练问题，不是原帖公开的面试官追问。

练习结束前，走完一次“加入比赛—开始—输入—异常—完成”的路径，再描述一个服务重启后的恢复过程。图中的组件都应对应具体请求和状态。

一条 Frontend 全流程复盘提到 Autocomplete、在既有代码库与 PR 上修复问题，以及聊天系统设计。作者没有获得明确的逐轮评分，因此不能据此判断哪一轮导致拒绝。Anthropic 前端全流程复盘。

我们的建议：Autocomplete 训练要覆盖输入变化、异步响应乱序、键盘选择和空结果。可以用请求版本或取消机制避免旧响应覆盖新结果，但最终方案应与所用框架和接口契约一致。

对于允许 AI 的项目练习，按“复现问题—定位模块—提出小改动—运行验证—解释结果”推进。不要仅因为生成代码看起来合理就认为问题已解决。修复 PR 后，应检查它是否影响其他调用方、已有测试是否覆盖真实用户路径。

例如修复搜索结果闪回的问题，验证重点应是快速输入与慢响应组合下的行为，而非只增加一个正常响应的测试。AI 使用规则以自己的邀请与面试官说明为准。

一条电面记录提到最佳通勤路线，以及允许换乘的 follow-up。正文没有完整输入格式、代价定义或约束，不能直接认定必须使用某一种算法。Databricks 路线规划电面记录。

我们的建议：先确认最优指最少时间、最少换乘还是最低费用；再确认等候、步行和换乘惩罚是否计入。如果换乘成本取决于当前线路，只用“站点”作为状态可能不足，需要考虑“站点与线路”的组合。

无权图、非负权图和含时刻表的路线问题，适用方法不同。先明确模型，再选择 BFS、Dijkstra 或时间相关的搜索方式。用一组“多走一站但少换乘”的例子检查目标函数是否真的反映需求。

一条 DE 复盘报告 SQL 与 Python 的题意理解耗时，并提到 Python 部分未在结束前跑通。其文字快照没有完整 SQL schema 或可还原的题干，因此本期不据此列出具体“新题”，也不把作者关于换题的感受当作全公司题库变化的证据。Meta DE 电面复盘。

我们的建议：SQL 练习先说清输入与输出粒度、连接键和重复行来源。Python 练习先跑通一条最小路径，再增加后续需求。给自己设置检查点：前半段结束时，至少有一个可验证的结果，避免把所有运行时间留到最后。

可复用的练习是给同一份事件数据分别要求“每用户”“每会话”“每日”结果，检查聚合粒度改变后，去重与连接逻辑是否仍正确。这是本站训练设计，不是对缺失题目的还原。

一条 Team Screen 过经提到 KYC、运行提供的测试入口以及现场环境安排。这些属于个人经历，不能推导完成固定数量阶段就一定通过。Stripe KYC Team Screen 记录。

我们的建议：面试前检查共享屏幕、编辑器、运行命令与网络；拿到项目后先确认如何执行样例和查看失败信息。每一阶段完成都运行一次，留下足够时间修复语法、导入和返回格式问题。关于工具、共享方式和时长，以自己收到的安排及现场说明为准。

复盘时把技术能力与现场节奏分别记录：是模型错了、实现错了，还是没有及时运行？不同原因对应不同训练，单纯再刷一道相似题未必能解决原来的缺口。