Are you interested in getting a Software Engineering job at a top tech company like Microsoft (or Google, Facebook, Amazon, etc.)? Are curious about the interview process and looking for some tips and advice on getting started? Then read on. I will attempt to demystify the interview process and offer some advice from the perspective of an interviewer. While I’ve tailored this post to fit Microsoft’s process specifically, most of it is applicable to any of the top tech companies.

If you are a video person, I have a video on this topic on my YouTube channel.

Step #1 Ask yourself: Why do you want to work at Microsoft?

I think this is an important, but often overlooked question that you should ask yourself. Why Microsoft, or any other company for that matter? It could be a number of reasons: a specific product or a team, reputation of the company, compensation and benefits, or any other personal reason. All of them are valid. My advice to you is to find at least a few reasons, and make a mental note of it. This will help you find passion in the process. For example,

I want to work for the XBox Live Services team at Microsoft because I’ve been an XBox gamer for almost a decade now, and would love to contribute to that team

I want to work for the browser’s security and privacy team because I am passionate about cyber security and I think the new Edge browser has made amazing progress in terms of user privacy, and I would love to be part of that!

You get the idea.

Step #2 Find the positions you are interested in

Sign up at Microsoft’s career website and find a few positions that you are interested in. Start by searching for keywords, then filtering further to match your location, career stage and area of expertise. Once you have a few jobs, save them in your profile. At this point, you can apply, but hearing back is hit or miss. The reason for that is because of the sheer volume of applicants Microsoft gets. By the time your application meets a recruiter’s eyes, the position may have already been filled. There is a better way, which takes me to step #3.

Step #3 Build your LinkedIn profile / resume

If you don’t have a LinkedIn profile, create one. It is okay to have a bit of a personality in there, but keep it mostly professional. It isn’t meant to be like Facebook or Instagram. In today’s day an age, paper resumes are becoming irrelevant, esp. in the tech world. Sharing your LinkedIn profile should suffice. If you do end up needing a resume document, you can always export your LinkedIn profile as a PDF.

Creating good resumes is a big topic on its own, but I will offer a few quick tips here.

• Your resume should read like a list of achievements, not like a job description

• Include numbers wherever you can — for example, write “I helped scale project X from 200 users per day to 10,000 users per day” instead of “Worked on project X”

• Do mention the tech stack you used for each project

• If you are a fresh college graduate, do the same things, only that you will write about your best projects instead of your recent jobs

Step #4 Find a point of contact

The best bet here is if you know someone personally that works at Microsoft. Ask them if they would be willing to refer you. By personally, I mean is that you have worked with them, or they are aware of your projects or skills as an engineer. A friend of a friend may work. Ask your friend if they may be willing to ask their friend to refer you. It may not work, but never hurts to ask. Please do not add random engineers on LinkedIn that you don’t know. There is no benefit to doing that.

If you don’t know anyone, don’t fret. Reach out to a few recruiters on LinkedIn. Again, don’t start adding them. Instead, send an email expressing your interest. Do your homework. Don't just say — "I want to work at Microsoft." That sounds entitled. Instead, like I mentioned in step #2, leverage the career website and find exact positions that you are interested in. Briefly explain why you are interested, why you think you would be a good candidate and how you are passionate about the company and the position. And it goes without saying, please be courteous and respectful. You may need LinkedIn premium to be able to send emails to people outside your network, but if you are serious about this, I think it is worth the upgrade.

Step #5 Prepare for the technical interviews

This is the most difficult part of the process and where the bulk of your time should be spent on. Technical interviews at top tech companies are designed to be very difficult, and you will most likely need to do extensive prep work regardless of how much experience you already have. And the most common reason I see candidates fail tech interviews is because they don’t give themselves enough time.

Why are these technical interviews so hard?

Logically, the technical interviews only really test your problem-solving skills based on what you learned in college. But, in practice, that is also what makes them hard. We don’t normally solve those kinds of problems on our daily jobs as engineers. Consider Max Howell’s case for example, who created Homebrew, a very popular package manager, one that is widely used all over the world. But, when Max interviewed for an engineering role at Google, he was rejected because he could not invert a binary tree on the whiteboard, even though Homebrew is used at Google as well. It does sound silly when someone who’s already demonstrated an ability to create something from scratch and get it widely adopted gets rejected for failing at a simple problem solving question. I don’t think anyone would argue that Max wouldn’t have done a great job at Google, or at any other company. However, a case like his is an outlier. For the majority of candidates, these notoriously hard interviews exist for three main reasons:

