When I reflect on my journey as a Microsoft Software Engineer, the word that comes to mind is “extraordinary.” Over the course of multiple years, I had the privilege of being a part of a company that has left an indelible mark on the tech industry and the world. In this blog post, I’ll take you behind the scenes and share my personal experiences, the challenges I faced, the projects that defined my time at Microsoft, and the invaluable lessons I learned along the way.

Joining the Microsoft Team

Every tech enthusiast dreams of landing a role at giants like Microsoft. I had been using their products forever, so Microsoft was my top choice since college. My journey began during my M.Sc. degree. I applied to lots of companies online and participated in as many university tech career fairs as possible. Based on my experience, the only companies that replied back were the ones, where I had set up a personal connection.

I still remember the huge line in front of the Microsoft booth at my first career fair. At the time, Windows and Office were booming, so it was a major destination for many students. I gave my resume and went through a first-level evaluation, where I had to code some simple functions and that allowed me to proceed to the first round, which was done on campus. That round consisted of a couple of interviews on campus. I managed to clear them and got the magic ticket to fly to Redmond for the final round.

Being at Redmond was something beyond my wildest dreams. The Microsoft campus is huge, larger than a university campus. Seemed like they had more than 100 buildings in the area. And lots of shuttles that drove people from one building to the other. I arrived at the Recruiting building, which is where all candidates start their day. After a behavioral interview with the recruiter, I took the shuttle and went to a different building.

The recruiter had initially given me the names of three interviewers. I later found out that this is standard practice. If the first three interviews go well, then you proceed to additional interviews. If not, then your day ends early. After my first three rounds with two different teams, I had a couple more interviews. Since I was a new grad, all these interviews (apart from the initial behavioral interview with the recruiter) were coding interviews. I did not go through a design interview.

One tip that I wanted to share is that Microsoft interviewers tend to briefly talk to each other when they pass on a candidate to the next interview. So, having a great first interview helps set a positive tone for all the following interviews. Also, it definitely helps to show passion for technology and specifically for the product that you are interviewing for.

In my case, after the first interview was over, I was supposed to have a break. However, I spent the whole break chatting with my interviewer about my thoughts on potential issues with the design of their feature. And after joining the team, I found out that I was spot on in many of my observations. Also, in one of my last interviews, the interviewer asked me why I was interested in the area, based on my resume. Without thinking much, I innocently blurted out “Because it’s cool!”. Immediately his face lit up, he smiled and said something along the lines of “That’s right! That’s why we are in this area!”. I think that this attitude helped me a lot to get the offer, even passing other candidates, who might have performed better in the coding aspect.

The last interview was with the As Appropriate (aka the “AA”), who is the final decision maker for a loop. It’s up to the AA to decide whether to proceed with an offer or not. The AA asked some coding questions but also did a lot of behavioral questions as well. Fortunately, my interview with the AA was successful and I got the offer! I was thrilled when I received the phone call from the recruiter a few days later! I was about to become a Microsoft Software Engineer, working on Windows!

If you are interested in learning more about Software Engineering interviews, take a look at my post How to Prepare for Software Engineering Interviews.

The Microsoft Campus Experience

The Microsoft campus is impressive! I had this feeling from the first time that I saw it during my interviews until my last day at Microsoft. Microsoft’s main campus is located in Washington State, on the border of Redmond and Bellevue. There are additional sub-campus in nearby cities, as well as in different states and countries, but the main campus is by far the biggest and most impressive one.

The main Microsoft campus consists of almost 100 buildings and hosts around 50,000 employees. Each building has a number, starting with 1 and ending at a number somewhere above 120, but there are some numbers that don’t correspond to buildings. To be honest, I never counted the actual number of the buildings. They are some many and they always build new ones that it’s not easy to keep an accurate number.

One famous “missing” number is the one for Building 7. This building was scheduled to be built but never was. So, a common joke between Microsofties is to send new hires to Building 7 for “a very important meeting”. As the new hires try to find the building, people tell them that it’s between Building 6 and Building 8. At some point, they find out the joke.

