Microsoft

I applied for the Microsoft Software Engineering Intern role off campus and was shortlisted for the online assessment after the resume screening. The OA had two coding problems, both around the medium-to-hard range. I managed to solve both, but I still spent a good amount of time checking edge cases because the problems were the kind where a solution could look correct while failing on a few hidden cases. After clearing the assessment, I received the interview invitation. The first technical interview started with a quick introduction and then moved straight into DSA. The first problem was reversing a linked list. Instead of immediately writing the standard iterative solution, I explained both the iterative and recursive approaches and compared their space complexities. The interviewer then asked a follow-up about how I would handle the problem if the list had certain constraints. The next question was based on the Open the Lock problem. I recognized BFS fairly quickly because every combination represented a state and each move had the same cost. I explained the brute-force idea first and then moved toward BFS with a visited set. The interviewer asked me to discuss how I would avoid processing the same state repeatedly and what the complexity would be. We then discussed tree traversals. I was asked when I would prefer BFS over DFS and how I would modify a traversal depending on the condition being checked. The round ended with a more involved problem combining backtracking and BFS. I was able to derive the approach and implement most of it, although I needed to spend some time debugging an edge case. A similar off-campus candidate report describes this combination of linked lists, Open the Lock, tree traversal and a backtracking/BFS problem. I cleared the first interview and went into the second round with considerably more confidence. This round began with a discussion about one of my projects. I had to explain the architecture, why I selected the technologies I used, and how I would change the design if the number of users increased. The coding question was the Gas Station problem. Interestingly, the interviewer first asked only for the brute-force approach rather than immediately demanding the optimal greedy solution. I explained the straightforward method, coded it, and discussed its complexity. We then talked about how it could be optimized. I was able to derive the greedy observation and explain why restarting from a particular index was sufficient. The technical performance itself felt decent to me, but I could tell that the second round was more demanding because the interviewer kept testing how I handled follow-ups rather than just checking whether my initial solution worked. Recent reports also describe Microsoft interviewers focusing heavily on explanation, debugging strategy and adaptability to hints. A few days later, my application status changed to rejected. I was disappointed because I had cleared the OA and made it through both technical interviews. The experience nevertheless showed me that for Microsoft, solving the main DSA question is only one part of the evaluation. The ability to optimize, explain trade-offs, handle follow-ups and demonstrate genuine understanding of projects matters throughout the proce