Phantom Code AIPhantom Code AI
FeaturesEarn with UsMy WorkspacePricing
FeaturesEarn with UsMy WorkspacePricing
Home/Interview questions/Microsoft
Microsoft interview prep

Microsoft Interview Questions — What 60, 61, 62, and 63 Candidates Actually Get Asked

Microsoft does not run the rigid, single-format loop you get at Google or Meta. Each round mixes coding with behavioral, the question style shifts noticeably between Azure, M365, Xbox, and Bing org branches, and the level you target — 60 (SDE), 61 (SDE II), 62 (Senior), 63 (Principal track) — changes which signals matter most. This page walks the structure and the real questions asked in each round.

The level system, and why the loop feels different at each band

Microsoft uses an internal level number rather than the T3/T4/T5-style ladder you see at Google. Level 59 is the new-grad SDE entry, 60 is the standard SDE, 61 is SDE II — the band most experienced industry hires land in — 62 is Senior SDE, and 63 begins the Principal track. The same loop format is used across the bands, but the bar moves. At 60, an interviewer may be satisfied with a working brute-force solution and a discussion of the optimization. At 62, they expect the optimized solution first, with the trade-off table volunteered before they ask.

The other variable is the team. Microsoft hires into a specific org — you are not abstracted into a hiring pool the way you are at Google. The Azure compute team will lean on systems-level questions about networking, schedulers, and concurrency. The M365 team leans on collaborative-editing and sync problems. Xbox leans on real-time and graphics-adjacent topics. The shared substrate is what Microsoft calls the “as appropriate” framework — interviewers are coached to evaluate candidates against the role they are being hired into, not against a one-size-fits-all rubric. Practically, this means a strong 60 candidate hired into a research-heavy team will get pushed harder on theory than the same candidate hired into a tooling team.

The cultural overlay across all bands is the “Growth Mindset” framing Satya introduced — “learn it all, not know it all.” This is not a slogan in the loop; it is a measured signal. Behavioral questions about feedback, failure, and learning are scored against it. Candidates who present as flawless tend to land below candidates who narrate a real learning arc.

How a Microsoft interview loop is structured

A standard Microsoft on-site is four to five rounds, each forty-five to sixty minutes. Unlike the strict separation Google enforces between “coding round” and “behavioral round,” most Microsoft rounds are mixed: roughly thirty to forty minutes of coding plus ten to fifteen minutes of behavioral, asked by the same interviewer back-to-back. This means the same person sees both your problem-solving and your self-narration in one sitting, and your scorecard reflects both.

A typical loop looks like this: a phone screen with one coding problem and a few collaboration questions, then on-site rounds one and two are mixed coding and behavioral, round three is a system design (added at level 61 and above), round four is an “as appropriate” round — sometimes a deep-dive on your past projects, sometimes a second system design, sometimes a domain-specific technical conversation depending on the team — and round five is the hiring manager. The hiring manager round is heavily behavioral with a smaller technical component and is the round where team-fit is decided.

The team-matching phase is unique to Microsoft. After you clear the loop, you are not auto-placed; recruiters set up calls with two or three teams that have headcount, and you and the team both pick. This means a strong loop result does not guarantee an offer in the org you wanted, and a weak round on the loop can still be salvaged if a specific team wants you. It is closer to an industry-style placement than a centralized hire.

Coding round — real questions and structured answers

Microsoft tends toward classic CS — arrays, strings, trees, linked lists — rather than the highly contrived DP problems you sometimes see at Meta. Interviewers often pull from a known internal bank, and the bar is “optimal solution, clean code, edge cases handled, complexity stated.”

Q. Reverse a linked list in place — recursive and iterative. Which one would you submit and why?

The iterative version is the safer answer. Walk three pointers — prev, curr, and next — flipping curr.next to prev as you advance. It runs in O(n) time and O(1) auxiliary space, which is what the interviewer is looking for. The recursive version is elegant but pushes n stack frames, which a Microsoft interviewer will probe on: 'What happens if this list has ten million nodes?' Stating the trade-off out loud — 'I'd ship iterative because the recursion blows the stack on long lists' — is the kind of pragmatic reasoning the loop rewards. If they push for recursion anyway, write it cleanly: base case returns the node, recurse on next, then point next.next back at current and null out current.next.

Q. Given a string, find the length of the longest substring without repeating characters.

