Hiring for Roslyn

A couple years ago I made a blog posting called "The Managed Languages Team Is Hiring" mere hours before our senior management announced that our hiring goals had been met and told me to please stop recruiting people. That was a little embarrassing. This time I have been assured that, really truly, we do have open positions on my team.


This gives me the opportunity to more clearly articulate what has hitherto been speculation and rumour. Yes, as many of you have deduced we have split the managed languages team into two teams. One is concentrating on the "async" feature that is now in CTP as well as researching and developing other possible new language features. The second team, code-named "Roslyn", is working on longer-lead tasks, namely a massive rearchitecture of the C# and VB compilers to support "compiler as a service" (CaaS) scenarios. The latter is the team I actually work on, along with a number of other developers and architects (like Neal Gafter, Matt Warren, Peter Golde and of course Anders Hejlsberg just to name a few.) We are looking less at specific language features and more at how to build a compiler architecture that is amenable to use as a foundation for modern tools.


When I joined the C# team during the effort to build C# 3 there were basically two "silos" of code on the C# team: the compiler team and the IDE team had each written their own custom semantic analyzer. (They shared a lexer and parser.) We realized that the semantic analysis burden imposed by LINQ was large, and that doing the same work twice was not a good idea. We made a major investment in enabling the IDE to consume the compiler's semantic analyzer so that we would have only one lexer, parser and analyzer suitable for both "batch compile" and "interactive" scenarios. That was a big success.


However, the interface to the C# 3 compiler's semantic analysis services is exceedingly complex and narrowly tuned to our specific IDE scenarios. And it is inconsistent with VB's similar system. And it is written in unmanaged C++, not in C# or VB, making it difficult to use it from managed code. There is a huge opportunity for the tools space if we can make a semantic analysis service that more than just our own IDE team can consume, with a consistent interface across the two premier .NET languages that is itself easily accessible from managed languages.


This is a enormous undertaking given the small size of our team; we have been working on it for some time now and we have plenty yet to do. The Roslyn team is somewhat understaffed right now; we are looking to hire someone at the "Developer 2" level. We will consider "fresh out of college" candidates but the ideal candidate we're looking for would have solid industry experience with both use of and creation of code analysis tools. We need someone who is crazy in love with compilers, who has thorough knowledge of C# and/or VB, and who wants to work with the awesome squad of senior architects and engineers we've already assembled.


The text of the job posting is below; if you are interested in this position please do not send your resume to me directly or post it here as a comment; use the mechanisms on the career site to make sure that your information gets entered into our database. If you want to mention in your application that you learned about this job here, that would be great, but not necessary.


Finally, why "Roslyn"? I was the one who came up with this silly name. Almost all Microsoft product code names are now city or town names. It's unlikely that the lovely and historic town of Roslyn, Washington is going to object to us using their name. But if we chose the name of a copyrighted character or fictional location from a book or movie then there might be a legal issue there, and obviously names already taken by other products are right out.


But more importantly my office has a northern exposure.


Ha ha ha ha ha ha!!! I crack myself up.


Job Category: Software Engineering: Development
Location: United States, WA, Redmond
Job ID:
734698 28776
Division: Server & Tools Business

C# and VB are the flagship languages targeting the .NET platform. The overwhelming majority of code running on .NET is written in VB or C# using Visual Studio. The C# and VB team build both the language compilers and the Visual Studio editing experience around those languages, and the compiler team is looking for a new team member to help us deliver on a bold, new undertaking.

Until now, the VB and C# compilers have been used as black boxes. You put text in, and you get out a binary file. In our long-lead project, code name Roslyn, we’re changing that dynamic by building an API that exposes compilers’ analysis engines. Exposing parse trees and types, expression binding, and assembly production through an API enables a world of new scenarios including REPL, C# and VB as scripting languages, and more. In order to do this right, we’re re-examining the compilation pipeline at the most fundamental level and designing an immutable model written top to bottom in managed code.

Technical challenges on the Roslyn compiler team come in many forms. Ever noticed how fast the C# compiler is? It’s not an accident. What about lambda functions? How do those things work under the covers? If you were on the Roslyn compiler team, you’d be developing high performance implementations of C# and VB language features that developers use every day. How does Visual Studio produce such accurate and quick IntelliSense? It’s the compiler guts back there, and you could help build the foundation that enables scenarios like that.

As a developer on the Roslyn compiler team, you’ll work in an environment filled with smart, industry-recognized folks working on a next-generation product that directly affects the experience of thousands of developers like yourself every day. And if you’re seeking a more direct interaction with customers, on the Roslyn compiler team you will develop an in-demand expertise in the compiler implementation that allows you to speak as a domain expert in online forums and at conferences.

We’re looking for a developer who wants to be challenged, has sharp intellect, and possesses solid collaboration skills. The ideal candidate will have a strong architectural sense, a history of producing robust and maintainable solutions, and a passion for delivering genuine customer value. Knowledge of the .NET managed execution environment is a big plus and the ability to drive open issues to resolution is a must. We program in VB and C#.

