HackTheRounds Interview Experiences

Microsoft OA Interview Experience (2026) - Alloy Production, Max Team Size, Dominating XOR & MEX, Offer

Microsoft 2026 New Grad HackerRank OA pool: binary search on alloy units, interval overlap max team size, MSB bucket dominating XOR pairs, and MEX greedy with f

By Anonymous ยท 2026-04-10

Background

Microsoft's 2026 New Grad OA had been the one I was most nervous about on my shortlist, mainly because the prep posts this cycle kept describing the difficulty as "Medium-Hard with engineering-detail traps" rather than pure algorithm puzzles. I am a final-year CS student in North America with a backend-leaning internship at a logistics company and a referral from a full-time Microsoft engineer in the Azure Data org. I applied in late March, got the HackerRank OA link six days later, and walked out of the session with 2 of 2 problems passing on all visible tests plus a decent shot at the hidden set. Recruiter followed up eight business days later with a VO invite. This post covers what actually showed up and the patterns to study.

Timeline

Online Assessment (90 min, HackerRank)

Two problems in my draw, which matches the 2026 format people are reporting. Historically Microsoft OA ran four problems on CodeSignal, but the New Grad pipeline this year is explicitly 2 problems on HackerRank with a 75-90 minute window depending on region. The difficulty is genuinely Medium to Medium-Hard, the grader cares about performance on large inputs, and partial credit is given per hidden test. My session had problems drawn from what the community is calling the "high-frequency four": alloy production, max team size, dominating XOR, and maximum MEX. I'll walk through all four even though I only got two, because the pool rotates and you should prep for all of them.

Problem 1: Maximum Alloy Production

Problem: A foundry produces an alloy that requires composition[i] units of metal i per unit of output. You start with stock[i] units already in inventory and can buy more of metal i at cost[i] per unit. Given a total budget , return the maximum number of alloy units you can manufacture.

The key insight is that feasibility is monotonic in the number of units: if you can afford k units you can afford k - 1 . That unlocks binary search on the answer. The search range runs from zero to an upper bound derived from the budget plus stock divided by the cheapest per-unit composition. For each candidate production target inside the search, compute the extra demand per metal, multiply by its cost, and short-circuit as soon as the running total exceeds the budget. Total work is logarithmic in the answer bound times linear in the number of metals.

The trap the prompt sets up is the temptation to write a greedy purchase loop. That falls apart because partial production of one unit still requires all metals at once, so you cannot simply buy whichever metal is cheapest first. Binary search sidesteps the ordering problem entirely.

Problem 2: Maximum Team Size

Problem: You have n employees, each with a start and end time representing their shift. Two employees can interact only if their shifts overlap. A valid team must contain at least one employee who overlaps with every other member of the team. Return the size of the largest valid team.

The cleanest framing is: for each employee treat their interval, and ask what is the largest set of intervals that share a common point with at least one "central" employee. Equivalently, for each candidate center, count how many other intervals overlap with its interval. The brute force is quadratic and fails at n = 2 10^5 .

The trick is to realize the "central" employee is whoever has the shortest interval span within the largest cluster, because any two intervals that both overlap the shortest must share its entire span. Sort by end time, sweep with a pointer, and for each interval count how many currently-active intervals it overlaps. Maintain active intervals in a min-heap keyed on end time and pop as the sweep pointer advances. That yields n log n .

There is a simpler almost-correct approach that treats the problem as classic "max concurrent events," which is wrong because classic concurrency does not require a universal overlapper. Catch the distinction before you code.

Problem 3: Dominating XOR Pairs

Problem: Given an array of n positive integers, count unordered pairs (i, j) with i < j such that arr[i] XOR arr[j] arr[i] AND arr[j] .

The bit-trick insight: XOR exceeds AND exactly when the two numbers differ in their highest set bit. In other words, pair arr[i] and arr[j] contribute if and only if their most-significant-bit positions are different. So bucket all values by MSB position, then count cross-bucket pairs. Sum cnt[b] (sum of cnt[b'] for b' < b) across all MSB positions.

That reduces the problem from quadratic to linear in n times logarithmic in the value range. The MSB per value is a single bit-length call. Watch for zero values in the input, which have no MSB and cannot participate in any dominating pair.

Practice it: no exact match in the current Microsoft set, so I did not link this one.

Problem 4: Maximum Possible MEX

Problem: Given an array of n non-negative integers, you may subtract any positive amount from any element any number of times, but not below zero. Return the maximum possible MEX of the resulting array. MEX is the smallest non-negative integer missing from the array.

Greedy with a frequency map. Sort the array and sweep a target value starting at zero. For each position, if any remaining element is at least the current target, consume it and increment the target. Because we can freely decrement, any value greater than or equal to the target can cover that slot. The answer is the value of the target after you run out of elements to assign.

A subtle point is that repeated values of zero still consume a slot each but always map to the same MEX floor, so the answer maxes out at the count of distinct "reachable" slot values. This is linear after sorting.

Practice it: no exact match in the current Microsoft set, so I did not link this one.

Result

Passed both of my assigned problems (alloy production and max team size) with full visible and hidden credit according to the recruiter's follow-up. VO invite came eight business days later, and after the standard Microsoft onsite loop I got the offer for an Azure team role. The OA was the single biggest stress point in the whole pipeline.

Tips

  1. Binary search on the answer is the single most reused pattern in Microsoft OAs. Alloy production, any "max X such that feasibility predicate holds" prompt, and the classic bookcase-and-budget problem all share the same structure. Drill the template: define the predicate, prove monotonicity, set search bounds, short-circuit the feasibility check.
  2. For interval-overlap problems, read whether the prompt requires a universal overlapper. Microsoft's max team size is deceptively close to max concurrent events but the semantics differ, and the correct algorithm differs. Candidates who conflate the two lose the whole problem.
  3. Bit-level reasoning pays for XOR-versus-AND prompts. The rule "XOR > AND iff MSBs differ" collapses a lot of pair-counting problems into a single bucket sweep. Internalize it.
  4. For MEX problems with "decrement freely" allowed, think greedy-with-slot-assignment. The moment the operation budget is unbounded, sort and match smallest-needed-slot to smallest-viable-element.
  5. Microsoft's HackerRank grader is strict on partial credit. Even if you are running out of time, submit what you have, then iterate. Do not wait for "one clean submission" because the scoring picks your best submission across attempts.
  6. Prep the high-frequency four before the OA, not after. Alloy, team size, dominating XOR, and MEX rotate in almost every Microsoft draw this cycle. Write each out once, get your template solid, and you walk in with muscle memory.