面经 | Systems ML Tooling | 🔥🔥🔥 | Meta
2026(9月) Software Engineer - Systems ML Tooling @ Meta | Menlo Park | Technical Interview | 😐 Neutral | Hard | Pending
60 分钟的 technical，全程没有 coding。题目基本集中在 shared_ptr 和 memory、virtual memory、profiling、lock、debugging，最后是 project deep dive。
这一轮：内存、profiling 和锁
shared_ptr
第一个问题：shared_ptr 是否线程安全。
reference count 本身可以保证并发安全，但 shared_ptr 指向的 object 不会因为用了 shared_ptr 就自动 thread-safe。
follow-up 是两个 thread 同时修改 object 怎么办。
接着问循环引用和 weak_ptr，这部分很快。
Virtual memory
问虚拟内存主要解决什么，virtual address 到 physical memory 怎么映射，process isolation 怎么做。
有一个 follow-up：一个长期运行的 process RSS 一直涨，是不是就说明 memory leak。
不一定。聊到了 allocator、cache、mmap，以及 memory 没有马上还给 OS 的情况。
内存增长的 debugging 场景
然后给了一个场景：一个 service 跑几个小时以后 memory 会持续增长，怎么定位。
先确认能不能稳定复现，再缩小到具体 workload，看 allocation、call stack 和对象生命周期。这里提到了 heap profiler / debugger。
memory leak 这一段他追得最久。
CPU profiling
性能部分问了 perf 和 debugger。比如 CPU 很高怎么定位。
先 profile 看 hotspot 和 call stack。
他又加了一个条件：CPU 没有明显 hotspot，但是 latency 很高。
那可能再往 lock contention、IO、scheduler 这些方向查。
mutex 和 spinlock
mutex 和 spinlock 的区别，锁本身有哪些开销。
还问了 spinlock 什么时候会比 mutex 更差，以及什么场景反而会考虑 spinlock。
用 AI 定位内存泄漏
有一道挺贴这个组方向的问题：如何利用 AI 定位内存泄漏。
不是单纯让 AI 看代码猜哪里 leak。
我的理解是先通过 profiler / stack trace 把范围缩小，再把 allocation site、ownership chain 和相关 code context 给 AI 辅助分析。
follow-up：如果 AI 判断是 A，但 profiler evidence 指向 B，信哪个。
肯定还是 runtime evidence。
还问了 AI 给出的 fix 怎么验证。除了重新跑原来的 workload，还要看 memory curve、crash、use-after-free 之类的问题有没有出现。
Project deep dive
最后是 project deep dive，问之前做过什么 performance optimization。
他主要追这几点：
- bottleneck 怎么定位的
- 改之前 metric 是多少
- 改完以后是多少
- 有没有影响其他 metric