Greedy and Beam Sentence Decoding
Reported by candidates from Microsoft's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The data structure that carries this one is a bounded pool of hypotheses, basically a priority queue you re-sort every step. Microsoft reported this decoding question in September 2026, and it looks scarier than it is. You're simulating greedy decoding and beam search over a tiny token table, then returning sentences with exact fractions. Nothing exotic. The pain is in the tie-break rules and the finished-hypothesis handling. If you blank on the details mid-assessment, StealthCoder runs invisibly on your desktop and can hand you the structure in real time. Read the spec twice before you type anything.
The problem
Implement greedy decoding and beam search for a finite next-token probability model. Return the generated sentences and their raw probabilities. The distinct strings in tokens form the vocabulary. The last string is <eos>. For this exercise, percentages[i][j] / 100 is the probability of generating token j when the previous token is i; each row sums to 100. The initial context is token startToken, which is not included in the returned sentence. Stopping and sentence probabilities A generated <eos> ends that hypothesis. Include its transition probability in the product, but omit it from the sentence. Generate at most maxTokens transitions, including a possible <eos>. At the cutoff, return remaining unfinished hypotheses without appending an artificial ending token. Join emitted ordinary tokens with one space. Immediate termination produces the empty string. Write each raw probability as a reduced positive fraction numerator/denominator, including 1/1. Do not renormalize probabilities over the retained beam. Two decoding strategies Greedy decoding chooses the highest-probability next token at each step. Break ties by token text, treating <eos> as the empty string, which precedes every ordinary token. Beam search starts with one empty hypothesis of probability 1. At each step, expand every unfinished hypothesis through every positive-probability next token and carry every finished hypothesis unchanged. Keep at most beamWidth hypotheses from this combined pool, ordered by descending raw probability and then ascending sentence text. Finished hypotheses occupy beam slots and are never expanded again. Stop beam search when every survivor is finished or the transition cutoff is reached. Keep distinct sentences even when their last token matches. Return a two-dimensional string array. Row 0 is [greedySentence, greedyProbability]. The remaining rows are the final beam's [sentence, probability] pairs in the stated order. The same sentence may appear in the greedy row and a beam row. Interview follow-ups Discuss how to reduce the time and space used to select the next beam. Explain why raw probability can favor short sentences, and how a length-aware scoring rule could change that preference. The judged output uses raw probabilities; a weighted scoring formula was not specified in the report. The report also discusses top-k and top-p sampling conceptually, while the implemented task is greedy and beam decoding. Function decodeSentences(tokens: String[], percentages: int[][], startToken: int, maxTokens: int, beamWidth: int) → String[][] Examples Example 1 tokens = ["start","a","b","<eos>"] percentages = [[0,60,40,0],[0,0,50,50],[0,0,0,100],[0,0,0,100]] startToken = 0 maxTokens = 3 beamWidth = 2 return = [["a","3/10"],["b","2/5"],["a","3/10"]] Greedy chooses a, then <eos> on the tie, with probability 3/10. Beam keeps b with probability 2/5 and a with probability 3/10. Example 2 tokens = ["seed","pear","apple","<eos>"] percentages = [[0,50,50,0],[0,0,0,100],[0,0,0,100],[0,0,0,100]] startToken = 0 maxTokens = 2 beamWidth = 2 return = [["apple","1/2"],["apple","1/2"],["pear","1/2"]] Equal probabilities use sentence order, so apple precedes pear even though its vocabulary index is larger. Each probability is 1/2. Example 3 tokens = ["seed","go","<eos>"] percentages = [[0,100,0],[50,50,0],[0,0,100]] startToken = 0 maxTokens = 2 beamWidth = 3 return = [["go go","1/2"],["go go","1/2"],["go seed","1/2"]] No hypothesis emits <eos> before the two-transition cutoff. Both remaining sentences have probability 1/2; greedy follows the lexical tie to go go. Constraints 2 <= tokens.length <= 12. Ordinary tokens are distinct lowercase English words of length 1..8; the final token is exactly <eos>. percentages is a square matrix with one row and column per token. Entries are integers in 0..100, and each row sums to 100. 0 <= startToken < tokens.length - 1, 1 <= maxTokens <= 8, and 1 <= beamWidth <= 20. The <eos> row is never queried after termination. All probability arithmetic can be represented exactly with signed 64-bit integers under these bounds.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The pattern is greedy for row 0 and a pruned frontier for the beam. Greedy is a loop: pick the max-probability next token, break ties by token text with <eos> as the empty string, stop on <eos> or at maxTokens. Beam is the harder half. Each step, expand only unfinished hypotheses through positive-probability tokens, carry finished ones unchanged, then sort the pool by probability descending and sentence ascending, and cut to beamWidth. Finished hypotheses still take slots. The classic pitfalls: renormalizing after pruning, appending <eos> to the sentence, and comparing probabilities as floats. Keep numerator and denominator as integers (percent products over 100^k), compare by cross-multiplication, and reduce with gcd at the end. Dedupe nothing, since distinct paths can share a sentence. If the tie-break logic gets tangled live, StealthCoder is the hedge.
If this hits your live OA and you blank, StealthCoder solves it in seconds, invisible to the proctor.
You can drill Greedy and Beam Sentence Decoding cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Built by an Amazon engineer who would have shipped this the night before his JPMorgan OA if he'd had it.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Microsoft's OA.
Microsoft reuses patterns across OAs. Built by an Amazon engineer who would have shipped this the night before his JPMorgan OA if he'd had it. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Greedy and Beam Sentence Decoding FAQ
How hard is this Microsoft decoding problem really?+
Medium on paper, but it's mostly a simulation with strict rules. There's no clever algorithm. You lose points by missing a detail like finished hypotheses occupying beam slots or the empty-string ordering for <eos>. Careful reading beats cleverness here.
What's the trick to getting the probabilities exactly right?+
Don't use floats. Track each probability as an integer numerator over 100 raised to the number of transitions, multiply percentages as you extend, and compare by cross-multiplying. Reduce with gcd only when formatting output. Print 1/1 for a probability of one.
How should I order and prune the beam?+
Build the combined pool of expanded unfinished hypotheses plus unchanged finished ones. Sort by probability descending, then sentence text ascending, and keep the first beamWidth. Don't renormalize. Stop early if every survivor is finished or the maxTokens cutoff is hit.
What happens at the maxTokens cutoff?+
You return unfinished hypotheses as they are, with no artificial ending token. Each transition counts toward the limit, including a generated <eos>. Example 3 shows this: two transitions, no <eos> emitted, and both sentences are returned with their raw probabilities.
How do I prepare for this in 48 hours?+
Hand-trace the three given examples until your code matches them exactly. Then write the tie-break comparator and the fraction handling as small helpers. Practice explaining the follow-ups: why raw probability favors short sentences and how length normalization would change the ranking.