Skip to content

Microsoft Interview Guide

Microsoft’s loops are the most collaborative of the big five. Interviewers routinely work the problem with you, offer hints early, and treat a hint taken well as a positive signal rather than a deduction. Candidates coming from a Google-shaped mental model often over-perform the stoic lone-genius act and score worse for it.

The bar leans toward clean, production-shaped code rather than exotic algorithms: sensible names, handled edge cases, a function you would be willing to review. Expect mediums, expect to be asked about testing, and expect the conversation to matter.

The most conversational of the big five, and the most likely to care about code quality rather than just correctness. Expect discussion of edge cases, naming and testability.

The loop

Recruiter + technical screen 1× · 60 min One medium, often with a design flavour
Onsite 3-4× · 60 min Coding plus practical design and past-project depth
As-appropriate ("AA") round 1× · 60 min Senior interviewer, broad and decisive

The bar

Write code you would submit in a pull request: named variables, guarded edges, and a stated test plan. "How would you test this?" is asked far more often here than elsewhere.

What they lean on

This is the durable part. Which pattern families a company favours is far more stable than which individual problems it uses, so prepare in this order:

  1. linked-lists
  2. binary-trees-and-bst
  3. strings
  4. design-with-stacks-and-queues
  5. matrix-and-grid-manipulation
  6. one-dimensional-dp

Quirks worth knowing

  • Expect to be asked to walk your own code through a test case line by line.
  • Real-world framing is common ("this array is a log of requests"), so restate the problem in plain terms first.
  • Deep questions about your own past projects are standard. Have one project you can defend at architecture level.

Reported problems

24 problems
7 easy16 medium1 hard
  • Refusing hints. A hint accepted and built on is a positive signal here. Silently struggling for ten minutes is not.
  • Writing contest-style code. Single-letter names and no edge-case handling read badly when the bar is “would I approve this pull request?”
  • Not asking about testing. Offer the test categories unprompted — it is closer to the day job than the algorithm is, and it is explicitly valued.
  • Treating it as easier because it is friendlier. The collaboration is genuine; the bar is not lower. Clean beats clever, and clean is harder to fake.
They askWhat they’re checkingThe answer
“Would you like a hint?”Whether you collaborateYes — and say what you were stuck on first. Naming the stuck point turns the hint into a dialogue rather than a rescue.
“How would you test this?”Engineering instinctCategories rather than examples: empty, one element, duplicates, maximum size, and the specific boundary the algorithm pivots on.
“What would you extract if this were production code?”Whether you know interview code is not production codeInput validation, a named helper for the core transform, magic numbers as constants — while saying you deliberately skipped them for the 45-minute version.
“Can you make this more readable?”That clean is the actual barTake it seriously: extract the condition into a named predicate, split the loop body, rename i/j to what they index.
  • Collaborative by design. Hints are offered early and taking one well is a positive signal.
  • The bar is clean, reviewable code — names, edge cases, a function you would approve. Clean beats clever.
  • Offer the test categories unprompted. It is explicitly valued and closest to the day job.
  • Friendly is not easier. Say what you are stuck on rather than going quiet.
  • Know what you would extract for production — and say you skipped it on purpose.

pch.coffeeTagline

pch.coffeeCta

pch.feedbackHeading

pch.feedbackSubheading