There are trees everywhere, a small lake (aka “Lake Bill”, as a tribute to Bill Gates), a couple of treehouses, a soccer field, a baseball field, small basketball fields, a bus transit center (Park & Ride), a visitor center and huge parking structures. There is also a shopping mall called “The Commons”, which has restaurants, retail stores, and a pub, among other things.

The campus has lots of internal streets. They are filled with Microsoft shuttles, cars that belong to Microsofties, and regular traffic. Typically at the beginning and the end of the work day, there is so much traffic, as 50,000 people are trying to either come to the campus or to leave campus. However, during the rest of the day, it is such a pleasure to drive around the campus, explore, and take pictures.

Team Structure

Windows is a huge organization (aka “org”) split into multiple sub-organizations. The exact split changes very often and I don’t know what it looks like today, but imagine that there is a different org for kernel vs multimedia vs applications, etc. At the beginning of my tenure in Windows, each org was split into 3 functions:

• Software Development Engineers (SDE): Responsible for system design, coding, etc
• Software Development Engineers in Test (SDET): Responsible for testing
• Program Managers (PM): Covering both the role of the Product Manager (eg. writing the functional specification) and the Technical Program Manager (responsible for the project plan, communication with other teams, etc)

At some point, the SDET function was eliminated and there was a layoff in that division. The SDETs, who remained, joined the SDEs and formed the combined function called Software Engineers.

My main daily interactions were with:

• My SDE (Microsoft Software Engineer) team
• My manager (whose title was SDE Lead)
• The SDET team
• The PM team
• Our partner SDE teams and their PMs

Project Planning in Windows

Windows was built using a Waterfall methodology and had very long cycles. Remember how long each Windows version used to take?

At the beginning of each cycle, the Windows Leadership team would provide memos giving us the general targets for the next release. Then the next level of hierarchy (e.g. the Directors of each org) would provide their own set of memos that would show how the efforts of their org need to be aligned with the overall Windows strategy. So, we would see a trickle of memos from each level in the hierarchy above our team.

And as the memos trickled down, each team would decide how their efforts would look for the next release. Typically, the team leads (SDE Lead, SDET Lead, and PMs) would create a backlog of all the potential features, which would include all the requests of the partner teams, prioritize them, do a first pass in costing each feature, and provide a cut line. Then they would assign owners (SDE, SDET, PM) for each feature that would be above the cutline.

The PM is responsible for writing the functional spec (aka the PRD or Product Requirements Document, as is known in other companies), the SDE writes the design spec, and the SDET the test spec. After all the specs were reviewed and approved by all stakeholders, SDEs would start coding. The SDETs would create the test framework and PMs would oversee the whole effort. After the elimination of the SDET function, the Software Engineers became responsible for doing both the implementation and the coding.

Like in any other typical Waterfall project, it was very difficult to project timelines accurately at the beginning of the project. Some teams would plan for lots of features, others for much fewer. Some teams would be understaffed and others would be overstaffed. Each Windows version would take lots of years to be released. For example, here are the release dates for some Windows versions that followed this model:

As you can see, it was very common for each version to take 2-4 years. Starting with Windows 10, the project planning methodology changed and the goal became to have 2 releases per year: One during the first half of the year and one during the second half. That was a huge mentality change in the Windows team and led to drastic changes in the ways that the teams operated.

A Day in the Life of a Microsoft Software Engineer

As an individual contributor Microsoft Software Engineer in Windows, my day was very different during the early phases of the project planning process, during which the leadership team would send the memos and the team leads (SDE Lead, SDET Lead, PMs) would finalize the feature set and assign owners, vs the implementation phase.

During the early phases, we had much more flexibility with our time. We could spend time diving deep into the codebase, fixing bugs, building interesting prototypes, building code samples that would distributed to external developers, taking classes, etc. In general, it was a low-pressure period.

