Rudi Martin is a software developer in Microsoft, who works on .NET.
He explains how is the envirnoment in MS. What you should expect inside. He also explains about the MS' interviews. What does it look like and what you should do during the interview...
Look inside Microsoft... read the interview.



1) Did you contact Microsoft, or they did contact you?

My case was somewhat unusual, I guess. I was working for a different company (Digital) over at a small site of theirs in Scotland. In the turbulence that followed Digital's acquisition by Compaq it was decided to close that site down.
Microsoft heard about this and given that the site comprised thirty or so experienced engineers, sent an interview team over. A number of us went through technical interviews there and then flew out to Redmond a couple of weeks later for a second round of more informal talks. About ten of us eventually accepted positions in MS.

2) What were their requirements, in order to apply for a job?

Well that didn't really in my case But I can give an idea of what we look for in general. The most basic requirement is a college/university degree in some numerate discipline (computer science, math, physics etc.). Not all of our developers come from a CS degree and this matters less than you think it might (it's rare that a university course will match with a company's requirements — on the job training is inevitable — the purpose of the degree is mainly to show the candidate's ability to learn). Microsoft is a company with a strong technical focus, so you should know your basics well (at least a couple of years of experience with one of the C-like languages, a good grasp of fundamental algorithmic concepts such as lists, trees, hashes, sorts and searches etc.).
Above all, we appreciate self-motivated individuals who have a genuine love for software development.

3) What did the interview look like? What questions did they ask you (personal, programming...). Did they give you some assignments to solve?

Again, my interview process was not exactly typical, so I'll focus a little more on how these things generally go. An interview with Microsoft (at least for a college hire), will typically last about a day. During that time you'll interview with maybe four or five people (developers from probably a couple of different groups). Each interview is one on one and lasts maybe 40 minutes or so. There's an initial interview with a representative from Human Resources (HR) that's there to sort out logistics, put the candidate at ease etc. before the real interviewing begins.

The actual interviews themselves, since they're run by developers in the group, will vary somewhat from group to group and also with the individual interviewer, but there are some general points to bear in mind:

a) MS interviews tend to be technical; you'll probably be asked to write code on the whiteboard (one problem, maybe two) at every stage of the interview. These problems tend to cover basic design/implementation tasks (e.g. linked list insertion/deletion, string manipulation, tree transforms) that are intended to take anywhere from 5 to 20 minutes to solve. Aside from that there will probably be higher level technical questions that you'll be expected to discuss without producing any code (e.g. how would you design a virtual memory paging system?).
b) The interviewer will ask about previous projects/code you have worked on. This is to get a feel for the experience you have, but also allows the interviewer to assess your communication skills. Being able to clearly express yourself (particularly when discussing the technical aspects of something the interviewer may not be familiar with) is a very valuable skill.
c) There will be very few personal questions (beyond some simple pleasantries). For legal reasons, the interviewer *cannot* ask race, religion, sexual orientation, geographic etc. questions. So most interviewers will just steer away from anything not directly related to software engineering, just to be on the safe side.

Some quick tips:
a) Don't obsess about your appearance; looking neat is good, but we're more interested in the contents of your head (and this is MS, we don't wear ties
b) Try to relax as much as possible (I know this is hard). A calm interviewee makes a much better impression.
c) Talk to the interviewer: ask them clarifying questions when they give you a problem (this is expected and desired by the interviewer), tell them what you're thinking when you're trying to design the solution to a problem (if we just see you standing there staring into space, we'll assume you've frozen up — the interviewer is interested in how you approach a problem, not just the final solution).

4) What previous jobs you have had? Did you have or did you need any testimonials from your past employers?

I worked for Digital (DEC) for 7 years, firstly on the VMS operating system then on NT. That was mainly file systems and networking in the kernel (I designed the protocols behind TCP/UDP ports 579 and 625, though they're Digital propriety so I can't share the details

A reference from my previous boss was asked for (usually, for college hires HR will want at least two references from college professors or an internship employer). In my case this was somewhat odd since my boss was being interviewed for a job at MS at the same time!

5) How long did the interview took?

