As other postings on this site have indicated, the standard hiring process for engineering roles typically involves one technical phone screen, followed by a full day of on-site interviews if the phone screen is successful. This was my second interview with Microsoft. In 2008, I interviewed for an SDET position and received an offer, which I gratefully accepted. I voluntarily left the company two years later because I did not enjoy my work as an SDET. Contrary to what recruiters may say, it is quite difficult to move internally within the company. I've found it's actually much easier to leave and then return on your own terms, which is essentially how I did it. A key piece of advice here: ensure you have a stellar performance record before leaving, as they retain this information and will review it upon your return. This was a bridge I made absolutely sure not to burn on my way out.

I was contacted by a Microsoft recruiter about an SDE position. I had an initial phone interview with someone who was quite personable. He asked many questions about my resume, and we discussed one particular personal side project in great detail for about 45 minutes. The questions didn't feel like an interrogation; rather, he seemed genuinely interested and engaged in my work.

He then asked some basic work-related questions about how the file system at my current company operates. Next, we did some coding in a shared document, which was not difficult. He asked me to insert a node into a binary search tree (BST) and then balance it. In total, I wrote the code to insert a node, get the current balance of the tree, determine the height of any node, and the rotate_left and rotate_right functions needed to restore balance. It was approximately 120 lines of code, written in the C programming language. The bottom line in any interview is that if it's on your resume, it's fair game.

Then, I was brought on campus for a full round of interviews. They scheduled me to speak with four different people, with an itinerary provided upon my arrival in the lobby. What they don't explicitly state is that each interviewer acts as a gatekeeper to the next. If you don't perform well at any point, it's "game over." Conversely, if you do well, you'll likely complete the entire schedule and may even have two to three additional bonus interviews. I arrived around 9:30 AM and left sometime after 5 PM. Keep in mind this doesn't guarantee an offer, but if you're asked to leave before completing your scheduled interviews, it's likely a bad sign.

I went into the interviews fully prepared, but I didn't feel as thoroughly (technically) grilled as I might have expected. I was asked many design questions, primarily concerning locking, thread synchronization, scheduling, data compression, and file system snapshot operations. Overall, I had no trouble with any of the questions, and the interviews felt more like conversations about my passions. I had expected to write more code than was requested, and I was certainly prepared for it. Each interviewer makes recommendations to the next regarding areas to focus on, attempting to uncover weaknesses, and will also suggest areas to skip if your skill level in a particular area is already known to be strong. They continuously probe in different areas throughout the day, scanning for weaknesses. If you demonstrate strength in an area, my observation is they adjust their approach rather than continuing to present easy problems. I handled the first couple of coding problems easily, which I believe prompted them to shift to a more holistic approach, wanting to assess if I could see the "big picture." At one point, I even requested another coding problem, but was politely declined. I then offered to provide one myself, which was also denied, lol.

My day concluded between 5 PM and 6 PM. I can't recall the exact time (perhaps 5:30 PM), but it was dark and cold outside. Having gone through this twice now, the best piece of advice I can offer is to get plenty of sleep the night before rather than cramming. Studying the night before won't save you. Regardless of the technical difficulty, this process can be quite nerve-racking. It takes an emotional toll, and by the end, I was exhausted.

They contacted me three days later to say they wanted to move forward with an offer.

Design a scheduler to run many functions at different times. It needs to be thread-safe. Each task scheduled to run will have a timestamp, containing a desired execution time, and a function pointer containing the desired function. Also, find a way to supply the arguments to each function. Implement the mechanisms for scheduling and removing work to be done. How would you handle functions that must be serialized as opposed to ones that didn't need to be?