辅面完一场 Uber SDE New Grad 面试，整体流程走下来还是比较典型的套路。黑车家 NG 一般是 4～5 轮左右，结构也比较固定：先是 OA ，然后一轮技术筛选，最后进入 3 轮 onsite（主要是 coding + behavioral）。整个流程节奏挺紧，对算法熟练度和临场发挥要求都不低。这一场刚打完，趁记忆还新鲜，来给大家做个完整复盘，顺便把关键考点和踩坑点一起整理一下。
Round 0：筛选 Coding
题目
第一轮是典型的 OA 筛选题，题目是给定一个整数数组和 limit，要求找到满足子数组中任意两个元素差值 ≤ limit 的最长子数组长度，整体思路和 LeetCode 1438 非常接近。
解题思路
这题我是按“优化路径”一步步推进的：从暴力枚举所有子数组（四重循环），优化到三重循环减少重复计算，再到双指针维护窗口内的最值，最终使用滑动窗口 + 双端队列，将时间复杂度优化到 O(n)。
面试官重点关注你如何一步步优化，以及是否考虑到边界情况。同时时间复杂度和空间复杂度的分析也会问得比较细。整体发挥稳定，顺利通过。
Round 1：DSA + 并查集（DSU）
题目
这一轮题目是拼车日志问题：每条记录表示两个用户在某个时间拼车，需要动态维护当前车辆数量，以及找出最终同车用户的合并时间点。
解题思路
一开始可以用 BFS / DFS 来做连通分量，但效率不高。优化后使用并查集（DSU），通过 union 操作动态合并用户集合，同时维护连通块数量。重点在于 DSU 的实现细节：路径压缩、按秩合并，以及 parent / rank / size 的设计。同时需要清晰说明复杂度（接近 O(α(n))）。这一轮本质是在考察数据结构基本功。
Round 2：低级系统设计（LLD）
题目 & 要求
设计一个火车-站台管理系统，需要支持列车调度、站台分配，以及基于时间的查询能力，并要求写出可运行代码。
设计思路
我将系统拆分为 Train、Platform、Scheduler、Manager 等核心类，使用 minHeap 管理调度顺序，并设计支持时间维度查询的数据结构，整体偏向可扩展设计。
面试官会持续 challenge 设计决策，比如为什么这么设计、是否有更优方案、如何扩展系统等。这一轮更偏工程能力与代码结构，而不是算法。
Round 3：高层设计（HLD）
第四轮是系统设计升级版，题目是设计 Uber Eats 首页。
核心考点集中在几个方向：地理位置搜索（GeoHash / GeoIndex）、API 设计、数据库选型（SQL vs NoSQL）、缓存策略，以及一些典型指标统计（热门餐厅、热门菜品、订单量等）。
这一轮需要画系统架构图，并且能解释清楚每一层的职责。面试官整体比较友好，会引导你一步步优化方案，比如如何降低延迟、如何提高扩展性，而不是一上来就否定你的设计。
Round 4：Manager + Behavioral
最后一轮是 manager 面，偏 behavioral，整体氛围相对轻松，主要围绕项目经验展开。重点考察的是几个维度：代码规范、ownership（责任感）、以及你做的事情有没有实际业务影响力。同时也会看沟通能力，比如你能不能把复杂问题讲清楚。最后留了时间让我反问团队情况，这一轮更多是双向选择。
面试结果&建议
这场已经稳住节奏一路打完了，最终结果也是拿到 Uber SDE Offer。如果你也在准备 Uber SDE NG，其实很多人卡的不是“不会做”，而是卡在关键时刻：思路卡住、节奏乱了、或者写到一半开始怀疑自己。这种情况下，有一个人在旁边做实时思路提醒，真的差别很大。Programhelp这边主要就是做这种高强度面试场景的 面试辅助 支持，包括 OA / coding 面 / 系统设计。
如果你最近也在冲大厂，或者正好有 Uber / 类似公司面试在即，这种实时辅助会比单纯刷题更直接有效，尤其是在“不能失误”的关键局里，提升还是挺明显的。
