About Mansoor Mamnoon

Before I wrote code, I spent years on UKMT math competitions — evenings on problems where the only tools are attention and patience, and the only reward is the feeling of the solution clicking into place. That habit of looking for structure under a complicated surface is still how I approach engineering. When I arrived at Berkeley and took my first systems course, I wasn't learning something entirely new: I was learning that the things I already found beautiful — invariants, state machines, careful reasoning about what can go wrong — had been hiding inside computer architecture the whole time.

I gravitate toward the layer of software where decisions are irreversible. A dropped packet, a corrupt log record, a race condition on a hot path — these are not bugs you fix with a unit test and a redeploy. They require understanding the machine at every level: the cache hierarchy, the memory model, the protocol, the scheduler. That's what drew me to OS 162, Compilers 164, and DB 186, and to building a C++20 matching engine from scratch with slab allocators and CPU pinning rather than reaching for a library. The interesting engineering is in the gap between what the abstraction promises and what the hardware actually does.

I became a CS 61C Senior Mentor and Content Lead because teaching forces honesty. You can bluff through an interview question about cache associativity; you cannot bluff through writing a worksheet for 300 students who will immediately notice if your explanation of false sharing is wrong. Writing the CS 61C worksheet on memory hierarchy and pipelining taught me things about those topics that three semesters of coursework hadn't. The notes page on this site is mostly me doing the same thing privately — writing a clear sentence about something until the sentence stops being wrong.

This summer I'm joining Databricks' Traffic Platform team, working on the networking, security, and performance layer for large-scale distributed infrastructure in Go and Rust. Before that I spent a summer at Amazon building a real-time IoT platform. The common thread in the work I find most interesting: systems where correctness and performance are in tension, and getting both right requires understanding what's actually happening below the interface.

Outside of engineering, I play cricket and tennis, follow both poorly, and have strong opinions about RISC-V and moderate opinions about everything else. I think the most underrated quality in an engineer is being genuinely useful to the people around you — clear in code review, honest about what you don't know, good at making the person next to you faster. That's what I'm trying to build toward.