Read the Codebase, Fix the Bug

Start from brute force

The quickest-looking fix is at the call site: swap the two pops in rpn so a is the top of the stack and b the one below. Two reversals cancel, and all seven hidden tests pass. The evaluator still runs in O(n) time and O(n) stack space, so the cost does not change; what changes is which function is wrong. _apply(op, a, b) still computes b - a, so its contract stays broken: any other caller that passes left then right, or a direct test such as _apply("-", 5, 2), still gets -3. The patch turns the tests green while the bug stays where it lives, and it breaks the rule that rpn must not change.

The approach

Read the contract before the code. In rpn, an operator token pops b first, the top of the stack and the right operand, then pops a, the value pushed earlier and the left operand, and calls _apply(t, a, b). So the call promises _apply(op, left, right). Checking each branch against that promise finds the defect: + and * are commutative and come out right either way, while the stub’s - and / branches return b - a and b / a. The reference changes exactly those two lines to a - b and a / b and leaves _is_op and rpn untouched.

Why this is the right place: after each token, stack holds the values of the complete subexpressions read so far, in left-to-right order, so the value below the top is always the left operand. Confirm with a case where a wrong subtraction feeds another operator, 10 2 3 - *, and with chained subtraction, 20 5 - 3 -, which must give 12. The TypeScript apply gets the same two-line fix.

Walk through an example

The third example, ["10", "2", "3", "-", "*"], shows one reversed subtraction poisoning the multiply that consumes it; the last column is what the buggy stub computes.

Complexity

O(n) time for n tokens: each token is classified once, each operand is pushed once, and each operator does two pops and one push. O(n) space for stack, which peaks when operands come first, as in 1 2 3 + +. The swap-the-pops patch costs exactly the same; it is rejected for correctness, not speed, because _apply stays wrong.

Edge cases to test

• ["20", "5", "-", "3", "-"] → 12.0. Chained subtraction runs left to right, (20 − 5) − 3; the stub returns 18.0.
• ["8", "2", "/"] → 4.0. Division is the second reversed branch; the stub returns 0.25.
• ["3", "4", "+", "2", "*"] → 14.0 on both the fix and the stub. Tests that use only + and * can never catch this bug.
• ["7", "2", "/"] → 3.5. Python’s / is true division; a port that used // or Math.trunc would return 3.
• ["-3", "4", "+"] → 1.0. _is_op compares the whole token, so "-3" is a number; a check on the first character would treat it as an operator.
• ["2", "0", "/"]: Python raises ZeroDivisionError, while the TypeScript version returns Infinity. The input is promised well-formed, but the two languages disagree here.

Common mistakes

• “Fixing” rpn’s pop order instead of _apply — the pop order is right; the arithmetic is wrong.
• Swapping only - and forgetting / (both are non-commutative and both are reversed).
• Assuming addition/multiplication are also broken — they are commutative, so operand order does not matter there.
• Not confirming with a nested case like [10, 2, 3, -, *], where a wrong subtraction order silently poisons the multiply.

Follow-ups an interviewer asks next

How do you prove the fix is in the right function?

Test _apply directly, not only through rpn: assert _apply("-", 5, 2) == 3 and _apply("/", 8, 2) == 4. Both fail on the stub and on the swap-the-pops patch, while every test that goes through rpn passes on that patch. A unit test at the boundary where the contract lives is what separates a real fix from two bugs cancelling out.

Make the evaluator reject malformed input.

Check that the stack holds at least two values before an operator pops, and raise an error naming the token and its position if it does not. At the end, require exactly one value, since leftovers like 1 2 mean an operator is missing. Wrap float(t) so an unknown token such as x reports where it was instead of surfacing a bare ValueError.

Add exponentiation or a unary minus.

Exponentiation is one more non-commutative branch, a ** b, and exactly where the same operand-order bug would reappear. Associativity needs no extra handling, because RPN token order already fixes the grouping. A unary operator such as negation pops one value instead of two, so _is_op has to report an arity and rpn has to pop that many.

Evaluate ordinary infix input like (3 + 4) * 2.

Convert it to RPN first with the shunting-yard algorithm: numbers go straight to the output, operators wait on a stack and move to the output when a new operator has lower precedence, or equal precedence and left associativity, and parentheses bracket the popping. The resulting token list feeds this evaluator unchanged, a common way to keep parsing separate from evaluation.

Where this shows up

This is code comprehension: the bug spans two functions, so you cannot fix it without reading how rpn feeds _apply. That “drop into unfamiliar code, trace the data flow, fix at the source without breaking the rest” skill is exactly what the AI era rewards — and what interview loops have started testing directly, because it is the half of the job AI does not do for you.

Reference solution

def _is_op(t):
    return t in ('+', '-', '*', '/')


def _apply(op, a, b):
    if op == '+':
        return a + b
    if op == '-':
        return a - b
    if op == '*':
        return a * b
    return a / b


def rpn(tokens):
    stack = []
    for t in tokens:
        if _is_op(t):
            b = stack.pop()
            a = stack.pop()
            stack.append(_apply(t, a, b))
        else:
            stack.append(float(t))
    return stack[-1]


print(rpn(['5', '2', '-']))          # -> 3.0
print(rpn(['10', '2', '3', '-', '*']))  # -> -10.0

function isOp(t: string): boolean {
  return t === '+' || t === '-' || t === '*' || t === '/';
}

function apply(op: string, a: number, b: number): number {
  if (op === '+') return a + b;
  if (op === '-') return a - b;
  if (op === '*') return a * b;
  return a / b;
}

function rpn(tokens: string[]): number {
  const stack: number[] = [];
  for (const t of tokens) {
    if (isOp(t)) {
      const b = stack.pop()!;
      const a = stack.pop()!;
      stack.push(apply(t, a, b));
    } else {
      stack.push(parseFloat(t));
    }
  }
  return stack[stack.length - 1];
}

console.log(rpn(['5', '2', '-']));           // -> 3
console.log(rpn(['10', '2', '3', '-', '*'])); // -> -10