Sliding window with a hash map of character to last-seen index. Track a left pointer and walk right across the string. When you see a character whose last index is at or after left, jump left to oneAfterLastIndex. Update the answer with right minus left plus one on every step. This is O(n) time and O(min(n, alphabet)) space. Microsoft loves this question because it tests four things in one shot: window invariants, off-by-one discipline on the left jump, choice of data structure, and whether you instinctively reach for a hash map versus an array of size 128 for ASCII. Mention the ASCII optimization at the end — interviewers note it.

Q. You are given a binary tree. Return its level-order traversal as a list of lists, one list per level.

BFS with a queue, but the trick is producing the per-level grouping. After each enqueue cycle, snapshot the queue size at the start of the level — that is exactly how many nodes belong to this level. Pop that many, push their children, and append the popped values to the level list. The common bug is using a single while loop without the size snapshot, which mixes levels together. Time is O(n), space is O(w) where w is the maximum width of the tree. If the interviewer asks for the variant where odd levels are reversed (zigzag traversal), the cleanest mutation is a boolean flag and reversing the level list before appending — do not try to push to a deque from both ends, the bookkeeping gets ugly under pressure.

Q. Implement a function that detects whether a singly linked list contains a cycle, and if so, returns the node where the cycle begins.

Floyd's tortoise and hare. Move slow by one and fast by two until they either meet (cycle exists) or fast hits null (no cycle). To find the entry node, reset one pointer to the head after they meet, then advance both by one — they meet again at the cycle entry. The proof is worth knowing because Microsoft interviewers sometimes ask for it: if the non-cycle prefix has length a and the cycle has length c, the meeting point is a + b inside the cycle, and the math collapses to a equals c minus b modulo c, which is exactly the head-to-entry distance. O(n) time, O(1) space. The hash-set version is O(n) space and is acceptable as a starter, but the follow-up will always be 'can you do it in constant space?'

Q. Given two sorted arrays, merge them into one sorted array in place — assume the first array has enough trailing space to hold both.

Walk both arrays from the back, not the front. Two pointers at the last real element of each array, plus a write pointer at the end of the destination. At each step, copy the larger of the two values into the write slot and decrement the corresponding pointer. When the second array's pointer goes negative you are done — any remaining elements in the first array are already in place. The forward-walking version is the classic mistake: it overwrites unread values in the first array unless you copy the first array off to a temp buffer, which costs O(m) extra space. The reverse walk costs O(1). This shows up at Microsoft because it tests whether you instinctively look for the in-place trick.

Q. Given an array of integers, find all triplets that sum to zero, with no duplicate triplets.

Sort first — sorting is what makes deduplication tractable. Then for each index i, run a two-pointer pass on the subarray to its right looking for a pair that sums to negative nums[i]. Skip i forward whenever nums[i] equals nums[i-1], and inside the two-pointer loop skip the left and right pointers past duplicates after each successful triplet. The full complexity is O(n^2) time, O(1) extra space ignoring the output. The naive triple-loop is O(n^3) and will not pass. The hash-set per-element version is also O(n^2) but uses O(n) extra space and is harder to deduplicate cleanly. Microsoft interviewers care about the deduplication detail — saying 'sort plus two pointers' is half the answer; explaining the three skip conditions is the other half.

Q. Design and implement an LRU cache with O(1) get and put.

Hash map plus doubly linked list. The hash map keys to list nodes; the list orders nodes by recency, with the head as most recent and the tail as least recent. On get, look up the node, splice it out of its current position, and move it to the head. On put, if the key exists, update the value and move to head; if it does not, create a new node at the head and, if size exceeds capacity, evict the tail and remove its key from the map. The reason a doubly linked list is non-negotiable is the splice operation — singly linked lists cannot remove a known node in O(1) without holding the previous pointer. Use a dummy head and dummy tail to avoid null checks in the splice helper. This question is a Microsoft staple at level 62 and above because it forces you to combine two data structures correctly and handle the eviction edge case where you remove the same key you are inserting.

Mixed coding + behavioral — the Microsoft hybrid format

These are the questions that look behavioral on the surface (“how would you?”) but turn into a small technical design conversation under follow-up pressure. They show up in the mixed rounds and let one interviewer probe two signals at once.

Q. How would you design a calendar application — and then, given the constraints we discuss, how would you store recurring events?