During the implementation phase, things changed. Each Microsoft Software Engineer had a specific set of features that we were working on. We started each phase by giving a high-level estimate for each feature and then providing status updates to the team and to our manager during the team meeting or our 1:1 with our manager. The Program Manager would send status weekly updates letting everyone know of the status of each feature, as well as whether there were any changes in the timelines.

Before submitting any piece of code, we would ask the team for a code review, i.e. get others in the team to take a look at the code and make sure that there are no obvious bugs, and that it follows the coding patterns of the team, etc. Only after we got explicit sign-offs from the team, would we be able to check in the code.

As time progressed and we were getting closer to the end of each phase, we would start setting bugs in the code that we had already checked in. So, on top of working on new features, we would also need to clean up any existing bugs. If the team had lots of bugs, then we would go into bug jail, i.e. we would not be able to submit any new code until we cleaned up the critical bugs.

In addition to writing code, we would have quite a few meetings to join, such as:

• Team meeting with the whole team
• 1:1 with manager
• Spec review meetings
• Bug triage meetings, where we would prioritize the bugs to fix
• Meetings with other teams
• Ad hoc meetings to discuss any important blockers

In general, during the development phase, our day would be full of coding, bug fixing, and meetings. Our effort was to reduce the number of meetings so that we would be able to focus on finishing the code.

Memorable Moments

Lesson from a great manager

I was really fortunate to have great managers during my tenure at Microsoft. All of them cared for their teams and we could speak eye-to-eye. They were all very technical, which was great for me, a passionate software engineer, who was eager to learn.

As a new grad, it is not easy to know what to expect. I remember at some point when I was relatively new to the team, I stayed up relatively late, fixing a particular bug. As I was tired, I submitted the fix and went home. However, I had made a mistake and did not check in all the files that I needed to. This resulted in a build failure. The next morning, I realized my mistake when I saw the emails with the build break errors that were sent to the whole team.

My first reaction was to panic. What would the team think of me? How about my manager? Would my performance review be impacted? Was my job a stake? Remember that I was very junior at the time.

I went to see my manager, who was already aware of what had happened. I started to apologize. I still remember his response, though. He told me that this was the first time that I did this mistake and I got a free pass. I should not worry about this at all. However, his hope was that this would not happen a second time. And it never did! From that point forward, I remembered his words and never broke the build again.

Building technical credibility within the team

I believe that it is quite challenging for a manager to decide what tasks to assign to a new hire. On one hand, the new hire has no idea about the codebase or the coding standards. On the other hand, the best way to learn is by implementing a feature or fixing a bug.

In my case, my first area of ownership was a specific area that was fairly isolated from the rest of the code, so it was easy to learn but had quite a few reliability issues, so there was lots of room for improvement. I had full flexibility to understand the code, try things, fix bugs, and learn, without breaking the rest of the team. I got into work, created my own test matrixes, fixed a lot of issues, and simplified the code where I could. All my changes had gone through code reviews, however, at some point, the question came up about whether I knew what I was doing since the code had changed a lot.

My manager decided to schedule a bug bash, during which the whole team would spend hours testing different scenarios in my area. The SDETs gathered all the scenarios that had been problematic in the past, I also provided my test matrix and the senior engineers in the team chimed in with ideas. I have to admit that I got a little nervous during that discussion because the test matrix was quite detailed and I wasn’t sure if I had deliberately tried everything.

So, the day of the bug bash came, we all split test cases and started trying different scenarios. Long story short is that after a few hours of testing, we didn’t find any important bugs with my code. More importantly, all the problematic test cases that were causing huge pains in the past, had also been fixed. I have to admit that even I was surprised by this. However, it was an amazing feeling! Finally, I got the credibility that I needed, as everyone on the team understood that I really knew what I doing and that I was the true owner of that particular area.

Accidentally discovering a decades-old bug within a core part of Windows

Windows is a product that has been used for many decades by billions of customers. There are huge code changes between different versions however there is also part of the code that is so critical and complicated that it “never” changes. In theory, this code has passed the test of time, since nobody has found any bugs for ages.

