最近走完一轮 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 在线实时提示和思路。北美求职越来越卷，如果你不想再一个人闭门造车，欢迎私信我聊聊你现在的进度和痛点，我们一起看看怎么帮你突围。