I my case it was a day of technical interviews (well really only three hour long sessions) and another day at MS itself, talking to representatives from 3 different groups, trying to get a feel for the type of work being done there (those weren't really interviews per se). I described a more typical pattern above.

6) Are you pleased with the salary that Microsoft offers? Are you afraid to lose your job there, because of the slow-down inthe IT sector?

Yes I'm not worried by the current job situation, these fluctuations happen in cycles every few years. It does mean that it's more of a buyer's market at the moment however; don't expect to be able to haggle between companies for higher salaries to the extent you could of a few years back.

7) What is your job there?

I'm a SDE (Software Design Engineer), or dev (developer) for short. For most of the three years I've been at MS, I've worked on the low level security aspects of the .NET Framework runtime (mainly declarative security, infrastructure and strong names). I also briefly worked on some of the threading aspects (I wrote most of the object locking code used by the C# 'lock' primitive and the Monitor class).

I'm currently looking at other core pieces of runtime functionality for the next version.

8) How are you givven something to code? I mean, do they tell you something like "write a function/class that does the following..."?

How you're assigned tasks depends greatly on your level (and your group for that matter). A recent college hire, for instance, is much more likely to be given a straightforward, well-defined and constrained task (such as a specification for a function or class).

As your career progresses, you take on the responsibility for more of the task — you are given a higher level specification of the problem and it's your job to design and implement from then on. The higher you go, the more abstract the problem specifications become, and choosing between the variety of potential solutions becomes a significant part of the process.

My group is relatively small (I'll get into the details in a later question), so individuals tend to 'own' part of the code base. If something needs to be done (a tester finds a bug and enters a bug report, a new feature request comes in or the code simply hasn't been finished yet), the dev simply does whatever he or she needs to do to finish the job. Any major scheduling conflicts are resolved between the dev and their manager (fairly soon after a new hire arrives they're expected to take an active part in scheduling their work).

Interactions between you and your manager and the rest of the team can vary greatly depending on the dynamic of the group you are working with. And there are a lot of different groups at MS.

9) How many hours per week you work?

That's flexible and depends on the point of the product lifecycle I'm currently at. Projects tend to be broken up into significant milestones (places where large pieces of the project can sync up and stabilize and, of course, large milestones like shipping a beta or the finished product). Near the end of one of those milestones the hours are likely to be long (working evenings and weekends). Conversely, near the beginning it's not uncommon to see people head out in the afternoon to go hiking or skiing/snowboarding.

The longest run I've done so far is two 36 hour stints separated by a 4 hour sleep. But that's only happened once in 3 years and there have been a number of occasions when I've only just made it into work in time for lunch

10) Does Microsoft give you the opportunity to go on higher levels? For example program manager or something like that?

Oh yes, I wouldn't work for someone who didn't. One of the nice features of MS is that it retains a high degree of technical competence at higher levels (many high level managers came from the developer path). This allows your career to progress in either a managerial or technical (or some mix of the two) direction to a very high degree indeed.

In MS a program manager is not actually a higher level than developer, they work side by side with developers (we hire program managers direct out of college in some cases, for instance). The difference is not in level, it's in the focus of their jobs: program managers often take a broader view (interacting with customers or other external parties to drive future requirements for the project, working on whitepapers and other presentations of the technology and helping with the design of the overall product). The mix between dev/PM responsibility is another one of the things that varies wildly amongst the different groups at MS.

11) Many programmers are against .NET at all. How does Microsoft think to make them switch to it?

