Interview Experience | Systems ML Tooling | π₯π₯π₯ | Meta
2026 (Sep) Software Engineer - Systems ML Tooling @ Meta β Menlo Park β Technical Interview | π Neutral | Hard | Pending
60 minutes, technical, and no coding at all. The questions stayed on shared_ptr and memory, virtual memory, profiling, locks, and debugging, plus a project deep dive at the end.
Technical interview β memory, profiling, locks
shared_ptr
First question: is shared_ptr thread-safe.
The reference count itself is safe under concurrency. The object the shared_ptr points to is not. Using a shared_ptr does not make that object thread-safe.
Follow-up: two threads modify the same object at the same time, what then.
Then cyclic references and weak_ptr. That part went quickly.
Virtual memory
What does virtual memory mainly solve, how does a virtual address map to physical memory, and how does process isolation work.
One follow-up: if a long-running process has RSS that keeps growing, does that mean there is a memory leak.
Not necessarily. We talked about the allocator, caches, mmap, and memory that is not handed back to the OS right away.
Debugging memory growth
Then he gave me a scenario. A service runs for a few hours and memory keeps going up. How do you find it.
First confirm it reproduces reliably, then narrow it to the workload that triggers it, and look at allocations, call stacks, and object lifetimes. I mentioned heap profilers and debuggers here.
This is where he spent the most time.
CPU profiling
Then perf and debuggers. For example, CPU is high, how do you find out why.
Profile first, look at the hotspots and the call stacks.
He added a condition: CPU has no obvious hotspot, but latency is high.
Then I would look at lock contention, IO, and the scheduler.
mutex and spinlock
What is the difference between a mutex and a spinlock, and what does a lock cost in the first place.
Then: when is a spinlock worse than a mutex, and when would you actually choose a spinlock.
Using AI to find a leak
One question fit the team directly: how would you use AI to locate a memory leak.
Not just handing the code to a model and asking it to guess where the leak is.
My answer was to narrow the range with the profiler and stack traces first, then give the AI the allocation site, the ownership chain, and the surrounding code context to help analyze.
Follow-up: if the AI says the leak is at A but the profiler evidence points at B, which one do you believe.
Runtime evidence.
He also asked how I would verify a fix the AI suggests. Rerun the original workload, and also watch the memory curve, crashes, and anything like a use-after-free.
Project deep dive
The last part was a project deep dive. He asked about a performance optimization I had done before.
What he kept pulling on:
- how I located the bottleneck
- what the metric was before the change
- what it was after
- whether anything else regressed