One day, my manager asked me to work on a particular customer issue. That particular customer wanted to implement an edge case scenario, which was not supported in previous versions of our product. I spoke with a couple of senior engineers, who told me about a potential method that could work, however, they were not sure, if the new architecture was compatible with the old one, i.e. whether both versions could coexist.

So, I decided to test different scenarios. I wrote down my test matrix, built different versions of our files, and tried different combinations. Things looked fine… Until I found a weird case, where something was off. I tried the same scenario a couple of times, and on different computers but with the same results. Without going too technical, I found that if I loaded a specific type of file in Windows one way, then the Windows Memory Manager would perform the loading correctly, but the unloading was hitting an issue.

Feeling uncertain about my findings in such a critical component of Windows, I emailed my manager with my findings. He forwarded my email to one of the main architects of the Windows Memory Manager. His response was that he was not aware of such an edge-case scenario, but there was nothing that we could do, as this code had been working the same way for decades. He also congratulated me on finding such a bug, which was a great feeling, coming from such a knowledgeable person.

So, I pat myself on the back, feeling happy with myself. Fortunately, I also found a workaround that prevented us from hitting that particular bug in our implementation for the customer, so I managed to fix our issue without problems.

Preventing others from breaking Windows compatibility

At the end of a very long day, I had finished my work and was ready to go home. For whatever reason, I decided to sync the codebase, i.e. to download the latest Windows sources to my computer and do a final check. Suddenly, I saw weird failures in paths that used to work before. I thought that it was I had caused the error, so I started debugging.

I was immediately perplexed by what I saw because it seemed as if suddenly we were passing “garbage” instead of actual data within our code. For example, let’s say that our code was expecting values between 0 and 10, whereas suddenly we started passing 5000+. And this was very strange because I had not made any relevant modifications to the code. And neither the code that provided the data nor the code handling it had recently changed.

After a long debugging session, I realized that a different developer in a different team had changed one of the files that should never change. More specifically, he had changed some of the values of Enums that had existed forever in Windows. It just happened that I picked up this breaking change very shortly after he submitted it. Of course, if this change persisted, then it would mean that Windows backward compatibility would be broken, as any code that used the new values would be incompatible with the code that used the old values. All new applications would immediately stop working in old Windows versions.

Since it was getting late and my team had left, I emailed my manager and my teammates with my findings. The next morning I got so many “Thank yous” from people, who were really frustrated about the issue and could not figure out why everything broke overnight. Of course, the breaking change was reverted and action was taken to never do something similar again.

What happens, when cross-team collaboration fails

The last months before every launch are chaotic. Everything needs to be checked 10,000 times, all critical bugs need to be fixed, and the Program Managers are pushing for continuous updates… There is a huge pressure to make sure that we don’t miss the deadline. So, it is logical that after the launch, things cool down a lot. All the pressure is gone, people are welcome to take a few days off, relax, etc.

Imagine my surprise, when I got to the office the next day after a big launch and got flooded by emails from our external partners that there was a huge issue in my code. More specifically, they were telling me that a very critical scenario was not working. I had tested this scenario so many times that I could not believe what I was being told. So I tried it on my own computer and indeed it was failing… They were right.

After my initial panic cooled down a little, I started debugging the issue. How is it possible that I had missed it? And what I found was that as part of the update, there was another team that had made a modification that affected my code without letting the owner of the code, i.e. me, or anyone else in my team know about it!

After checking all my emails, the comments in the check-ins, and everything else I verified that there was no prior communication, so I relaxed a little. However, the next step was how to fix it. After some thought, I wrote down a plan about how to communicate the issue internally and externally and searched for the fastest way to send a new update that would fix the issue.

Then, I spoke with my manager. After explaining what happened, he also could not believe it. He started going through the same emotions that I had gone through. He started thinking about what to do. At that point, I presented to him my plan. He agreed that this would be the best way to move forward and gave me the green light. Fortunately, it all worked out in the end and we avoided a big crisis if things had escalated.

Presenting at conferences is both stressful and rewarding

