Microsoft Sde2 - Microsoft | Interview Experiences

Summary

I recently interviewed for an SDE-2 role at Microsoft, navigating four rounds covering Data Structures and Algorithms, Low-Level Design, High-Level Design, and a final Architecture/Behavioral discussion. I successfully cleared all rounds, receiving 'Hire' verdicts, and ultimately secured an offer.

Full Experience

I applied for the SDE-2 role at Microsoft via a referral through their career portal. A recruiter reached out within a couple of days, and all my interviews were scheduled on the same day.

Round - 1: Data Structures & Algorithms

In this round, I was asked to design a data structure with two methods: save(int num) to store data and best() to return the most frequent number, removing it afterward. A key constraint was that if there was a tie in frequency, I had to return the last entered number among the tied elements. I initially solved this using a combination of a doubly linked list and maps. Later, I realized there was an even better approach that could be achieved using only maps. The verdict for this round was 'Selected (Hire)'.

Round - 2: Low-Level Design

This round focused on Low-Level Design, and the problem was to design the classic Snake and Ladder game. I had to explain my design thoroughly and managed to implement about 95% of the code during the interview. Although I couldn't complete all the code, I had a productive discussion with the interviewer, and she seemed pleased with my approach. I received a 'Selected (Lean Hire/Hire)' verdict for this round.

Round - 3: High-Level Design

The third round was a High-Level Design discussion, but the question felt more inclined towards Low-Level Design: designing a Residential Elevator Control System for a single shaft serving Ground + 10 floors. I initially felt a bit confused because of this, but I proceeded to approach it from an LLD perspective. I wrote some code and engaged in a detailed discussion about the trade-offs of my design with the interviewer. Surprisingly, despite my initial confusion and treating it more like an LLD problem, I received a 'Selected (Lean Hire)' verdict for this round.

Round - 4: AA Round (Architecture/Appraisal)

This final round was conducted by a very senior person. The discussion primarily revolved around my past experience and resume. The interviewer delved into the most complex problem I had solved previously, asking about its challenges. Following this, I was asked to implement the stoi function in C++. I had a comprehensive discussion about various edge cases and successfully wrote the code. This round also ended with a 'Selected (Hire)' verdict.

Overall, I cleared all rounds and secured an offer from Microsoft.

Interview Questions (4)

Design Data Structure with Most Frequent & Last Entered Retrieval

Data Structures & Algorithms

Choose a Data Structure and define two methods:

save(int num): store the data (e.g., 2, 5, 8, 2, 8, 9, 2)
best(): Return the most frequent number and removes it. If there is a tie, return the last entered number among the tied elements.

Example: eq, best() -> 2, best() -> 8, best() -> 2, best() -> 9

Design Snake and Ladder Game

System Design

Design the Snake and Ladder game. I had to explain the design and implement 95% of the code.

Design Residential Elevator Control System

System Design

You are to design the software system for a single-shaft residential elevator serving Ground + 10 floors (floors 0 to 10). The system should simulate and control elevator operations — handling user inputs, elevator movement, and display updates — while satisfying the functional, behavioral, and safety requirements described below.

System Context

Each floor and the elevator car have the following:
At Each Floor
Buttons:

Up button – requests the elevator for an upward journey.
Down button – requests the elevator for a downward journey.
Ground floor (0): Down button is disabled.
Top floor (10): Up button is disabled.

Display:

Shows the current elevator position (floor number) and its state: UP, DOWN, or STOPPED.

Inside the Elevator Car
Buttons:

One per floor (0–10) to select a destination.

Display:

Indicates current floor and movement state (UP, DOWN, STOPPED).

Expected Functional Behavior

Startup & Idle State

Elevator starts at Ground floor (0) in the STOPPED state, waiting for a request.

Request Handling

Requests can originate from floors (Up/Down buttons) or from inside the elevator (car buttons).
The elevator must eventually serve all valid requests; none should be lost or ignored.

Movement Rules

The elevator moves between floors and stops as required to serve requests.
It must minimize unnecessary movement, trying to serve requests in an efficient sequence.
Once moving in one direction, it should normally continue in that direction until no further requests remain that are compatible with its direction.

Physical constraint: the elevator needs at least two floors of deceleration distance to come to a halt, so it cannot instantly stop at the very next floor once moving at full speed.

Display Behavior

All displays (inside and outside) should be updated in near real time to show:
Current floor position.
Current movement state.

Optimization Goals

Reduce total passenger wait time.
Reduce unnecessary motion (energy/resource efficiency).
Ensure fairness – no request should be starved indefinitely.

Safety and Reliability Requirements

The elevator must not move while doors are open.
It must never move beyond floor 0 or floor 10.
The system must allow for emergency stop handling at any point.
If a sensor or signal fault occurs, the system should transition to a safe halted state rather than continue unpredictably.
The elevator should resume a consistent and safe state after restart (e.g., following a power failure).

Optional/Extension: Maintenance & Serviceability

Design provisions for servicing and diagnostics:
Maintenance Mode
When enabled:

Reject new passenger requests.
Complete current trip safely.
Move to the nearest floor, open doors, and remain idle until maintenance completion.

Diagnostics
Track and report:

Fault or safety events.
Emergency stops or overloads.
Unusual delays or missed commands.
Remote or Manual Control (Optional Bonus)
Expose a conceptual interface for maintenance personnel to monitor or manually control the elevator’s operations.

Assumptions

Single elevator, single shaft.
Requests and internal logic handled in software only (no actual hardware integration).
Timing and motion may be simulated logically (e.g., 1 floor = 1 unit time).

Implement stoi Function