So how much and how hard do you have to work at Microsoft to be successful? I was asked this question by a graduating student who has an offer from Microsoft to be a software design engineer. Actually the question was "do I have to work 100 hours a week to be successful?"
I went back and forth in my head how to answer this one. Well on the one hand, I should probably say that if you come to Microsoft you will have a balanced life where you can work, have hobbies, have friends, and all will be great. On the other hand, I keep reading articles about how at "Web 2.0" companies you get hired from college and live in your office--you don't even need to leave to eat since they bring gourmet food to your office. So I certainly would want everyone to think that Microsoft has a competitive offering and that if you join here you can live in your office and work 16 hours a day (or night). But I would not want folks to think we're inhuman.
I'm not really sure what the best way to answer this is, so let me just tell it like I see it.
The truth is there are two "cycles" of workload that you go through at Microsoft. The first is the cycle that starts as a college new hire and evolves as you gain experience. The second is the project cycle you are on and how that has an ebb and flow.
When you first join Microsoft from college you are very much on a "college clock". That generally means you arrive with that blurred view of "work" and "social life" because in college things are all basically one long experience, punctuated by exams and the summer. You probably want to sleep late and work late. You probably move out here and don't bring a built-in social network like the one you developed at school. And you probably are really anxious to start your job. All of these lead to a pretty intense start to your working life. You are probably going to work as much at Microsoft as you did in the combination of attending classes, studying, and doing project work. At Cornell I took about 18 credits a semester, which translates into roughly 18 class hours per week and generally the guideline was that every hour in the class was 2 hours of preparation or work over the course of the semester. So that means just over 50 hours per week. That pretty much is what I would say is average for a new hire. Is that a lot? Not enough?
Well when you're new at something you always put in that extra effort and pay very close attention to all the details. Some things are way harder when they are new (like how much time it took to write a 5 page paper as a freshman compared to a 20 page paper as a senior). Coding on commercial software is no different. It takes a lot of effort up front to contribute effectively and efficiently. And when you're new you will put in extraordinary efforts to get those first pages of code done well--you will write and rewrite them and test them repeatedly. Believe me it is a big deal writing code and checking it in for a few hundred million people to use! And since at Microsoft you are on real products the day you show up, this will likely be a pretty all-consuming learning process.
In other words, no matter how many hours you are officially supposed to work when you are new you will put in a lot more to get those projects done. That is ok. No, that is expected because you are going through the learning phase. Your learning is not happening on a practice field but is happing in the big show. So the extra hours and effort are worth it to you and the team.
And of course as a college hire you are joining Microsoft with a large number of other college hires (we will hire more people from college this year than any other year, and more than any other computer software company I'm pretty sure). In fact, there is a good chance some of your classmates will also be joining Microsoft. So in many ways your college experience will get translated immediately to Redmond (or Mountain View, or any of the other locations mentioned in other postings). Every "class" of Microsoft has different things that become popular and even within the class you get the same sort of extra-curriculars that you had in college. Some folks go to dinner and movies with their team, others go with their classmates. It is just like in college where some people ended up being friends with their house/roommates and others found people through organizations (at Microsoft we have all the same sorts of clubs you have in college--I spoke at CHIME last week, which is Chinese Employees at Microsoft, for example).
Microsoft will feel a lot like college in terms of the hours you put in and the environment you work in. It will be fun. It will mean late nights. It will mean "hanging out". All of those same things. That was my experience and when I look around I see the same thing happening now.
The only thing I would say is that anyone who tells you how cool it is to pull all-nighters on commercial software or anyone who says "I live at the office" and means it, is really someone I would not want checking code into my project. To be blunt, there is no way you can do quality work if you do not give your brain a break. Since the 1940's people have been studying the quality of work people are capable of without the proper sleep, change in environment, and exercise. There are reasons why even back during Apollo moon missions they forced the astronauts to sleep and not run on adrenaline. So working at Microsoft does not push the limits like this--it is not good for you, not good for business, and not good for the customers paying you for your software. If a company is driving you to work crazy hours like this, either because you want to or they want you to, it is just uncool.
There is an "arc" to this and as you get older two things happen. First, you get better and what you do. So you really can get the same amount of work done in less time, and you do it better. Just like how you got better at problem sets through college. And second, you do start to develop a "work-life" balance. For some people this happens in 3 years and for others it happens in 5 or 10. It all depends on you and your own skill/career arc. You are not slowing down. You are not doing less. You are becoming better at your chosen profession. You are moving from an apprentice to a skilled practitioner. Your individual contribution should be increasing each year as you get promoted and gain deeper and broader knowledge. But you also might be developing a relationship with a significant other. You might want to start a family. You might be contributing significantly to the community. You might actually be taking your vacation and going somewhere other than visiting your parents.
Microsoft is a place where as you increase your skills and advance your career you also simultaneously develop a more balanced approach to life. You have to. Because we want you to have a long and balanced career at Microsoft we do expect your career arc to allow you to attain more balance as you gain experience.
The project cycle represents ebb and flow of work that overlays your own career arc. This workload is well understood and repeats itself each project, but even here we are careful about what is good business and common sense.
The role each of development, testing, and program management plays in the project cycle is matched by level of work "intensity" over the course of the cycle. Early in a project cycle is when program management is writing specifications and planning the release. Testing and development are reviewing specification and planning their next steps. Development is not actively writing code and so their intensity is relatively lower. And testing is likely very focused on planning for the end game. As we progress to the coding portion of a project, development really ramps up their efforts and the intensity increases. Developments intensity also increases as the schedule gets closer and closer to the "end". This is because developers own their own schedules and sign up to get their work done based on their own estimates. So as you can imagine this gets pretty intense. But you are on record to deliver about 35 hours of coding per week (depending on how your group accounts for the schedule) so any "overtime" you put in is really your own. Of course developers also love to go above and beyond the call of duty so it is likely that cool features get done in addition to the committed ones. As development nears the end of coding, testing really ramps up. This is where we are now in Office "12" and in fact this morning we had a test manager meeting going over the work needed to get to our second beta (our first beta is about to hit the streets).
As an aside, it is really the case that you own your own schedule. This does not mean that you work in isolation for as long as you want--your work interacts with other's work and other's depend on you. It does mean that you have to take the desired outcome and scale it appropriately to fit within a normal schedule. Of course you don't really get trained in this in college so that is the role of your lead in terms of mentoring you and helping you to estimate and gauge the work ahead of you. Over time you become expert at this and then soon enough you are managing and mentoring new people yourself.
A lot of companies think that it is cool to buy dinner all the time and do whatever it takes to keep you at your desk to work more during these "crunch times". We actually don't generally do this for Office (though some teams occasionally do). Over the years we've found this is not a good practice for the team overall because it encourages a style of work that does not yield good software. But trying to keep people chained to their offices, in the name of encouraging team work and dedication, does not help. I remember back in 1990 working on the first C++ compiler and we were doing the dinner thing for the team and I remember noticing that a lot of folks would just end up eating dinner at work then going to dinner later in the evening--that does not get better code, though it does yield bigger waistlines. I admit then when people tell me about other companies that buy you dinner and change your oil in an effort to keep you focused on work, I do worry about your health and if you really are able to write quality code. The best example of this is just how you can stare at a bug for 8 hours and make no progress, but if you leave work, clear your brain, and maybe do something nutty (like ride a bike, play racketball, or play poker) you probably will find you can fix that bug with a whole fresh perspective. I think that is an important part of every work day.
Therefore the work week has different levels of intensity as you move through the product cycles. There is a flow to this just like you have a flow to a semester (introduction stuff, problem sets, mid-term, project, final). But for a Microsoft project there are numerous highs and lows that map to both the discipline you work in and the phase of the project.
I think it is super [sic] important that throughout the project cycle you pace yourself--like any endeavor you can only run so hard for so long. What we do is hard, unpredictable, and important for a lot of people. It is also incredibly fun. What you find on our development teams is that most people would be sitting in front of computers, even if they didn't get paid. Computers are also our hobbies. Most of us run elaborate home networks, love to help our friends and family with their machines and networks, and many of us help local community organizations with their PCs. But it is also important to balance this with the need of your brain for down time and the need for you to gain a perspective on your work and what you do.
Finally, the core question is not just do you need to work 100 hours a week, but "do I need to work 100 hours a week to get ahead". The answer to that is definitely no. You need to get a lot done and you need to do it efficiently. We want you to be a heroic developer in the sense that you get more high quality work done in a shorter time than others, but not in the sense that you can work 100 hours straight to produce 50 hours of work without sleeping, eating, or leaving your office. Microsoft went through the phase of growing up where we thought the best programmers were those who survived on Starbucks and gummy bears--we actually studied bugs counts and defect rates and found that the people that wrote the most code, also had the most incomplete code and the most bugs/line. We want you to be great programmers who write high quality code that works right the first time and for a long time. That takes far more skill and talent than you can make up for by sitting at your desk for heroic hours. Developing your skills, making sure your code is complete, bug-free, highly performant, scalable, highly secure is the way to get ahead. Maybe your manager works a lot (I do) or maybe your manager is very efficient, but the hours you work is not a measure of your ability to succeed and certainly not something you get evaluated on. You get promoted because your work excels relative to your peer group--because you get done what you say your going to get done; it works super well; and you got done the right amount of work relative to your peers.
Working at Microsoft is hard. We have a lot of people counting on what we deliver. You will put in a lot of hard hours. But if you are managing your work effectively then you will have a rewarding career and a rewarding balance between life and work.