Start with the user-visible features so the interviewer knows you have a model in your head: events with title, start, end, attendees, location, recurrence, and reminders; views by day, week, and month; conflict detection. Then narrow when they push you toward storage. The recurrence problem is the meat — you do not store every instance of a daily standup for the next ten years. You store one base event with a recurrence rule (RRULE in iCalendar terms — frequency, interval, count or until, by-day, by-month-day) and an exceptions table for cancellations and edits to specific instances. A query for 'show me this week' expands the rule on read inside the requested window. The follow-up Microsoft tends to ask is 'what if a user edits one instance' — that becomes a row in the exceptions table that overrides the generated instance. The hybrid framing is the point: the interviewer is checking whether you can take a fuzzy product question, pin down a concrete schema, and reason about a real edit-flow under follow-up pressure.

Q. How would you implement a function to validate that a Sudoku board is currently legal — and then, walk me through how you would extend it to a full solver?

Validation is three sets of nine constraints: each row has unique digits one through nine, each column has unique digits, each of the nine three-by-three sub-boxes has unique digits. Walk the eighty-one cells once, hashing into nine row-sets, nine column-sets, and nine box-sets keyed by floor(row/3)*3 + floor(col/3). Any duplicate insertion fails the board. O(1) time and space because the size is fixed. For the solver extension, it becomes backtracking: find the first empty cell, try digits one through nine, check the three constraints incrementally (do not re-validate the whole board each time — keep the three sets live and update them on push and pop), and recurse. If no digit works, backtrack. The interviewer is watching whether you reuse the validation data structures inside the solver instead of rebuilding them — that is the 'as appropriate' insight Microsoft loops weight heavily.

Q. How would you build a feature that auto-saves a document every few seconds without losing the user's work if the network drops?

Two layers. Layer one is local: every change writes to an in-memory buffer with a sequence number, and a debounced flush (say every two seconds of inactivity, or every five seconds maximum) persists the buffer to local storage — IndexedDB on the web, the platform's preference store on desktop. The user never loses work to a tab crash. Layer two is sync: a background worker reads from local storage and POSTs deltas, not full snapshots, to the server. Each delta carries the sequence number; the server acknowledges up-to sequence N, the client trims its local queue. On reconnect, the queue replays in order. The conflict question is the standard follow-up: who wins when two devices edit offline? The pragmatic answer for a single-user document is last-writer-wins on the server clock; for collaborative editing you need operational transforms or CRDTs. Microsoft will probe on the trade-off — name it.

Q. How would you handle rate limiting for an API endpoint — and how does your answer change if the endpoint is hit by a customer's ten-thousand-machine fleet versus a single browser?

Single-browser case: token bucket per user identifier with the bucket sitting in an in-memory store like Redis. A request decrements; if the count goes negative, return 429 with a Retry-After header. Refill at a fixed rate. The fleet case forces a different decomposition. Per-user limits do not help because all ten thousand machines share the same user. You move the limit to the API key plus origin IP, and you accept that strict global synchronization is too slow at high QPS. The realistic implementation is local in-process counters synced asynchronously to a central store, with a small over-shoot tolerance — the alternative is taking a Redis round-trip on every request, which adds latency on the hot path. The Microsoft hybrid framing is to start with the user-visible behavior (what does the customer see when throttled?) and let the implementation fall out of the constraints. They are listening for whether you trade strict correctness for latency at the right point.

Q. How would you design and implement an undo-redo stack for a text editor — and what changes when the editor is collaborative?

Single-user version is two stacks of operations. Every user action pushes onto the undo stack and clears the redo stack. Undo pops from undo, applies the inverse, pushes onto redo. Redo pops from redo, reapplies, pushes back onto undo. Operations carry enough state to invert themselves — a delete carries the deleted text and the position. The collaborative version breaks the simple stack model because remote operations can land between your local actions. You cannot blindly undo your last action if a colleague has since edited the same paragraph. The fix is operational transformation: each user has their own undo stack of operations, and undoing means computing the inverse and transforming it against any concurrent operations that have arrived since. The interviewer is watching whether you recognize that the data structure does not change but the semantics do, and whether you can articulate why naive stack-pop is wrong in the multi-user case.

System design — Microsoft-flavored problems

System design enters the loop at level 61 and is decisive at 62 and 63. Microsoft prompts often map to products the company actually ships — the interviewer has a deep mental model of the real architecture and will probe the parts where naive answers collapse.

