最近走完一轮 Apple SDE 面试，整体体验非常典型：不考八股、不聊过往项目、不问 system design，三轮全部纯 coding，但强度很高，下面分享 12 月这套真题。
Timeline
- 11.28 第一轮
- 12.12 第二輪 + 第三輪（同一天完成）
节奏不算极快，但后两轮背靠背强度非常大，中间几乎没有缓冲时间。整体流程比较干脆，没有拖很久。
Round 1
第一題給了一個持續接收 event log 的系統。日誌按 timestamp 遞增，每條包含 timestamp 和 eventType。同一個 eventType 可能在短時間內連續出現很多次，如果全部原樣儲存，會浪費大量記憶體。
要求在實時 append 的同時完成壓縮儲存，並支援後續查詢。
這題關鍵不在統計，而在“如何對連續重複事件做區間級建模”。自然思路是把連續相同的 eventType 壓縮成一個段結構，每個段記錄 eventType、startTime、endTime 和 count。
當新日誌到來時，如果型別與當前段相同，就擴充套件區間；如果不同，就新建一個段。查詢時透過二分定位時間區間，找到重疊的段做聚合。
面試官會不斷追問插入複雜度、查詢複雜度、如果 timestamp 不再遞增怎麼辦、如果支援刪除怎麼辦。整個過程很考驗你對資料結構的掌控是否足夠紮實。
Round 2
第二題是一個多版本配置系統。系統有多個配置源，每個都是 key-value map。每次更新都會生成新的版本號。現在需要支援在任意歷史版本下查詢某個 key 的最終生效值，並且配置源之間有優先順序覆蓋關係。
這題本質是持久化資料結構問題。不能為每個版本存完整快照，否則空間會爆炸。合理做法是每次 update 只記錄變更，透過版本共享來減少儲存。
查詢某個版本某個 key 時，需要沿版本鏈向上查詢最近一次對該 key 的修改，並結合優先順序規則確定最終值。
面試官追問的重點在於如何最佳化查詢效率、如何避免深鏈遍歷、如果版本數達到百萬級怎麼辦。這一輪更偏工程抽象能力，而不是純演算法技巧。
Round 3
第三題是拓撲排序變體。給定一組任務，它們之間存在依賴關係形成 DAG。同時每個任務屬於某個 group，同一個 group 內的任務必須嚴格按照提交順序序列執行，不同 group 之間可以並行。
要求輸出一個合法執行順序，並且在合法的前提下儘量讓任務更早開始執行。
難點在於如何把 group 內順序約束翻譯成圖結構約束。常見做法是為同一 group 內相鄰任務新增隱式依賴邊，再與原始依賴邊合併，然後統一進行拓撲排序。
面試官會問是否可能產生環、複雜度是多少、如果 group 數量很大怎麼辦。這題核心不是拓撲排序本身，而是約束建模是否嚴謹。
瞭解更多
如果你正在準備 Apple SDE 或其他北美大廠技術面試，建議不要只刷題，我們提供系統化面試輔導服務，覆蓋 OA輔助、VO助攻 、由北美一線 CS 工程師進行 1v1 線上實時提示和思路。北美求職越來越卷，如果你不想再一個人閉門造車，歡迎私信我聊聊你現在的進度和痛點，我們一起看看怎麼幫你突圍。
