Jason Zander's WebLog : Pointy Hair

Staff Meeting Bingo (aka Geo Distributed Engineering Challenges)

Jasonz — Sat, 05 Sep 2009 00:11:21 GMT

Like many of you my engineering organization is spread out around the globe. With some recent relocations we’ve hit a point where we can no longer have a staff meeting slot that actually works for everyone. Jeff Beehler (our Chief of Staff for Visual Studio) just sent out a great chart demonstrating the issue as we searched for a good time to meet:

We use several different techniques to help make things work (not exhaustive).

For keeping the team in sync, every meeting has a Live Meeting link in the invite. My “All Hands” meetings are also done with a Live Meeting link and in some cases I’ll repeat the content in person when I’m visiting a dev center.

For engineering purposes we (obviously) make heavy use of TFS to track features, source, etc. Product teams work in their own “PU branches” for reasonable isolation and changes are integrated at the central branch on a regular basis. Standard sets of tests and verifications are run as code goes up / down in the system to help prevent breaks across the system. Making these kind of scenarios easier was part of the motivation behind our new testing features in VS2010. There are similar benefits with the new architecture features (like layer validation). Etc…

Have you developed best practices for working in a geo distributed environment?

Calling all interns! Come work on IronPython, Rotor, CLR Profiler and more...

Anonymous — Fri, 27 May 2005 05:16:00 GMT

We're gearing up for another round of summer internships on the CLR team and I'm looking for more candidates. We have openings for dev, test, and PM, covering a wide range of topics from:

IronPython and Dynamic Languages
Rotor (SSCLI)
New class library support
Code coverage/analysis tools
CLR Profiler and WinFX performance work
And whole lotta low level bit tweaking geek heaven in the engine

Qualified candidates should be finishing their second or higher year of advanced studies (university level). Programming skills are a must, but you don't have to be a Computer Science grad (some of our best programmers are mathematics and physics majors). Strong analytical skills are also a must. Experience working on runtimes or compilers is very helpful, but not a strict requirement. Competition is high, so expect to have a GPA in the 3.5+ (4.0 scale) range. For more details on Microsoft's internship programs, read this internship FAQ.

If you meet the criteria, please contact me through this blog and send me your resume!

Note: for those folks already in the work force, there are two links of interest:

I have a very senior performance architect job open
And our regular job openings are posted here

Pointy Hair: The Best Internship Projects

Anonymous — Tue, 07 Dec 2004 19:09:00 GMT

As much as I love spending time writing code, a big (and important) part of my day job is running a big team. Several kinds of questions come up during the various times of year. Right now we are interviewing summer intern candidates. I get asked by new leads how best to structure such efforts, so I thought I would blog my philosophy both to answer the FAQ and as a way to explain to prospective candidates what you can expect on the CLR team.

There was an episode of ER where 4 prospective interns were split between Dr. Green and Dr. Weaver. Dr. Weaver is a "by the book" rules oriented person who promptly took both interns to her office for an hour lecture on the virtues of being a Dr. She showed them where they would be working and what they might do. Dr. Green grabbed a clipboard and muttered "follow me" and proceeded to go from patient to patient and did the job. Each intern was asked to do hands on work with the patients. At the end of the day, guess which interns were totally stoked about joining the team?

If you come to work on the CLR team, roll up your sleeves. There are no observers.

My ideal intern projects meet the following criteria:

Take a Chance: Some ideas may not pan out and don't fit well into product cycles. Giving these incubation style projects to an intern is a win/win: we get to see if the idea has merit, and the intern can try to break new ground.
Bugs are for warm ups only: Fixing/finding bugs can be a good way to get exposure to a code base. But it should be done on a limited basis (1, 2 weeks tops) for an internship. I like to see how someone works under all phases of a project, not just the bug crunch.
Do the Lifecycle: I like projects that have a spec/design phase, a coding phase, a testing phase, and ideally some kind of production usage. Again, stress the broad experience.
Raise your bar: The project needs to foster getting good feedback from a variety of team members. Part of the cool thing about working on the CLR is you get to learn from people with decades of experience spanning multiple OS's, companies, etc. Ideally you will lead a CLR Architects meeting on your topic and defend your design. There is no better way to raise your bar than convincing Chris Brumme you've thought it through completely.

In the past we have had interns prototype obfuscators, create MDA plug-ins for VS.Net, write new automated test tools, analyze and publish performance projects, prototype new NGen enhancements, and implement features like the profiling API's. Many of our full time employees started out as repeat interns. At least two that I know started interning after their Freshman year.

We're looking for people who love to write code and think of themselves as developers (PM, Test, and Dev). There is a lot of competition for the open slots, so make sure to talk to your campus recruiter early and come prepared to kick butt!