Q. Design Outlook — the email client and server, end to end.

Frame the problem first: hundreds of millions of mailboxes, billions of messages per day, sub-second send and receive, full-text search, calendar integration, mobile and desktop clients, offline support. Then partition. The mailbox storage layer is sharded by user ID — each user's mailbox is a contiguous append-only log of message envelopes plus a separate blob store for attachments. The send path goes through SMTP with a queue (one per outbound shard) and DKIM/SPF signing on the way out. The receive path lands in a per-user folder, runs spam and malware classifiers, then writes to the mailbox log and updates a search index built per-user (because search is always scoped to one mailbox). The sync protocol to clients is delta-based: clients keep a sync token, ask the server 'what changed since this token,' and apply the delta. Calendar shares the storage substrate but has its own recurrence-rule expansion logic. The places to dig in if the interviewer pushes — and they will — are: how you handle a user whose mailbox is too big to fit on one shard (split into folders mapped to sub-shards), how attachments get deduplicated across recipients (content-hash addressing in the blob store), and how the search index stays consistent (eventual consistency with a per-user lag budget of a few seconds is acceptable). Microsoft cares about the storage model and the sync protocol — those are the levers.

Q. Design OneDrive sync — the file-system replication that keeps a folder consistent across multiple devices.

The hard part is not 'upload files to a server.' The hard part is conflict detection, partial syncs over flaky networks, and bandwidth efficiency. Each file gets a content hash and a per-file version vector. Clients run a local watcher (FSEvents on Mac, ReadDirectoryChangesW on Windows) that produces a stream of change events. A change is enqueued with the file's hash and a parent version vector. The server accepts changes that fast-forward the version vector and rejects ones that conflict. Conflicts get materialized as a duplicate file with a suffix — '(conflict copy from device X)' — and surfaced in the UI. Bandwidth efficiency means chunking files into fixed or content-defined blocks, hashing each block, and only uploading blocks the server does not already have — this is what makes a one-byte edit in a one-gigabyte file fast. The download path is symmetric: the client asks 'what blocks do I need for this version,' fetches missing blocks, and reassembles. Selective sync is folder-level subscription: the client tells the server 'I only care about these subtrees,' and the server only streams change events for those. The Microsoft-flavored follow-up is almost always around the watcher: what happens when the user is offline for two weeks, the watcher queue is huge, and the server has also moved forward? The answer is a full reconciliation pass — walk the local tree, compute hashes, diff against server state, push and pull as needed.

Q. Design Teams chat — one-to-one and group messaging at large scale, with presence and typing indicators.

Three subsystems. First, message storage: a chat is a partitioned log keyed by chat-ID, with messages appended in order. For one-to-one, the chat-ID is a deterministic hash of the two user IDs sorted; for groups, it is a UUID. Reads are tail-driven — clients fetch the last N messages and subscribe to new ones. Second, the connection layer: persistent WebSocket or long-poll connections from clients to a fleet of edge servers. Each user is mapped to one edge server at a time, looked up via a presence service. When user A sends to user B, the message lands in the chat log, then a fanout worker looks up B's edge server and pushes the message down B's socket. If B is offline, the push is skipped — the next time B connects, the client reads the unread tail from the log. Third, presence and typing: presence is a TTL'd entry in a fast key-value store, refreshed on heartbeat; typing indicators are ephemeral fanouts that do not touch the message log at all because they are not durable. The two scale problems Microsoft will probe are large groups (a 10,000-person Teams channel) — for which you batch-fanout via a per-channel subscription tree rather than naively pushing to 10,000 sockets one at a time — and read-receipts, which need their own append-only structure keyed by (chat-ID, user-ID) to avoid hot-spotting on the message rows.

Behavioral — Growth Mindset and customer obsession

The Microsoft behavioral rubric weighs Growth Mindset, customer obsession, and partner-collaboration heavily. Answers that read as polished hero stories tend to score below answers that show real self-awareness, a concrete behavior change, and a measurable outcome.

Q. Tell me about a time you received feedback that was hard to hear. What did you do with it?

