Robinhood 的面試還挺注重 communication 的，不光要寫對 code，還得講清楚你是怎麼想的。我面的三輪基本都是 LeetCode medium+system design，沒有特別離譜的難題，但 follow up 問得挺細，得把 trade-off 講明白才行。
第一輪 coding
題目：Robinhood有個推薦系統：老使用者推薦新使用者加入，每條推薦關係只能發生一次，不會有迴圈推薦。我們想知道哪些使用者的“推薦鏈”最厲害，統計每位使用者最終帶來的新使用者總數，然後列出影響力前三名。
解題思路：首先整理推薦資料，用字典記錄“推薦人-直接推薦使用者列表”，確保每個新使用者僅歸屬1個推薦人，然後對每個使用者，遍歷其推薦鏈，統計不重複的新使用者總數，最後按“推薦總數降序、使用者名稱升序”排序，擷取前三名並按“使用者名稱 推薦數量”格式輸出即可。 本質是處理“無環單向圖”的節點後代數量統計問題。
第二輪coding
題目：給定一個由“買入”和“賣出”訂單組成的訂單流，需要計算訂單的總成交數量。
解題思路： 用有序結構存未成交單：買入單按價格降序，快速找高價買單，賣出單按價格升序，快速找低價賣單，均記錄“價格+剩餘數量”，然後逐筆處理訂單，買單打匹配價相等賣單，賣單打匹配價≥自身的買單，取最小量成交併累加總數，剩餘訂單更新或留存，最後等所有訂單處理完，輸出總成交數。
第三輪：Design a Leaderboard
題目：Design a leaderboard with the following APIs:addScore(playerId, score) top(K)
reset(playerId)
這題其實是資料結構設計題。我當時跟面試官討論了幾個方案：
方案一：hashmap + 每次 topK 時排序。優點是簡單，缺點是大規模資料下 topK 效率低。
方案二：hashmap + 最小堆（size K）。addScore 的時候更新 hashmap，topK 的時候遍歷 hashmap 維護一個大小為 K 的 min-heap。但這裡有個坑：如果已經維護了一個全域性堆，reset 或者 addScore 更新分數時，堆裡可能有髒資料。所以要麼惰性刪除，要麼用 balanced BST。
方案三：hashmap + TreeMap（或者 sorted set）。用 TreeMap 維護分數到 playerId list 的對映，這樣 topK 可以直接取最大 key。面試官對這個方案比較認可，說空間換時間，思路清晰。
最後討論
面試官最後拋了一個open-ended 問題：如果這個 leaderboard 在高併發場景下怎麼辦？可以考慮幾個方向：
- 讀寫分離
- 快取 topK
- 非同步批次更新
- 分散式排行榜（分片）
這種問題一般不需要特別完整的答案，主要是看你的系統設計思路。
面試卡住怎麼辦
其實很多同學在技術面的時候不是不會做題，而是現場壓力大、思路容易斷，尤其是像Robinhood 這種 follow up 很多的面試，一旦某一步沒想清楚，就可能被一路追問卡住。
如果你也擔心在 VO 或技術面裡出現這種情況，可以提前瞭解一下programhelp的 面試輔助 ，在你面試過程中如果遇到卡點，可以得到思路提醒和方向提示。
