輔面完一場 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 / 類似公司面試在即，這種實時輔助會比單純刷題更直接有效，尤其是在“不能失誤”的關鍵局裡，提升還是挺明顯的。