1. Microsoft, or any other top tech company, expects their engineers to be well rounded

   It is rare that you will only do the high-level engineering side of a project and not get into the nitty gritty of optimizing every little bit of code. One day, you may be designing a large-scale distributed system and another day you may be improving a specific lookup to make it 12% faster because a previous version was using a less effective hashing function. This is the reason you are expected not only to know high level design, but also core data structures and algorithmic optimizations.

2. Standardize the process

   These interviews are very structured. You are told you will need know a very precise list of things and the types of problems you will be asked. So essentially, they are just like standardized tests like SATs and GREs. In most cases, they aren’t the most effective tools to gauge an applicant’s intellect, but most top schools require that you get a very high score on them anyway. Why? Because it is the same for every applicant, so it provides a standard framework, and it is known to be a difficult thing to master. At the very least, it shows your drive: when push comes to shove, can you take a hard challenge and get it done?

   Evaluating anyone in a 45 minute session is difficult. Malcolm Gladwell, in his new book, Talking to Strangers, even makes a point about how we are inherently bad understanding strangers and how that makes interviewing a very difficult challenge. That’s why standardizing the process that is agreed to be a difficult challenge helps make better hiring decisions.

3. Filter out most of the candidates
   Companies like Microsoft get a lot of applications but hire very few. Hiring the wrong candidate can cost a company a lot of time and money. So it is better to err on the side of caution and very very selective. The acceptance rate at Harvard for the class of 2019-2020 was 5%. Acceptance rates for engineering jobs at the top tech companies is less than 0.5%. These technical interviews help effectively filter out an immense majority of candidates.

What areas do the technical interviews cover?

Technical interviews at Microsoft cover three key areas.

1. Problem solving (coding)

   These interviews are probably the hardest ones for most people. You will be presented with one or two problems, and are expected to solve them in about 30-45 minutes. It used to be common practice to ask puzzle-type questions like “How to Move Mount Fuji,” but not any more. Instead, these will be purely related to core data structures and algorithms. These are also language-agnostic, meaning that it won’t matter which programming language you use. Just use one that you are most comfortable with. Normally, will are required to write code on the whiteboard. But because of COVID, currently these interviews are virtual and are conducted via Coderpad, Collabedit and Microsoft Teams.

   A good example of a coding interview question is: “Convert a Binary Tree to a Linked List, in place.” To be able to solve this in a reasonable amount of time, you will need to know, at the very least, what a binary tree is, what a linked list is, recursion, and depth first search or some other form of tree traversal. And even with all that knowledge, modifying child pointers in place is a very tricky problem. Not only that, you will be excepted to write error-free code, explain your algorithm, come up with test cases and validate those, and discuss both the runtime and space complexities of your solution. All under 45 minutes. This is why these are challenging. Given enough time, and access to the internet, and your favorite compiler, many more people would likely be able to solve these questions. But without any of those, it is tricky and takes a lot of practice. Students right out of college tend to do better in these interviews because their knowledge of data structures and algorithms is fresh.

   A lot of candidates take the brute force approach to getting better at problem solving by mindlessly solving hundreds of interview questions. Based on my experience, that approach isn’t effective and results in many candidates stumbling in their actual interviews. I wont go into more details about problem solving here to prevent this post from getting side-tracked, but if you are interested in learning more, let me know in the comments below and I can make some videos solely dedicated to tips, tricks, advice and strategies I recommend for getting better at coding interviews, and doing so efficiently and productively.

2. System Design

   System Design interviews explore your ability to take something vague and ambiguous, and come up with a scalable architecture. Some example questions are "Design Twitter" or "Design Yelp". As you can see, these are very vague questions. Obviously, you aren’t really expected to design the real Twitter, that would impossible for just one engineer to do, let alone in just 45 minutes. What the interviewer is looking for whether you can take Design Twitter, and convert that to a set of solid requirements. For example: What is Twitter? What can a user do on Twitter? What features can we come up with just based on a few user stories? What is the expected performance? Do tweets need to show up within 5 minutes, or instantly? How many users can we expect daily? How are we going to handle the load if that grows significantly? So on and so forth. You get the idea. Once you have those, then you use your knowledge of various systems to come up with a proposed design that is extensible, reliable, available and scalable. On top of that, you are also expected to discuss trade offs of your design.

   There is rarely any code to be written in these interviews. This is a high-level design process. 90% of interviews I take are System Design interviews. I love asking System Design questions because it relates very well to real-life brainstorming and lets candidates express the breadth of knowledge that they have. Experienced engineers tend to do better in these interviews.

   Again, I will keep it short here. If you want t me to talk more about this specifically, let me know in the comments below.