During my tenure as a Microsoft Software Engineer, I had the opportunity to present in a handful of conferences. In most cases, this task is taken by Program Managers, but in my case, I am very glad that I was given this option.

I remember that in my first conference, we had a presentation coach, who would help us present better by making sure that we keep a slow steady pace, annunciate correctly, provide tips for our slides, etc. It was a great learning experience to get coaching in this area, but at the same time, it was scary to see all the mistakes that I was making.

If the conference is taking place away from Redmond, Microsoft pays all costs for conference presenters, including airfare, food, car rental, great hotels, etc. So, from one side it is like a free paid vacation, where you have time to hang out with your team and bond. Of course, you also need to present!

Another advantage of these Microsoft conferences as a Microsoft Software Engineer is that you get a free pass to view all the presentations in areas very different than yours. So, this is a great glimpse to understand what other teams are doing. Being a Microsoft employee allows you to talk to the presented openly and find out more information than regular attendees. And this is a great opportunity, to get a backstage pass to everything that is happening in so many exciting areas.

Finally, the thing that I enjoyed the most in these conferences was talking to external partners. With some of these partners we had exchanged emails before, so it was nice to tie a face to the email. With other partners, you meet during the conference. These partners are huge companies, so it’s a great networking and learning opportunity.

Windows launch parties are great

During the era, when Steve Ballmer was the CEO, Windows was Microsoft’s flagship product. Microsoft’s strategy and success were based on Windows. Every other product was there to help Windows grow. So, it is logical to realize that lots of money was flowing into Windows. And this led to amazing launch parties, after every release of Windows!

I still remember the first launch party that I attended. It was great seeing all the Windows Leadership in one place, so accessible. It felt really easy to hang out with higher-ups in a casual setting. They were there to enjoy themselves as well. Lots of networking, great food and drinks.

However, my highlight in that launch party was that this was the first time that I saw Bill Gates in person. We were told that he was in Europe, flew to Redmond with his personal jet, talked to us, and then returned back to Europe. Wow, that is a great way to travel! I don’t remember that much from his speech, but it felt nice to meet the richest person in the world, even if it was in this setting.

The Microsoft Culture: Beyond Just Code

Work-Life Balance

Microsoft understands the importance of work-life balance and actively promotes a healthy lifestyle among its employees. The company offers flexible working hours and the option to work from home, allowing employees to tailor their work schedules to their personal lives. This flexibility was particularly beneficial during my time there, as it helped me maintain a balance between my professional responsibilities and personal commitments.

Moreover, Microsoft encourages employees to take time off when needed and provides ample vacation days to ensure that everyone has the opportunity to recharge. The company also offers various wellness programs and resources to support employees’ mental and physical health.

For more information regarding the culture in the top high-tech companies, take a look at my post Inside the Culture of the Top Tech Companies

Continuous Learning

Microsoft was an amazing school for me. The culture of continuous learning and development at Microsoft meant that there were ample resources and programs for professional development. I took advantage of various on-campus classes, and workshops, which further enriched my learning experience. These ranged from programming classes on system design, Operating System internals, and advanced debugging techniques to classes on soft skills, such as presentations, cross-group collaboration, active listening, etc. The breadth and depth of the offerings was incredible.

Mentorship and Guidance

One of the highlights of my experience as a Microsoft Software Engineer was the access to a network of experienced professionals and mentors. I was fortunate to have mentors who were invested in my growth and provided invaluable guidance, feedback, and support. They played a pivotal role in helping me navigate my career path, set realistic goals, and develop a growth mindset.

Learning and Growth Opportunities

Technical Skills Enhancement

Microsoft, being at the forefront of technology, provided a fertile ground for enhancing my technical skills as a Microsoft Software Engineer. I worked with a plethora of cutting-edge technologies and tools, which significantly broadened my technical knowledge and coding proficiency. From mastering a variety of programming languages and tools to diving into the intricacies of system design and architecture, the learning curve was steep but immensely rewarding.

