Microsoft Technical interview is the core of the Microsoft recruitment process for technical roles. It comes after the screening and Codility test and usually consists of three to four rounds, one hour each. These days, Microsoft technical interview is done virtually.
Instead of trying to repeat what is already available online, I’ve tried to offer some insight from other applicants, as well as provide some amazing resources where you can practice these questions to prepare.
First things first, some of the best resources to practice for Microsoft technical interview:
- Microsoft LeetCode Problems
- Leetcode Top 100 Problem Selection
- Leetcode questions, categorized by topic
- Geekforgeeks Microsoft Preparation
- System Design Primer
- Top FAANG Interview Questions from LeetCode
Remember that you might get a screening test before the actual interview, so these resources will be useful for the Microsoft screening questions as well. Now let’s get on with the tips and what to keep in mind for the Microsoft coding interview.
7 Helpful Tips to Pass the Microsoft Coding Interview
To succeed in a Microsoft technical interview, keep these things in mind:
1. Start practicing on LeetCode
By far the best way to start preparing is to jump straight to practicing the problems on sites like LeetCode, Geeksforgeeks, and others. Take a look at what is mostly asked. These sites have the most asked Microsoft technical questions which you can practice any time.
Do these problems with a timer. You need to be able to solve them within a reasonable timeframe, and you need to be comfortable with easy leetcode problems.
Here’s a link to Practice Microsoft LeetCode Problems, and solve as many as possible to prepare for the interview. Don’t forget to look at the discussion.
By checking what others have written you can see different ways of solving the same problem, as well as explanations that can give you further insights into the problem.
2. Listen to the problems carefully
During the interview, you need to listen carefully and pay attention to what is written. Sounds cliche, but oftentimes people run through it without actually paying attention, and get an incorrect solution.
Ask clarifying questions when needed, and describe the question/solution out loud so the interviewer can hear how you think. You can start with a simple case, and then work towards the solution, or any way that seems best for you.
Practice this during your leetcode session, so you can be prepared for the interview and do the same thing.
3. Consider not revealing if you’ve seen the problem before
While most interviewers will suggest telling them whether you’ve seen the problem before, in general, you may consider hiding this to increase your chances of passing the interview.
This doesn’t mean being completely oblivious about the problem, especially if it’s something easy, but you don’t want to give a result instantly. A good way to hide this is to act as if you’re thinking for a while. Go step by step how a good programmer would think this through, then solve the problem out loud by following a natural problem-solving process. If you explain the process thoroughly, who cares if you already knew beforehand?
The only time you should consider mentioning this is if you have an ethical dilemma. However, keep in mind that you may be putting yourself at a disadvantage if you decide to do so, as they could potentially give you a much harder problem you can’t solve. In the end, it shouldn’t matter if you knew it beforehand if you can explain the process to solve it, right?
4. Name things clearly in your code
Try to name things clearly in your code. Good code needs to be self-explanatory, and easy to read and understand.
Keep it simple. Your functions or variables should be named by using specific names, which easily describe what the function does. If you can name it so that you can understand what it does without having to dig deep you’ve done it well. Don’t use generic names for your functions.
It’s OK to use longer names if you need to. It’s better to use a longer name that properly describes what a variable does than to use abstract names that can confuse everyone. Keep it simple without being too clever, without naming them something only you will understand.
There are many more good pieces of advice you can follow when naming your code, and here’s a good example from Brandon Quakkelaar.
5. Explain yourself and your code
An important thing in a Microsoft technical interview, as well as any other technical interview out there, is the ability to explain your code and what you’re doing. Every technical interviewer wants to know what you’re thinking as you approach the problem.
Once you hear (or read) the question, run your ideas out loud to your interviewer. Explain to them the approach you’d be using while solving the problem.
If you were told to sort an array of integers into a binary tree, you can probably do it. But if you explain it first, you can increase your chances of passing because if you make a simple error, they’ll know what you are trying to do and mistakes happen.
If you find it difficult to explain out loud, write the comments in your code before they ask. Keep in mind they don’t expect you to solve everything instantaneously. What’s more important is that you show them your thinking is on point, and if you’re young, also that you can learn and grow.
Here’s an approach you can take when solving these problems during the interview. It doesn’t matter if it’s a whiteboard or virtual, it still applies:
6. If you don’t know, start with a brute-force solution
If you can’t solve the problem, remember that even a brute-force solution is better than no solution. While Microsoft interviewers won’t look at this as a correct solution, you can still use your brute-force solution as a first step at the beginning to frame the rest of your answer.
After mentioning or using a brute-force solution, the interviewer will most likely ask you to find a better solution. However, if you don’t know the answer, even doing this will show the interviewer that you can code at least and that you’re thinking about the problem.
As you begin with a low-effort, easy solution, you may get insights into the optimal solution as well. The point here is that starting to solve the problem, and working your way through brute force is still much better than not doing anything.
7. Be able to positively receive feedback on your code
An important thing at Microsoft culturally is being able to receive feedback and learn from that feedback. You need to be able to accept negative feedback and think about how you can improve. This is especially important for junior-level roles because you need to show how you’re willing to grow within Microsoft.
If you need more motivation on how important this is, consider how there are some candidates for Microsoft that can find an optimal solution quickly the same problems you can only brute force.
Showing an interviewer that you have the right approach to the problem, the right mindset, and the will to take criticisms and grow tells them you can become a better and more skilled employee. You can make a bigger impact in this area by doing your behavioral interview well.
If you ever get stuck, just throw a hashmap at the problem.