Bruce Dawson does some of Microsoft's most valuable work for Windows. Doesn't even work for them.
He was on my interview loop at ATG, and I recount it as my favorite interview of all time. He pointed to a circuit diagram poster, and said to me "You have to write a game for that, what design considerations should you be aware of?"
It looked something like this (can't find the actual poster, it's been a decade): https://qph.fs.quoracdn.net/main-qimg-9cdbc7bf35ef8126755175...
A bit out of my league, but I identified the important aspects (multicore/hyperthreaded design, small L0/L1 cache and impacts to mispedictions, etc.) and spoke to what I could and where my uncertainties lay. Afterwards he gave up the rest of the time to let me ask questions about the team.
One XFest he stood on stage giving a Powerpoint presentation on debugging and multithreaded concerns. An animation was slow, and he broke into it and started debugging Powperpoint live to demonstrate some of his techniques. A legend.
A huge loss to Microsoft when we stepped away. I did and do hope him the best!
Can you describe some of the insights you learned from the exit interview -- about growing your career and becoming a subject matter expert? I'm new to the field and I feel like that'd be immensely valuable to me and many others.
But most importantly, give talks and brownbags about the technology. Understand that there's going to be someone in the room that knows more than you... but they aren't giving the talk and helping everyone else, you are. They will chime in, and that's OK. You are the one putting yourself out there educating yourself and others. This helped me so much when I gave talks at GDC... even if I'm helping ONE person, it makes the event worth it (and the talk serves as my unique perspective / take on the industry).
Pour over source materials. Bruce read the 600+ page CPU documentation front-to-back, twice over. He said the second time, he gleaned so much more insight.
The engineers didn't realize just how much knowledge they were trying to distill, so you might read a comment that says "Of course, the second parameter determines XYZ." The first read-through, you might gloss over that. The second read-through, you realize the instruction they're documenting is doing double-duty elsewhere, and the comment is an important indicator of how that interaction plays out on the die.
Good luck!!
Is there a video of this somewhere? Sounds amazing.
At that point I was an ex-Microsoft person giving a talk at a Microsoft conference using Microsoft tools to profile Microsoft's presentation software. It may have been a cheeky thing to do, but it was so much fun.
I'm not aware of any publicly available video but I did a writeup of the issue: https://randomascii.wordpress.com/2011/08/29/powerpoint-poor...
We were the firefighters when a game studio's experts couldn't figure out what was going wrong. They may provide a code snippet, or in rare cases the full game, and we could debug with the console's OS/driver source code. We even had access to the processor layouts for figuring out hardware bugs. We'd get copies of the Red Disc and Green Disc masters used for duplication, before the game was published (helped figured out a few 0-day patch bugs that way).
The other half of the job was proactively figuring out what problems studios would run into with new APIs and new SDKs. How would they want to use them together, and the challenges that posed.
Finally, we were the developer representatives, advocating on their behalf as the platform progressed.
Was an amazing job. I only left because I just couldn't pass up my dream job (reworking the telemetry/stats pipeline for Halo 5, and getting to play with TB of data).