Microsoft | SWE II | Hyderabad | Windows Team

I had my Microsoft Interview today for a SWE II role as part of a Hiring Drive in Hyderabad for the Windows Team. We were scheduled for two interviews, and based on their outcome, they would decide if I would proceed to the other two rounds.

In my opinion, I performed well. However, I didn't receive any calls for further rounds, so I assume I didn't make it past the initial screening.

Round 1: DSA
The problem given was: "Given a File path reduce it to its canonical form."
For example:
Input: /home/foo/bar/./../../app
Output: /home/app
I implemented a solution in Python with O(N) time and space complexity.

Round 2: LLD (Low-Level Design)
The task was to "Design an Alert Monitoring System."
The system should involve machines and various types of sensors (e.g., Temperature, Pressure). Each sensor has a lower and upper threshold. If a sensor's value goes outside this range, an alert should be sent to the alert monitoring system, where a user can then check and change the state of the alert.

I designed the system with the following interfaces and classes:
Interface: Sensor
Classes: TemperatureSensor, PressureSensor, AlertMonitoringSystem, SensorData, Machine, Alert
Enum: AlertStatus

My implementation approach was for the sensor to hold a reference to the AlertMonitoringSystem. Sensors would periodically push their data to a queue. The AlertMonitoringSystem would then process this data from the queue, and if any value was outside its threshold, an alert object would be created.

Opinion on Round 2:
I don't think the interviewer was entirely happy with my design. Based on our discussion, I believe they expected the AlertMonitoringSystem to actively poll or go through all sensors to check their data, rather than sensors pushing data to a queue. I explained that in my experience with monitoring tools and projects, data is typically sent to a queue, from which the system reads and performs necessary actions.

The interviewer also asked if the "View" where a user would see alerts should be a separate class. I argued that it might not be strictly necessary unless there are multiple monitoring systems, as the view would just call methods within the AlertMonitoringSystem class. I suspect my answer didn't impress them, as I generally consider the frontend (view) to interact via backend APIs and thus don't typically include "View" classes in a low-level backend design.

Finally, the interviewer mentioned that I didn't show the flow and object creation (like a "Runner" class). However, at the beginning of the interview, they specifically stated they were only interested in the interfaces, classes, and their arrangement.

My 2 Cents (Reflections):
1. I felt the interviewer might have had a bias towards their own solution in the LLD round. In low-level design, multiple valid approaches can exist, and an interviewer should ideally be open to different solutions. If there are issues with a candidate's solution, they should be justified with examples or by extending the question rather than expecting a specific design based on unstated assumptions.
2. Regarding the recruitment process, I experienced a complete lack of respect for my time. Recruiters did not provide times for potential Round 3 and 4, were unreachable, and didn't reply to emails. It's crucial to inform candidates promptly if they are rejected so they can plan accordingly, rather than leaving them waiting. Many recruiters seem to be partner employees who may lack relevant experience or understanding of a considerate recruitment process.

I have other interviews scheduled for different teams at Microsoft, so I will see how those go.