Well I cannot speak for MS as a whole (as for this whole interview, I should point out that these are my own views, and these are not necessarily shared by my employer), but I would say you can never make any developer do what they don't want to do — just try making one change the way they format their code, or use a different editor from the one they've been using for the past ten years.So all that MS (or anyone) can do is to endeavor to produce the best, most flexible, most powerful environment we can. If we can succeed in that, then it will sell itself and people will be won over. There are always going to be people who have a philosophical objection to one particular way of doing things (or the company that's doing it). That's just a fact of life. You accept that and move on.

12) Approximately how many programmers work at Microsoft/your department?

Microsoft employees something like 49,000 people worldwide. About 24,000 of them work here in Washington state (most of them in Redmond).

As for in my department, that depends on the level you take the count at. My group (the CLR team responsible for the core runtime) has somewhere on the order of 40 devs (I really haven't counted in a long team). The team I currently work for within that group has 5 devs (and I'm currently off doing a side-project for the group, so maybe the answer should be 1

13) What do you think is the perfect equipment to develop with C++...I mean, which components are the most important in a workstation configuration? Or in other words, Do you use Dell, Compaq, etc. or what configuration?

The manufacturer is not that big of the deal from a development perspective (as long as they produce reliable products at a price that's acceptable to you, that's good).

If you're going to develop large project's (million lines plus), you're going to be doing a fair amount of time staring at the screen during compilations, so here are a few tips:
a) A second machine is handy so that tests or e-mail can be run on one while the other is busy building. The second machine doesn't typically need to be as fast as the main development machine (most devs in our group have two machines, quite a few have more). We use keyboard/video/monitor switches (KVMs) to cut down the amount of clutter this would otherwise bring into an office.
b) Multi-cpu boxes (dual procs are usually enough for a developer) are handy from two perspectives: if your build process is multi-threaded (the compilers aren't but our build process is and can be compiling multiple files at once), then there's a noticeable performance boost (not 100%, but
still significant). Compilation/linking is a classic example of a process that swings from CPU heavy to I/O heavy constantly, and multi-procs come into their own here. Even if you don't have a multi-threaded build process, dual CPUs will allow you to get work done on the computer while you're building (important if you don't have a second machine available).
Secondly, if your code is multi-threaded, there are timing window problems that hardly ever show up on a uni-processor. It's a good idea to have devs with dual procs just so they'll see these bugs earlier in the product lifecycle.
c) Extra memory probably speeds up building (especially linking) more than a faster CPU for the same price. Memory prices fluctuate wildly from time to time; wait till they're low then buy as much as you can afford (and will fit in your machine). My primary dev box at work has 768MB, my primary at home has 512MB. Overkill for most applications but can take a minute or two off those slow builds.
d) Another thing that slows down builds is disk access (lots of random I/O sandwiched between heavy CPU usage). If you've got the cash, it might be worth investing in a high-end SCSI adapter and disk (such as the 10,000rpm models). The disk doesn't have to be huge, just enough for the build. Even without an expensive disk/controller, getting a second EIDE disk and using it with builds will help (keeps the build files and the system pagefile separate for instance).

14) In what ways will Visual C++.NET differ from Visual C++? I heard that Visual C++.NET is far different from Visual C++, so there will probably a lot of compatibility problems, how to solve that?

Visual C++.NET is out there, you can go find out for yourself (Though all the language localized versions might not be available yet).

The new C++ isn't all that different in terms of syntax additions to the language. C++ is an established standard, so backwards compatibility is very important and additions made cautiously (notice how some C++ compilers still let you turn the bool keyword on and off? same reason).

So the new C++ is pretty much identical to the old language with a few new keywords (all beginning with , like gc). Old code should compile just fine (to native code, just like it always did). As you begin to use new features there will be a learning curve (though it's pretty simple stuff, it's designed to be easy). But C++ will make it very easy (even easier than the rest of the framework) for your old unmanaged C++ code to interoperate with your new managed C++. So it should be possible to convert your classes one at a time to managed code (to take advantage of garbage collected memory management, run time code generation etc.).

15) What was the reason for desiging C#?

