Math and arithmetic reasoning

What it is

Questions filed under "math" don't share one algorithm; they share the fact that the fast solution comes from a numeric or combinatorial insight rather than from choosing the right data structure. That insight might be a digit-by-digit simulation rule (how carries propagate in addition), a modular-arithmetic identity (when a difference is divisible by k), a halving trick that turns a linear amount of work into a logarithmic amount (repeated squaring), or a counting argument that finds a lower bound the schedule can't beat. What they have in common is that once you see the underlying number fact, the code is short — the difficulty is entirely in spotting the fact.

When it applies

• The brute-force approach is correct but does unnecessary repeated work that a mathematical identity can collapse (computing x^n by multiplying n times, when repeated squaring gets there in log n steps).
• The question is really about a numeric property of the input (divisibility, remainder, parity, digit position) rather than about searching, sorting, or traversing a structure.
• You're asked for a minimum or exact count that can be derived by reasoning about the single most constraining element (the most frequent task, the longest chain) rather than by simulating every step.
• If the "math" is actually about summing over ranges or subarrays, that usually collapses into the prefix-sum pattern instead — the two overlap often enough that a divisibility condition on a subarray sum belongs to both.

Tells in the problem

• "Do it in time logarithmic in n" attached to a power, multiplication, or repeated-operation computation — a hint for halving the exponent instead of iterating it.
• Numbers represented digit-by-digit (as a linked list or string) rather than as a native integer — a hint that you must simulate arithmetic (carries, borrows) by hand.
• "Sum is a multiple of k" or any other divisibility phrasing on a derived quantity — a hint to reason in remainders (mod k) rather than raw values.
• "Minimum total time/units" where a resource (a CPU, a slot) can sit idle, and one repeated element clearly forces the lower bound — a hint for a formula built from the most frequent item's count and gaps, verified rather than simulated.
• Constraints mentioning a specific bit width or integer range (e.g. 32-bit) as part of the story, not just as an input bound — usually a hint about overflow behavior being part of the question.

The classic mistake

The mistake interviewers report most is reaching for simulation (looping n times, walking every unit of time, generating every subarray) when a closed-form or logarithmic shortcut exists, and only realizing the approach is too slow once the stated bounds (n up to 2^31, arrays of hundreds of thousands of elements) are taken seriously. This happens because simulation is always "obviously correct," so it's tempting to start there and hope it's fast enough — but math-pattern questions are specifically chosen because the naive simulation's complexity doesn't survive the given constraints. The habit that catches this: before coding, multiply out the brute-force complexity against the stated bounds and say the number out loud ("that's on the order of two billion multiplications") — if it sounds too slow, that's the signal to look for the underlying numeric identity instead.

Questions to start with

• Add Two Numbers — digit-by-digit simulation with carries, the most literal "do the arithmetic by hand" version of this pattern.
• Pow(x, n) — the canonical halving trick: repeated squaring turns O(n) multiplications into O(log n).
• Continuous Subarray Sum — reframes a subarray-sum question as a statement about remainders modulo k.
• Task Scheduler — a counting argument: the most frequent task alone determines a lower bound on the schedule length, which you then verify is achievable.