Education
Why I Mentor at Cambridge (And What the Next Generation Teaches Me)
Experience without transmission is just accumulation. On why passing it forward matters, and what I keep learning in the process.
"The mediocre teacher tells. The good teacher explains. The superior teacher demonstrates. The great teacher inspires." — William Arthur Ward
There is a specific kind of confidence that only exists in people who have not yet been wrong in public. I see it in the graduate students and interns I mentor at Cambridge — this clear-eyed certainty that the problems their professors are describing have obvious solutions, and that the experienced engineers who built the existing systems simply did not think carefully enough. It is not arrogance, exactly. It is the confidence of someone whose models have not yet been tested at scale, in production, with real stakes.
I was that person once. I know exactly what it feels like. And that is part of why I keep coming back to mentor.
My involvement at Cambridge is with second-year graduation projects — the point where students go from coursework to building something real. I mentor a group through the entire arc: choosing a project, scoping it, building it, and presenting it. The project I proposed for my group was an app for blind and visually impaired users. The concept was simple to describe: take a photo with your phone, the app captions the image using computer vision, and reads the caption aloud. Point your phone at a street sign, a menu, a medicine bottle, and the phone tells you what it sees. They built it on TensorFlow — image captioning model, text-to-speech pipeline, the full loop from camera shutter to spoken word. I flew out to Cambridge every other week to meet with the group, review their progress, and advise on the engineering decisions that textbooks do not prepare you for: how to handle model inference latency on a phone, what happens when the captioning model is confident but wrong, how to test with users who cannot see the screen. Getting it to work reliably, with latency low enough that a blind user trusts it in real time, in lighting conditions that a sighted developer would never think to test for, is the kind of problem that teaches you more in twelve weeks than a year of lectures. I attended their graduation presentation. They delivered.
What Young Engineers Struggle With
The technical skills of new computer science graduates from Cambridge are genuinely impressive. They understand algorithms and data structures at a theoretical depth that I did not have at their age. Many of them can reason about computational complexity with a facility that most working engineers never develop.
What is harder — what I watch them struggle with consistently — is the gap between knowing how something works and knowing when to use it. You can understand a ring buffer perfectly and still design a system where a simple queue would have been better. You can understand distributed consensus and still reach for it when a single stateful service would have been simpler and more reliable. The judgment about which tool fits which context is not taught in courses. It is learned through building things that fail, understanding why they failed, and adjusting.
The Constraint Gap
Academic projects have clean problem specifications. Production engineering is defined by constraints: time, existing systems that cannot be rewritten, team size, operational requirements, the need to keep the current system running while you change it. Learning to engineer well under those constraints is a different skill from engineering well in a vacuum — and it is the skill that determines whether someone becomes a senior engineer or stays a proficient junior one.
The other gap is around constraint. Academic projects have clean problem specifications. You know what you are building. You know what success looks like. Production engineering is defined by constraints: time, existing systems that cannot be rewritten, team size, operational requirements, the need to keep the current system running while you change it. Learning to engineer well under those constraints is a different skill from engineering well in a vacuum, and it is the skill that determines whether someone becomes a senior engineer or stays a proficient junior one.
What They Teach Me
Here is the thing about mentoring that surprises people who have not done it: it is not a one-way transfer. The students and interns I work with regularly force me to articulate things I had been doing on instinct — to explain why, not just what.
When someone asks why we pre-allocate ring buffers rather than letting the runtime manage memory, and the honest answer is "because I have seen GC pauses take out a trading system at the worst possible moment," that is experiential knowledge that I hold informally. Explaining it precisely enough that a new engineer can internalize the principle rather than just the rule requires me to understand it at a deeper level than daily practice demands. Teaching is clarifying in a way that experience alone is not.
Beyond that: the questions that younger engineers ask are often the most uncomfortable ones. They have not yet learned to accept certain things as given. Why does this system work this way? Why is this the standard? Could it be done differently? Some of those questions have good answers. Others, when I actually examine them, reveal that the current approach is a historical accident rather than an optimal choice — that the industry accepted a pattern not because it was the best one, but because it was the first one that worked well enough and no one had time to reconsider it.
I have changed how I build things based on those questions. That is not something I would have predicted when I started mentoring.
The Responsibility of Experience
Twenty years gives you a particular kind of currency that is easy to spend badly. You can use experience to shut down discussion — "I have seen that approach fail, so we will not try it" — rather than to enrich it. You can pattern-match prematurely, seeing the current problem as an instance of a previous problem when it is actually genuinely new. The seniority that should make you useful can make you slower and more conservative than the situation requires.
What I try to offer in mentoring is not authority but context. I have been wrong in specific ways. I have seen systems fail for specific reasons. Those failures are only worth something if they are shared honestly, as stories with causes and consequences, not as conclusions that short-circuit the thinking of someone who might solve the problem better than I did.
The best moments in any mentoring relationship are not when the student does something the way I taught them. They are when the student does something better than I would have done it, because they understood both the principle I gave them and the reason I gave them the principle, and then went further. That is the version of the future I am trying to accelerate.
That is why I go back to Cambridge. Not to pass on a fixed body of knowledge. To be part of the conversation that keeps moving the whole thing forward.
"The best moments in any mentoring relationship are not when the student does something the way I taught them. They are when the student does something better than I would have done it."
Arindam Paul — Mentor, Cambridge University