This is a Growth Mindset probe — the most heavily weighted Microsoft cultural attribute. The pattern that lands is: state the feedback specifically (vague feedback in vague answers reads as evasive), describe your initial reaction honestly including any defensiveness, narrate the concrete behavior change you made, and close with the second-order outcome — 'two quarters later, my next review explicitly called out that I had improved on this.' The trap is reciting a hero arc where you immediately accepted the feedback gracefully — interviewers know that is rarely true and read it as polished rather than authentic. The 'learn it all, not know it all' framing is the explicit Microsoft language; you do not have to use that exact phrase, but the answer should embody it. Tie the change back to a measurable improvement.

Q. Describe a time you disagreed with a senior engineer or your manager. How did you handle it?

Microsoft is looking for collaborative disagreement, not heroic dissent. The structure: the disagreement was technical and specific (not a personality clash), you raised it in the appropriate forum (one-on-one or design review, not a group Slack callout), you brought data or a working prototype to the conversation, and you were genuinely open to being wrong. The closer matters most: either you persuaded them and the decision changed, or they persuaded you and you publicly supported the chosen direction. Both endings are fine. The losing answer is one where you 'were right all along' and the project failed because nobody listened — that reads as a teammate problem, which is a hire-no flag. Microsoft is partner-heavy as a culture; they want to see that you can disagree, commit, and move forward without resentment.

Q. Tell me about a project that failed. What did you learn?

Pick a real failure with a real cost — not 'we shipped a week late.' A scoped project that got cancelled, a launch that regressed a metric, an architectural choice that had to be reversed. Walk through what you missed and why you missed it (premise was wrong, stakeholders were not aligned, scope grew past your budget, you over-estimated team velocity). Then, and this is the part candidates skip, describe the structural change you made afterward — a new pre-mortem checklist, a different cadence with the PM, a habit of writing one-page design docs before any work starts. Microsoft's customer obsession value sits behind this question: did the failure teach you something about what users actually needed, versus what your team thought they needed? If yes, name it. The answer is not 'I learned to work harder' — that signals you have not actually reflected.

Q. Give an example of when you had to learn a new technology or domain quickly to ship something.

This is a direct Growth Mindset signal. Pick something where the learning curve was real — a new programming language for a critical-path service, an unfamiliar domain like cryptography or video codecs, an internal Microsoft system you had never touched (Cosmos, Substrate, whatever). Show the learning strategy: who you talked to, what you read, what you built as a learning artifact, how long the ramp took, and what the shipped outcome was. Bonus points for naming the moment you realized you were going to make the deadline — interviewers like specificity that suggests the story is real. The losing version is 'I read the docs and figured it out' — that is what every candidate says. Real answers have a person who helped, a sticking point that was non-obvious, and a shipped thing at the end.

Q. Tell me about a time you used customer feedback or data to change a product or technical decision.

Customer obsession is a Microsoft cultural pillar and shows up in almost every behavioral loop, especially at level 62 and above. The story should go beyond 'we ran a survey and added the top feature.' The strongest answers describe a moment where the customer signal contradicted the team's prior belief — a feature you assumed was loved had low engagement, a bug nobody prioritized was the top support driver, a workflow your PM was sure mattered turned out to be a niche. Then describe the technical or product change: scoping work, deprecating a feature, rebuilding a flow. Close with the metric that moved. The framing the loop wants to hear is that you treat the customer as a real source of truth — not as a vague justification you reach for after the fact.

What separates a hire from a no-hire across the loop

  • Stating complexity before being asked. At Microsoft this is expected on every coding answer — silence reads as not having checked.
  • Narrating trade-offs in the hybrid round. Saying “here are two approaches and here is why I am picking this one for these constraints” is the single move that separates a strong hybrid answer from a generic one.
  • Behavioral specificity. Names, numbers, and dates. A story without a number does not get scored as a story; it gets scored as a position.
  • Active calibration during system design. Microsoft interviewers expect you to ask scoping questions early — daily active users, read-write ratio, latency budget — and to revisit those numbers when you make a partitioning choice.

Practice these on a live Microsoft loop, with PhantomCode

PhantomCode is an interview copilot that listens to your live interview audio and surfaces structured guidance — code outlines for the coding round, prompts for the behavioral STAR structure, and scaffolds for the hybrid “how would you” questions Microsoft asks. It is invisible to the interviewer and works on Teams, Zoom, Meet, and on-site phones.

Try the interview copilotSee other companies

Last reviewed for the 2026 Microsoft interview cycle. Question patterns reflect SDE loops across Azure, M365, Xbox, and Bing org branches and are derived from candidate-reported experience, not from internal Microsoft material.