Comments (14)
  1. Kevin Stevens says:

    Ahh…for the path not taken. My favorite class coming out of school was compilers, but my brain is rotted from too many years of application coding. Good luck with your search.

  2. Gabe says:

    At first I was surprised to see that you're designing an immutable model. Then I realized that English provides no good way to distinguish a model that's immutable from a model of an immutable-something (like, in C++, the difference between a const pointer and a pointer to a const object). I take it that you're designing a model of compiling with data structures that don't have mutators, rather than a model that itself cannot ever be changed?

  3. Chris Sammis says:

    At Kevin …that describes me to a T.  I keep my brain from getting too dull by writing ever-more beautiful parsers for our simple internal searching language 🙂

    At Gabe:  Looks like the job posting is a test of semantic analysis ability in and of itself!

  4. Simon Buchan says:

    @Gabe: Why would you be surprised by an immutable model? Without it, it would be hard-to-impossible to safely combine multiple passes, or to spread compilation work over threads, or any of the other properties you would want of a high level structure of compilation. Though I imagine to get speed, this would probably work a lot like the VS10 editor model, immutable public interfaces over carefully implemented mutable backing.

  5. fatcathu says:

    Raymond Chen has an example about "immutable" today:

    "once the code ships, it's done. You're stuck with it. "


  6. Gabe says:

    Simon Buchan: If the model was immutable, it wouldn't be possible to extend it for  future advancements in compiler technology. If they created this compiler model 10 years ago, do you think it would be able to accomodate things like expression lambdas, type inference, and iterator rewriting? An extensible model is usually better than an immutable one because that means it won't have to be created anew every time something changes.

    You and Simon are both on the right track here. To clarify: when Roslyn builds up a data structure that represents the lexical, grammatical or semantic analysis of a particular hunk of code, the object it hands back to the caller is immutable, much as an expression tree is immutable in C# 3. The caller has no way of editing that thing. There are many reasons for that: immutable data structures are easy to make threadsafe, they support scenarios where old portions of the structure are cleverly re-used in future analysis, they make it cheap to keep historical data about what the analysis used to be around, they are easier to test, and so on. Internally we do use a fair number of mutable data structures for performance reasons but we try to hide this detail from the user. The kinds of things within that model will of course change and grow as the language changes and grows. — Eric

  7. Erik Källén says:

    Could this CaaS thing enable generation of JavaScript instead of MSIL? Kind of like projects.nikhilk.net/ScriptSharp but with the real parser?

  8. Ben Voigt [Visual C++ MVP] says:

    <quote>the two premier .NET languages</quote>  Surely there are three: C#, F#, and C++/CLI.  But we C++/CLI programmers are used to being ignored.  Hey wait, you're not including F# either?  Clearly there's something very wrong here.

  9. Michael Starberg says:

    *de-cloaking* and Merry Christmas to all of you. Religon aside, great week for a lot of food and async weight-gain. await a lot of workout in January. It may happen… or timeout. Maybe the task 'Beach2011' will come first. =)

    Anyway, I noticed a difference in style from Microsoft after .NET 2.0 came out. Since early windows and basic, Microsoft was very secretive about was what going on. – Here is Windows 95, take it! Here is Visual Basic 6.0, we don't need your input! Just use it!

    Maybe it started earlier, and maybe the advance in using the web as a community was maturing, but for me the major change came with the work with C#3, .NET 3.5 and the work on LINQ. Nobody and anybody like me could have an opinion. Before the CTP and then play with the CTP. Ask questions and give feedback. I really liked that.

    But this is even better. I really like how Eric sport (with confidence) that he need new hire, in his blog.

    – Join my team! I dare ya!

    I have with a great sense of humor applied for work in Erics team in a very funny email going back and forth as the 'NO HIRE' emails, where we had a bit of fun on what you should and should not do when applying for a job. There are funnier out there, especially on the daily wtf. However it ended when I asked him to formally say 'NO HIRE' to me. Eric didn't.

    So, should I apply again formally?

    I don't think so. While I have a pretty good understanding on how C# becomes CIL, my compiler coding skillz are somewhat  limited/rusty. And doing a compiler as a service? That an IDE and Re-Sharper and any application code could ride on? Have that even been done before?, scripting engines excluded?

    My little brain stand humbled.

  10. Michael Starberg says:

    Ben Voight: There used to be one premier language, but now VB is included. Java must have been the implict 0-th language supported, as Object should be clean while Java sported a few methods there. Managed C++ is on the fringe of normal application development, but have you yet found anything said that voilated C++ or F#?

    Eric is looking for a C++ reader and C# writer dev to translate a monolith compiler into a genuine API. Hey, you should apply!

  11. Paul Cotter says:

    What wouldn't I give to be involved!

    One problem with lambda expressions is the same one we see in SQL queries. Any given query has to fit in your mouth in one bite. You must understand the not only the parts, but the whole. Who, as a maintainer, has not stared at a twenty-line SQL statement, scratched his left earlobe,  and wondered, "Is the problem in there?". The ten-phrase lambda expression carries the same genetic structure. I am sure there are people out there who enjoy writing lambda novelettes which can be admired by lovers of Nietzsche. BUT, if there is an intuitive way to watch the workings of the compiler, to understand what it is doing as opposed to what you wanted it to do … well, that would be wonderful. The API is one thing. The tools that will use it are another. The latter should define the former.

  12. Alexander Morou says:

    What I wouldn't do for a PhD, or professional coding experience right now.

    Guess I'll have to enjoy being a hobbyist.  I curse being in the middle of nowhere in a tough economy.  Oh well, back to my own compiler framework.

  13. Alexander Morou says:

    Actually, what do I have to lose?

  14. Jack says:


    How does this new compiler infrastructure enable scenarios such as custom textual-DSLs?

    I am aware of the DSL toolkit team, but that is very focused on XML and the visual designer, and in my experience is both limiting and complex.

    I see meta programming as being the next big thing in productivity – so I can just define my models once (but not in C# because the syntax is not right for all purposes) then generate code to implement the various tiers (a bit like what LightSwitch or RIA services).

    There is a lot of 'cruft' that needs to be written in a multi-tier solution at the moment. If I could 'boil off' all of the excess code and just leave the essence I would say that I could describe it all in about 20% of the code or less.


    P.S. The small team makes me think Im not going to hold my breath for any of this technology in VS vNext 🙁

Comments are closed.

Skip to main content