21 Feb 2007

When I was sent to Seattle for an NSF workshop (summary of that at the end of this document), I thought I would add on a visit to the Microsoft Redmond campus. I had always wondered how things work there. I learned a lot, and took lots of notes so that I could share them with others. Michael Loceff also joined me for half of the interviews.

Michael and I asked questions around 4 topics: how the company is organized, how they do their hiring, what their software development process is like, and specific questions about their products that colleagues wanted to know about. This document is organized around these four topics also.

We interviewed the following Microsoft software engineers and found them extremely helpful and informative. The atmosphere was open and honest, with a spirit of generosity, collegiality and respect. In short, it was fabulous!

1. Corey Snow: SDE (Software Development Engineer" in the Windows Server division, working on Microsoft Connect, a website for customers to connect with and report problems to Microsoft.

2. Dan Sommerfield: SDE manager of Experimentation team.
Building a platform to make A/B testing of a new feature easy for MSN site.

3. Bradley Bartz: SDE manager of the team that plugs ASP.net functionality into MS Visual Studio.

4. Eric and Derek: In the consulting group, they develop tools that consultants will use to create solutions for customers. Right now they are enabling Sharepoint for collaborative media.

I would like to heartily thank Nima Dilmaghani for most of these contacts! I would also like to thank Chuck Lindauer for giving me the day off, and for paying substitutes to teach my classes for me. This trip would not have been possible without both of them.

I. Organization

There are three disciplines within the "profession" of software development at MS:
1) PM: program manager role, serves as coordinator, they own the spec, serve as glue between customer and SDE, manage schedules, sometimes perform analysis. Not the boss of the other two.
2) SDE: Software Development Engineer, also called "DEV", the implementor. Can be an individual contributor or a manager. Proficient in multiple languages, fluidly moves between C++, C#, etc, etc, etc.....
3) SDET: QA test engineers building test frameworks, infrastructure, write a lot of code in C# or VB.

PLUS technician level job: Build facilitating engineer, orchestrating the builds and integration between branches. Scripting, batch files, PERL. There is a build lab that has more build engineers that write and running scripts, move files around.
All have three have individual and management tracks available.

ANOTHER technician level job: There is also the role of "Support engineer" - lower level than SDE. Maintain operations of servers, write one-off programs that help the operations of servers. More common in IT role, rather than in software development. Deploy new releases of products. Fight fires when servers go down.

I would like to interview a manager of one of these aforementioned technician level jobs.

Employees see their jobs as working with people to know what to develop. The engineers focus on how things work and the managers focus on how to get things done. They were all very customer oriented. If your customer has a problem, it is your problem, it doesn't matter where the problem came from.

There is room for a straight coder who can't work with people, but they will be limited in their careers. There is especially room for someone who isn't good with communication in a bigger team, but even a senior individual contributer has to be able to communicate. A more balanced team (senior/junior, male/female, different cultures, etc) is best so everyone can get stretched and grow.

Employees feel that if they have a new idea, they can pitch a business plan and if you get the go ahead, then you are on your own to convince people via a presentation.

One example of a divison is The Developer Division, which is responsible for MS Visual Studio, and it contains many product units:
Visual Web developer, WPF, VB, C#, Core IDE, Build Lab, engineering excellence

The benefits here are great. Totally free healthcare for the whole family. If an employee's wife gets sick, MS will pay for a nanny to take care of the kids. Paternal leave of 1 month and maternal is 6 months paid. Valet parking.

II. Hiring

Three of the five engineers I interviewed had not been to college. Two who hadn't been to college were very young new hires. However, without a degree it seems like you have to know someone or be a contractor first in order to get hired.

Interview process is forward looking, as opposed to backward looking. What you can do now, as opposed to what you have done in the past. Demonstrations involve problem solving. No brain teasers. They ask problem solving cases based on real work, to see how the candidate's mind works through it.

They are trying to find out if the candidate:
a) has a good grasp of basic computer science concepts (e.g. complexity)
b) can come up with an algorithm eg.customer log, find those appearing twice
another eg: searching for products based on keywords
c) can get up and code on the board
d) can communicate through the problem solving process, can they communicate their design?

One manager said he doesn't look at certificates, another said that certificates are just one of many things they look at in a candidate, but not a deal breaker. They don't hire someone with a skill set. A lot of people look for someone with Perl, or Ajax, but MS doesn't. The problem is that the technology changes too fast, so if you have someone with a specific skill, their skill will be outdated soon.