3. Behavioral

   The third, and most commonly overlooked one by candidates during their prep, is behavioral interviews. These can have anything that is non-technical, but generally, the interviewer will ask probing questions about your past experiences or projects, looking to understand your approach on various areas like trade-offs, team work, communication, budget, project management, deadlines, and customer interaction — what challenges you faced, and how you worked around them. Instead of reciting coined answers to known behavioral questions, my advice is to know your work and projects in depth, not only from a technical stand point, but also from a non-technical stand point that I just described.

What does the full interview process look like?

There are typically 7 interviews at Microsoft. The first one isn't really an interview, but rather a conversation with the recruiter to see where your skills align. If you get a referral from someone, you generally skip this step.

Then you will have a phone interview. This is going to be an hour long. 15-20 minutes of it is usually spent on getting to know you, some behavioral questions, and the remaining 40-45 minutes on a coding question.

If you clear the phone screen, you will be invited for what is called an on-site "loop", where you fly in to the Microsoft campus (usually at Redmond) where you will be interviewing. Microsoft will pay for your flight, food, hotel and all other expenses. The on-site loop is typically 5 interviews. All of these will also be an hour long, except one, the lunch interview, which is one and a half hours. As a general rule-of-thumb, you should expect three of these to be coding interviews, one to be system design and one behavioral. This can change a bit depending on how far in your career you are. If you are straight out of college, you will likely get four coding interviews and one behavioral. If you are a Senior Engineer, then you will likely get two coding interviews, two system design interviews and one behavioral interview.

On the day of your loop, when you arrive on campus, you first meet with your recruiter who will answer any questions you have and briefly explain you how your day will be. You are generally scheduled for three interviews at first. You get two more if you do well on those.

I also want to add that Microsoft is a giant company, and is always looking for ways to improve the interview process, so certain teams may be experimenting with different interview styles like online assessments. So, you could see one of those in your interview process. That being said, the 5-interview format is probably going to hold true for 90% of applicants. Also, given the COVID situation, all interviews are obviously held virtually right now.

How are you evaluated?

As an interviewer, the most important thing I am evaluating is your problem solving aptitude. When given a coding problem, hopefully one that you have not seen before, how do you go about solving it? Note that I did not say "how you solve it". I said, how you "go about solving it". This distinction I think is critical because I see a lot of people being too obsessed about the solution, and not the process of getting to the solution. I am not trying to say that solving a problem serves no purpose, it does. What I am trying to say is that between a candidate who flawlessly solves the problem without any discussion whatsoever and a candidate who had all the right ideas, had a lot of back and forth with me, and almost got to the optimal solution, I would pick the latter. Because eventually, I am trying to hire someone who I can work with everyday, so being able to communicate technical ideas with relative comfort is a huge benefit.

Also, don't memorize solutions to common problems. One, it is really easy to spot when someone genuinely comes up with a solution versus when they already know the exact solution. Also, there will almost always be a follow up question that changes the constraints on the original one. And if you do the first part flawlessly but completely stumble on the follow up, it is a red flag. In fact, if you get a problem you have seen before, be honest and let the interviewer know. You will get brownie points for honesty. The interviewer may ask you to solve it regardless, or make some minor changes, which will only work in your favor. In my interviews, I generally pick a random question, usually from a real-life scenario related to system design, that even I don't know the exact solution to, then work with the candidate to solve it together. If we can work together to get to a solution, it is a strong indication that I can work with this person on any random problem in real life. And if the candidate goes even further and drives the discussion to lead me to the solution, they are not only great to work with but also can teach me a thing or two. That is awesome!

So, the key takeaway here is that when you prep for your interviews, do not forget communication — ask questions if you are confused or stuck. Coding is already a very structured thing, don't be afraid to add a little personality and human element to it. For example, in C#, a HashSet look up is .Contains(key) versus a Dictionary lookup is .ContainsKey(key). I get those mixed up all the time. Your interviewer won’t care about minor details like that. But if I am interviewing you and you made a light-hearted comment about it saying, "Man, I get these two mixed up all the time," I would totally relate to you saying "Yeah, dude, I do that all the time, too." Things like these alone won’t make you do well on your technical interviews because skill is first and foremost, but it makes the whole process more human. Think of it as a collaborative effort at solving a problem, where you are driving, and not a test where someone is evaluating you with a cold heart. As an interviewer, I want you to succeed as much as you do! I understand how much effort and dedication it takes to even get to the onsite interviews, I have gone through it multiple times myself, and I empathize with you and want you to do your best!

