My Microsoft interview experience was honestly a mix of excitement, nervousness, and a lot of learning. Before the interview, I had prepared quite a lot of DSA, especially arrays, strings, trees, graphs, dynamic programming, and some commonly asked interview patterns. Still, when the actual interview started, I was nervous because I knew that knowing the solution and explaining it under pressure are two completely different things.

The interview started with a brief introduction. The interviewer asked me about my background, my projects, and some of the things I had worked on. I was asked a few questions about one of my projects, and the interviewer kept going deeper into my answers. This made me realize that I shouldn't mention anything on my resume that I don't understand properly. After that, we moved to coding. I was given a problem and initially I started thinking about the brute-force approach. I explained my thought process instead of immediately jumping into the code. The interviewer then asked me whether I could optimize it. This was probably the most challenging part for me. I had to think while explaining my approach, and at some points I wasn't completely sure whether I was going in the right direction. I tried different approaches, discussed their time and space complexities, and eventually arrived at a better solution.

While coding, I was asked questions like why I was choosing a particular data structure, what would happen in certain edge cases, and whether my solution could be optimized further. I also had to dry-run my code with a few examples. What I found interesting was that the interviewer wasn't only checking whether I could write correct code. They were more interested in how I approached the problem and how I reacted when my first approach wasn't optimal. There were also questions related to my technical fundamentals and projects. I was asked about concepts that I had mentioned in my resume, so I had to explain not just what I had used but also why I had used it and what alternatives were available.

The behavioral part was comparatively comfortable for me. I was asked about situations where I had faced challenges while working on a project, how I handled disagreements, and how I dealt with failure or feedback.

Overall, the experience taught me that preparing for an interview is not just about solving hundreds of questions. I need to be able to think clearly, communicate my reasoning, explain my code, and stay calm when I'm stuck. Even though I was nervous initially, the interview became more comfortable as I started interacting with the interviewer. My biggest takeaway was that it's completely okay not to know the answer immediately. What matters is how I break the problem down and how I work toward the solution. If I had to give one piece of advice to someone preparing for a Microsoft interview, I would say: don't just practice solving problems—practice explaining them out loud. That's what made the biggest difference for me.

One thing they asked me was a coding question based on arrays and hashing. They gave me an array and asked me to find the longest subarray satisfying a particular condition. I first explained the brute-force approach, and then the interviewer asked me to optimize it. What made it challenging was the follow-up questions about time complexity, edge cases, and why I chose a particular data structure.