We want smart people who can ramp up on technologies quickly, think on their feet, learn something and move on. Be fluid, agile. Soft skills are very important too, especially in program management (PM). But for a SDE, if there are no red flags (eg: beligerance) than they don't look too hard at the soft skills.

They want to see if the candidate can think of multiple ways to solve a problem, analyze different approaches to solving a problem, give pros and cons and then make a recommendation and tell why one approach is best and THEN code it. A lot will come out of that process. They want a person who can reason their way through a problem.

An engineer can easily create a poor performing applications. MS wants someone who can build a tool. People can develop bad habits in a language like VB, and then repeat these bad habits. MS wants people who are comfortable and efficient with object oriented languages. The degree isn't as important as the skills. Do they know what SCC (source code control) is?

They don't hire anyone that won't have a long career path at Microsoft.

HR has a list of soft skills that people are held up to on their performance reviews.

III. Software Development Process

In MS you will find a different dev process for each dev team. Things happen fast, sometimes specs come online the week the dev is scheduled to start coding. It isn't uncommon to see the specs even written after implementation. Sometimes specs rot.

Here are some of the processes I learned about:

a) Approx. 30% of MS say they are using Agile development process in some form or another.

b) Everyone seems to use Test Driven Development: For every one line of product code, there are a dozen lines of test code written.

c) In DEV Division, they have just started the "feature crew" model, which defines a feature, like javascript intellisense for example. Assign one or more DEV, TEST, PM's to the crew. This feature crew writes specs,etc. Before they check in their work, they must pass a quality gate, where they prove their test has a certain percentage of code coverage, etc. They continue to build in an island until they pass all the quality gates. Their feature crew manages themsleves, but they have to meet the ship train in order to ship their feature. This doesn't work well when features are dependent on each other.

d) Product units used to ask the question "what is important for my customer?" and then build the feature. This resulted in a spreading of features with no overall direction to the new features that were going into VS. Now they define a pillar, which is a specific user scenario, which defines a high level goal for MS Visual Studio. All new features will now conform to a pillar, with exceptions of course.

e) They do user testing also.

They outsource much of the dev work to local vendors. Some to India too. Some MS vendors are trying to develop software by contract on an Indian reservation in Montana because it is so much cheaper. Near shore especially for testing. They like doing this in India though, because they work at night. They give the testers offshore the test frameworks and tools that were developed inside MS.

Specs can take the form of use cases, but the form of the specs vary. Sometimes they take the form of an API.

Tools:
Using C# and javascript, Visual Studio, command line build core XT.
Managed code is run in a runtime like Java.
They build several times per day.
SQL server and tools to help deploy code, get your code onto production machines.

There is a repository of shared code, especially for test automation of a browser.
There is less leveraging of shared code at MS than at other, more open source companies.

Coding Style
They have a wiki for their style guidelines.
They have regular code reviews and code inspections, where everyone at the meeting has already looked over the code and come prepared to discuss it.
There is an engineering excellence group.
The common belief at MS is that you need to have code review and diverse engineering teams in order to write good code.

IV. Products
I was not able to get a lot of product information because the employees did not seem to have a lot of information about product groups other than their own. I also did not sign a non-disclosure agreement.

The next release of VS will have support for WPF. Expression is focussed on a designer as a user, and WPF is focussed more on coders, who use MSVisual.

Consultants are using C#, windows communication foundation, ajax extensions 1.0 for asp.net 2.0. They are mandated to drive their own technical solutions back into the product groups in specific directions.

Unfortunately I was also not able to get any information about academic programs and products. After spending a lot of time and effort, I found that Mark Hayes, MS Academic Liason in Redmond, was simply not able to help me in any way. Nima Dilmaghani, who I met at Code Camp, rescued the situation for me!

NSF Workshop In Bellevue, WA:
We were creating the specifications for a national resource center to support the revitalization of IT education. I was honored to be one of only 12 faculty invited from across the country. Most everybody was interested in Scenario-Based Learning, and many of them were already teaching in this way.

Interesting recommendations from my fellow workshop participants:
1) Googlezon, short video view of the future:
http://epic.makingithappen.co.uk/new-master1.html
2) A different academic liason at Microsoft:
Van Eden
3) A graphical way to teach beginning Java programming from the ACM Java Task Force, including turtle graphics:
http://jtf.acm.org/
4) Coders bid on small programming jobs at:
http://rentacoder.com