Communication is even more critical for system design and behavioral interviews because those are very open-ended. There is no optimal solution to those. So it is imperative that you take those as a "technical discussion" between two engineers. Ask for advice, take advice, don't be afraid to disagree politely if you have an alternate approach and offer your trade-offs. Also, like I said before, don't be afraid to admit that you are stuck or you don't know something. Nobody knows everything. I'm a senior engineer because I have a wide area of experience, not because I know everything. In fact, I routinely learn new things from Junior engineers and interns. This is a valuable mindset to have not only for your interviews, but in life in general. Also, if you are a funny person, be funny. If you are a serious person, be serious. Don't try to be someone else in an interview because someone told you it works better or someone else who was a certain did well in their interviews. Be yourself.

Finally, even though your interviews at Microsoft will mainly be focused around your technical expertise, your interviewer will always be looking out for valuable attributes like customer obsession, drive for results, teamwork and leadership. So, always keep those in the back of your mind, and if you get a chance to display that, by all means, do so, especially in your behavioral interviews.

Once your interviews conclude, each interviewer will discuss their feedback and recommend a Hire or a No Hire. This is where Microsoft differs from companies like Google where they send feedback over to a separate hiring committee that will make the hiring decision. At Microsoft, the team that you are applying for does both, conduct the interviews and make the hiring decision. Typically, you need an overwhelming majority to recommend a Hire for an offer to be extended, which is 5 out of 5 interviewers recommending a hire, or at least 4 out of 5. The decision is then sent over to HR and recruiting who will start preparing your offer package and go from there. You will usually hear back within a week. If you are a fresh graduate or applying for an internship, you may even hear back the same day!

So you got an offer — what next?

Congrats! Pat yourself in the back. Go have a beer or something! From here on, it is mostly smooth sailing. This is where you discuss the terms of your compensation that includes your base salary, a sign on bonus, and company stocks, your benefits, your relocation package and your start date. The compensation in your offer looks something like: $150K base salary, $50K sign on bonus cash and $100K company stocks vesting over 4 years. This is just an example obviously. The actual offer varies wildly between people and is based around your performance, experience, team’s budget, competition and demand in the market, etc. It is not very common, but you may also get an offer for a slightly lower position than what you had applied for. For example, you may have applied for a senior role but you get offered a Software Engineer II offer. This typically happens when you didn’t do well enough for a senior position, but did very good for a level II. If this happens to you, don't take it as a bad thing — it just means that the team that is interviewing you knows what it takes for you to succeed, and they feel that you need a little bit more development as a level II before you hit Senior. If you are okay with that, take the offer, work hard and show progress and in no time, you will hit the position that you initially wanted.

Unfortunately you got rejected — what now?

If you didn't get the offer, please don't let your chin drop. Sometimes it is just bad luck. You could be very close and barely missed out. Keep at it! That being said, there is usually a cool-off period of 6 months to a year before you can re-apply, but do try again. Don’t give up. You will be surprised how many people make it in their 2nd or 3rd attempt. I’ll share my own personal story. When I graduated college, I applied to 57 companies, and did not hear back from a single one. Forget interviews, forget rejection. I didn't even hear back! Had big dreams of working at a top company and all that, eventually had to get a job at Geek Squad at Best Buy to pay the rent. But, I met some amazing people there, some of whom are still my friends. So, it wasn't all that bad! After masters, I applied to 40 companies, heard back from only 6 companies and interviewed with them, Got an offer from only one. After working there, I applied to Amazon and Microsoft, interviewed at both and accepted the offer from Microsoft. And now, I have interviewed candidates at Microsoft for more than 5 years, and am writing this post about how to do well on interviews. From hearing back from 0 out of 57 companies to being able to give advice on interviewing, the point I am making is that you get better at it each time you do it. And trust me, it is doable. If I can do it, you can, too! Just don't give up. Grit and relentless drive will take you a long way in life, not just interviews. And by the way, I still have my original Excel sheet of those 57 companies. I keep it around for motivation :)

Conclusion

I hope this gave you a good overview of Microsoft’s technical interview process, what interviewers are generally looking for, and some tips on succeeding at these interviews. I am sorry I couldn’t go in depth about every little detail to keep this as an overview to get your started and to keep this post short. But, if you want a more detailed information on any of the topics I discussed today, please let me know in the comments below and I will try to make the ones that are most requested.

Also, if you have questions for me that pertains to your personal situation that you don’t feel comfortable posting publicly, please feel free to message me on Instagram at @utsavized. That's the best place to get a response from me, not LinkedIn. And if you are interested in other software engineering and productivity content, please check out my other posts.

Until next time, peace!