I also had the opportunity to contribute to large-scale projects, which taught me the importance of writing clean, maintainable, and efficient code. The emphasis on code reviews and peer feedback was instrumental in refining my coding skills and adopting best practices.

Soft Skills Development

While the technical skills were crucial, my time at Microsoft also underscored the importance of soft skills. I learned the art of effective communication, especially when explaining complex technical concepts to stakeholders with varying levels of technical expertise. Team collaboration was another area of growth, as I worked in diverse teams and learned to navigate different work styles and perspectives.

Problem-solving skills were honed through tackling challenging projects and navigating roadblocks. I learned to approach problems methodically, breaking them down into manageable parts and seeking input when needed.

Compensation and Career Progression

Career progression for a Microsoft Software Engineer

A Microsoft Software Engineer has the option to proceed either as an individual contributor (IC) or to become a manager. Both the IC and the managerial track have the same compensation bands, so there is no compensation difference between a manager and an IC of the same level.

The following matrix shows the career progression, focusing on levels and titles.

At Microsoft, a promotion goes from one level to the next one, e.g. from level 61 to level 62. Based on the above matrix, it is obvious that a promotion might not correspond to a title change.

Salary of a Microsoft Software Engineer

The best public database for salaries in high-tech companies is provided by Levels.fyi. This website uses data from actual job offers, in order to publicize the compensation across different levels for lots of high-tech companies.

Here is a screenshot of their data For Microsoft Software Engineer salaries, as of 10/23/2023.

For more details regarding Microsoft’s compensation compared to the compensation of other tech giants, take a look at my post Salaries for Software Engineers are On FIRE!

Performance review process

During my tenure as a Microsoft Software Engineer, Microsoft did annual performance reviews. This means that every July, our managers had to write an assessment of our accomplishments throughout the year and then meet with the rest of the managers in our org, in order to stack rank us. Based on the output of these calibration meetings, we would get our compensation. Essentially, we would be bucketed in 3 different segments:

• Exceptional: Top 20%
• Meets Expectations: Middle 70%
• Needs Improvement: Bottom 10%

It was a little more complicated than that, e.g. there were 3 sub-segments within each segment, i.e. a High/Medium/Low classification within each segment, etc.

However, during the last few years, Microsoft has modified their performance review process:

• Calibrations happen twice per year (each period ends in March or September)
• Different segments, based on the rewards that the engineer will receive:
  • 0% of target rewards -> Corresponds to a Performance Improvement Plan in other companies
  • 60% -> All team transitions are blocked
  • 80%
  • 100% -> This is the actual target that most Microsoft Software Engineers will be bucketed in
  • 120%
  • 140%
  • 160%
  • 180%
  • 200% -> Max rewards
  • E.g. If the target rewards for a particular level is $X, then someone bucketed at 100% will receive $X, someone bucketed at 160% will receive 1.6*$X and someone bucketed at 80% will receive 0.8*$X
• Promotions can happen either in March or in September, but the vast majority happens in September
• Annual increases and bonuses are given in September

The most important part for this calibration process at Microsoft (both previously and now) is that your manager and your skip-level manager (i.e. the manager of your manager) play a really really important role in your promotion and performance results. As long as both of them agree that you are ready for a promotion, then there is a really high chance that you will get it. Of course, they need to provide a business justification and have the budget for it, but in most cases they manage to figure it out.

Downsides of working at Microsoft

Compensation is lower than other tech giants

One of the more prominent challenges at Microsoft is the compensation package. While the company offers competitive salaries, there is a noticeable disparity when compared to some of its peers in the tech industry, such as Google, Facebook, or Netflix. Software Engineers, particularly those at the entry and mid-levels, might find that their counterparts at other leading tech companies receive higher compensation for similar roles.

My rule of thumb is that Microsoft is paying the Software Engineers at level N, similar compensation to level N-1 at these other tech giants, e.g. a Senior Software Engineer at Microsoft is getting paid a similar amount as a Software Engineer 2 at Google/Facebook. This discrepancy can be a sig