At Microsoft Research (MSR) there’s a not-so-well-known role: the RSDE (Research Software Design Engineer). In this post I cover my experience going from SDE to RSDE and back to SDE, as well as the pros and cons.
My path to RSDE
Even before I joined Microsoft I was fascinated by a lot of the work being done at MSR. As a new college grad the idea of working there seemed like a dream. During my interviews I even asked my recruiter about MSR, but she told me MSR had a very distinct recruiting process and that internal transfers to MSR were not very common for software engineers. This was a bit discouraging but I was still thrilled that I was getting a job at Microsoft, so I put that thought aside for a while.
Then a year or so later I was working as a junior developer in Visual Studio and we started a collaboration with MSR (doing some nifty MSIL code injection to automatically instrument code). My manager knew my interest in MSR, so he made me the point of contact with the MSR team. And that’s when I noticed that the person I was working with had this interesting title: RSDE. Cool! This guy was a dev like me, but working on research projects. I was very intrigued and I set myself the goal to become an RSDE.
My next stepping stone was that I found myself a mentor. Back then Microsoft had a nice mentoring program where people could sign up to be mentors and you could search for one based on title, skills, etc. So when I found an RSDE that was available, I jumped at the opportunity. I met with her every month or so and I started learning more about what the RSDE job was like, and what groups would look for. And some things almost sounded too good to be true: she never dealt with build breaks, big lists of bugs or failed regression tests! This is also how I learned that RSDE jobs were mostly level 62 (i.e. SDE II) and up. Lucky for me around that time I got to that level so it was time to start looking.
Back then my work in Visual Studio was around synchronizing models (Visio like diagrams) with code. And I can’t remember the specifics but at some point we found that Phil Bernstein, from MSR, was working on some similar problems with database schema synchronizations. So we had a few meetings to discuss, and even though the collaboration didn’t go much further that gave me the chance to meet Phil. During this time I had started my masters at UW (which I describe in Can you go to graduate school while working as a software engineer?) and what do you know? Prof. Bernstein taught the course on Transaction Processing! (as an aside, this is one of the best CS courses I’ve ever taken). This gave me a chance to get to know him a little better.
Finally one day I found a job posting for an RSDE job at level 62. This was exciting! But then I paused. What if I’m not ready and I blow this chance? Perhaps I should finish my masters first (I was a couple of quarters away), this was MSR after all. And this is when it became very helpful to be able to reach out to Phil. He gave me lots of encouragement and advice (e.g. don’t wait to finish the masters). So I applied to the position, did my round of interviews and I got the job! I still remember feeling like the luckiest guy in the world.
I went on to spend the next 11 years at MSR, before I left for Facebook in 2016. So what was it like and why the heck did I leave? The short answer is that it was a fantastic experience. Below I give the long story along with why it came a time for me to leave.
So what is an RSDE?
At a basic level, an RSDE is an SDE that works in MSR and contributes to research projects. There are some developers in MSR with the SDE title (vs RSDE), but that seems to be relatively random. It doesn’t mean their role is significantly different than RSDEs. In fact I knew people whose title was SDE just because that’s the title they had before joining MSR and they never bothered to change it. The point is, you can’t read too much into someone’s SDE vs RSDE title if they are both in MSR. So for the purposes of this post I’ll generally talk about RSDEs.
The other major role at MSR is ‘Researcher’, which is very different from RSDE. Researchers are typically PhDs and experts in their field. In terms of coding, their abilities can range from close to none to those of top SDEs. They are also evaluated differently. In the case of the RSDEs, shipping products is highly valued, while academic impact is more important for Researchers. It’s also worth noting that there’s no career progression path from RSDE to Researcher (or the other way around), each one has it’s own set of levels and progressions.
Rsde vs rSDE
No, these aren’t really two separate titles :). But in some sense there are two types of RSDEs depending on their background:
One path is someone coming from an academic career, likely with a PhD but with a stronger affinity for coding than research. They have deep knowledge of their field, write or contribute to papers, go to conferences, etc. Their coding skills are on average better than those of a Researcher, but not always on par with a product SDE at the same level (e.g. L63).
The other is an SDE coming from either a Microsoft product group or another company. These are typically SDEs with a strong curiosity and a desire to get involved with the cutting edge research happening at MSR (that was me!). Their SDE background means they have very strong coding skills along with a greater degree of engineering discipline. Most of the time they don’t have a PhD, but a masters degree is pretty common. In terms of projects they get less involved with papers and research and more with shipping prototypes or transferring technology to product groups.
Another variation in the role is the type of team. Some RSDEs are part of a bigger engineering organization in MSR and there are a few of these across the various MSR locations. Other RSDEs are ’embedded’ within a research group, which means they work exclusively with that team and are usually more specialized in a certain field.
These are broad generalizations and you can find people in all places of the spectrum, but I just want to illustrate that there’s a fair amount of diversity in skill sets and team dynamics.
My own tenure
During those 11 years I was part of two teams. The first one was the Advanced Development Team (ADT), a central engineering organization working on projects across all of MSR. As an engineer there you would join different research teams needing development work for periods of 3 to 18 months. This was a lot of fun due to the variety of projects you could work on. I did hardware devices, mobile, p2p networking and even audio processing for Kinect. The team also has UX designers, program managers, software testers and even hardware engineers, so you have a nice engineering community around you.
I was having lot of fun in ADT, but all of this variety made it harder to specialize and I really wanted to dive into machine learning. So I moved teams and for my last five years I was part of the Machine Teaching Group and a development manager for engineers in various Machine Learning groups (I talk about this transition in Becoming a software engineering manager). Here I got to experience being in the embedded role and working in an specific area for several years. We focused on tools to make machine learning interactive and more accessible. Some of this work became the bases for Microsoft’s Language Understanding Intelligent Service (LUIS). These years were incredibly helpful for me in making the transition to machine learning.
The pros and cons
MSR is really its own little world and in some ways quite distinct from rest of Microsoft. As a result, being an RSDE is different from being an SDE on a product, which as some trade-offs:
Cons:
- Engineering doesn’t rule – In most product teams at Microsoft the software engineers call the shots. In MSR it’s the researchers for the most part. It is a research organization after all.
- Not shipping – The fact that you work on high risk, exploratory stuff means a lot of the code you write never ships. You may spend a lot of time in a project that in the end fizzles.
- Tech Transfers – The traditional way of getting your stuff to ship is to transfer the technology to a product group. This is not always easy since for product teams this can be a risky proposition. Although by the time I left in 2016 more and more projects shipped straight out of MSR, so your mileage may vary.
- Big Engineering challenges are harder to find – To rise through the ranks of Principal RSDE you’ll have to tackle some big engineering problems, and these are not always easy to find in MSR. For instance, you won’t see Azure scale deployments or have to speed up builds the size of Windows.
- Less Infrastructure – MSR doesn’t have the engineering systems and processes you see in larger Microsoft teams. You need a check-in process and a continuous integration build system? You’ll probably be setting that up on your own.
- Isolation – If you are an embedded RSDE you may sometimes be the only engineer in a project, with the rest of the team being researchers.
Pros:
- The people – To me this is the single biggest benefit. I met some incredibly smart people and learned a lot as a result.
- Coolness! – It’s hard to deny that a lot of research projects are just cool.
- Talks – MSR has more talks that you can attend. This includes in-house researchers, visiting researchers and even invited authors on a wide range of topics. You can even watch the recordings later if you miss the talk.
- Work life balance – In my experience work life balance is a little better than in products, which often have tighter deadlines.
- Lower taxes – Coding taxes that is. What I mean is that the overhead to writing code is much less than in a big product team. There’s typically less legacy code, support issues, cumbersome check-in procedures or systems, etc. In general you’ll spend more time in ‘prototyping mode’ than in ‘shipping mode’. I also felt there were fewer meetings and email.
- The academic circle – You can write papers and attend academic conferences if that’s something you like.
So what’s the verdict? I’d say that if research is something that excites you the pros far outweigh the cons, at least for a period of time. And there’s far more SDE jobs out there, so if you get a chance to be an RSDE for a while it’s definitely worth it.
A time for change
I thoroughly enjoyed my time in MSR and I wouldn’t change it for the world. I learned a ton, had a lot of fun and made some great friendships. My career grew and I even got the experience of being a manager. It certainly had some ups and downs (this was 11 years after all), but when I look back I feel incredibly fortunate I had this opportunity.
So why did I leave? Well, 16 years at Microsoft is a long time. It started to feel both comfortable and uncomfortable at the same time. Microsoft felt like home. I had a big network, friends, great mentors and I knew a lot of the technology inside out. And yet something was starting to bug me. I had joined Microsoft straight out of college and had never experienced another company. Part of me felt like another 16 years could go by and I didn’t want to feel like I never tried something else. Plus I wanted to challenge myself to go back to the ‘real world’ and apply a lot of what I had learned.
The RSDE role might not be for everybody. But if you are an engineer with a scientific curiosity and you get a chance to work in a research environment (in particular MSR), I highly recommend it.
And if you’ve had any similar or different experiences I’d love to hear about it!