這輪 Uber SDE2 Level VO 的 coding/design 題本身不難，但很考驗候選人對「動態更新 + 順序約束」的建模能力。
題目要求實作兩個操作：
postCustomerVisit(customerId)：記錄一次訪問getFirstOneTimeVisitor()：回傳目前只訪問過一次且最早出現的使用者
若不存在，回傳 None / null。
這題真正要考什麼
它同時包含兩個條件：
- 動態更新：訪問事件持續進來
- 順序維護：不是找任意 one-time 使用者，而是最早那個
很多人卡在「使用者第二次訪問時，要怎麼從順序結構中間刪掉」。
最穩的建模方式
兩個資料結構就夠：
HashMap：記錄每個customerId的訪問次數Queue：按第一次出現順序入隊
更新路徑
呼叫 postCustomerVisit(customerId) 時：
- 次數加一
- 若是第一次出現，加入隊尾
查詢路徑
呼叫 getFirstOneTimeVisitor() 時：
- 檢查隊首目前次數是否仍為 1
- 若不是，表示已失效，彈出隊首
- 重複直到隊首有效或隊列為空
- 有效隊首即答案；空隊列回傳
None
為什麼懶清理是關鍵
隊列中會有失效元素：第一次訪問時入隊，但後續又訪問過。
這是刻意的設計。與其在每次更新時做中間刪除，不如在查詢時從隊首懶清理，邏輯更簡單，也更符合流式場景。
SDE2 常見追問
1）時間複雜度
postCustomerVisit：均攤 O(1)getFirstOneTimeVisitor：均攤 O(1)
每個元素最多只會被彈出一次。
2）並發一致性
SDE2 常被追問 thread safety：
- 單機：用同步機制保護 map + queue 一致更新
- 分散式：依
customerId分片，並定義穩定排序策略
3）記憶體控制
長時間運行下 ID 會增長，可補充：
- TTL 或滑動時間窗
- 僅保留近期活躍資料在記憶體
- 冷資料下沉到持久層
Uber SDE2 高頻 3 個 BQ 問題
- 講一次你發現團隊方向有問題並主動修正的經歷。你怎麼識別風險、怎麼推動落地？
- 講一次你和 PM 或跨團隊在優先級上有分歧的經歷。你如何平衡交付速度和工程品質？
- 講一次你處理 production incident 的經歷。你如何排查、溝通同步與後續防再發？
這類 BQ 主要看 SDE2 的 owner 意識：不只是把任務做完，而是對結果和後續影響負責。
備考建議
這類題建議按這個順序練習：
- 先講清楚狀態
- 再講更新與查詢路徑
- 最後講複雜度與失效元素處理
面試裡把這個節奏講順，通常會比直接埋頭寫程式更加分。
需要面試真題？ 立刻聯繫微信 Coding0201，獲得真題。
聯繫方式
Email: [email protected]
Telegram: @OAVOProxy