Uber 的 OA 整体节奏偏快，出题风格兼具实用性和复杂度，适合有一定刷题基础的同学挑战。我是在秋招期间投的后端开发实习岗位，提交简历后一周左右收到了 OA 邀请，平台是 HackerRank，一共两题，限时 90 分钟。相比其他公司动辄三题甚至四题，Uber 的 OA 看起来题量不大，但实际难度不低，时间也很紧张，需要较强的思维转化能力。
第一题是经典变体的“Merge Intervals”题型，不过加入了业务场景，比如每个 interval 有权重，要求合并区间的同时保留最大权重。题目虽然不新颖，但实现过程中有很多细节需要注意，比如如何处理重叠区间、如何保留和更新权重等。我在这里花了将近 40 分钟，主要卡在边界判断上，建议大家平时刷题时多注重这种“套路题”的变种，不要只记模板。
第二题难度明显上升，是一道图论相关的题，需要找出一个节点网络中，所有可以双向到达的路径对数。题干很长，业务背景模拟的是 Uber 司机和乘客的匹配场景，如果没接触过图的遍历和联通分量这类题目会很吃力。我的做法是先建图，然后用 DFS 找出每个联通块的大小，最后计算组合对数。这个题目不是特别绕，但题干信息量大，一开始没有抓住重点，白白浪费了不少时间，后面才慢慢理顺思路。建议大家练习这类“长题干+简单模型”的题，锻炼快速提取有效信息的能力。
总的来说，Uber 的 OA 更偏工程实际场景，题型虽然在算法框架内，但融合了业务逻辑，对细节处理和代码风格都有较高要求。另外，如果在 HackerRank 平台上卡壳，系统不会提示错误类型，因此要养成良好的调试习惯，多写单元测试。做完后我收到 HR 邮件约了技术面试，说明 OA 评分不仅看 correctness，也看效率和可读性。总体体验下来，Uber 的 OA 不算最难，但绝对不能掉以轻心，刷题之外更要注重题目背景和实际场景的理解。