That I can't comment on, those decisions were made before I joined the company.
But one of the nice features of the framework is its ability to support multiple languages seamlessly at the same time and what better way to showcase this than adding a new one?

16) What are the differences between .NET and J2EE when it comes to security?

Frankly, I have no idea (I have no experience with J2EE at all). One of the notable features of .NET Framework runtime security (and again, I have no idea if J2EE has a similar concept) is code access security.

This is security based on the identity of the code itself (i.e. where was this code authored) rather than the identity of the user running the code (i.e. which login account owns this thread/process).

In the future, this will make it possible to protect against such virus attacks as the 'I Love You' worm. You will be able to execute attachments safely because even though you have the privileged to read/write/delete your own files, code from an untrusted source will not and will be stopped should it attempt to.

You can also apply security demands declaratively with .NET (i.e. attached as attributes to a given method). This can make security simpler, easier to read and less error prone.

17) Is the Microsoft culture all it is *****ed up to be? Do people stay up late into the morning crunching code because they WANT to and enjoy it...

Microsoft is certainly a pretty intense environment (at least around my group).
You tend to be thrown into the thick of it from day one and expected to stand on your own two feet pretty quickly. It's challenging and personally I like that.

You get all sorts of people working here. Sure we get our fair share (more than our fair share) of people who practically live in their office, but these days there is greater diversity. (According to the folks at the Microsoft Museum, a shift in attitudes occurred when the balance of employees at MS moved from their 20s to their 30s and families/kids became the norm).

All in all, the culture at MS is one of the big plusses when it comes to working here.

18) Whats the most exciting project you have worked on at Microsoft?

That would be the .NET Framework runtime (That's all I've had time to do, these projects are *big*).

19) What's the future of the C++ language; I mean, there will be a future for this language or will be suppressed by Visual Basic, Java or something else?

I'm sure C++ is around for the foreseeable future (after all, people have been predicting the death of FORTRAN and COBOL for years now, and they're both still going strong). .NET should help with that; it provides an environment where multiple languages can seamlessly co-exist (even on the class inheritance chain, or during debugging). So there should be less pressure to develop products monolithically in a single language; you'll use whatever language suits the task/suits you.

20) What kind of people work at Microsoft? Are they just pure and boring coders or interesting people that you might won't to hang around after work and so?

Well I hang around with a bunch of them after work and I don't think I'm just a boring coder (I bike, snowboard and wind-surf for starters).

Microsoft is one of the most diverse places to work imaginable; there are people here from all sorts of different backgrounds, with a variety of ways of approaching their jobs and lives.

21) I was wondering if you'd had any experience in the games programming area, and what type of experience is required to land a dream job programming games for a large corporation like microsoft?

Not much I'm afraid (my last foray into the field was when I was still at university — I sold it to a games magazine for enough money to buy me my first hard drive

Games programming is a popular area (for some reason people think it's going to be fun so you have your work cut out for you to stand out from the crowd.
The only advice I'd offer is to try and work on a portfolio in your spare time: mini-games, demos and the like that showcase your talent. Actions speak louder than words in those fields. A good grasp of DirectX/Direct3D is particular would be a good starting point.

Also, what does C# and the .NET platform offer for games programmers.

I wouldn't be surprised if start seeing DirectX wrappers for C# appearing soon.
After that, it's pretty much the same sets of benefits as for other applications. .NET would certainly have some use for the higher level aspects of game programming (such as integrating web support for things as automated patching, global ranking etc.).

22) Is nerf still big inside MS?

My manager has a pretty fearsome looking nerf gun, but apart from that I don't see much of it these days (we have plenty of other silly stuff to occupy us).
When I first started working here, one of the devs used to bring his pet tiger in from time to time (way cooler than nerf, and it's a heck of a shock to meet a tiger in the corridor

Apache and other GNU network systems seem to dominate the "large" network platforms, what is MS position on GNU.

This one I'll have to dodge, I can't answer MS policy questions, that's for MS to do.
This interview was taken by Ilia Yordanov