Big O Notation Explained (No Math Degree Needed)

Big O notation describes how an algorithm’s running time or memory use grows as its input grows. It throws away constants and incidental details and keeps only the dominant term, so you can compare approaches by their shape — does the work stay flat, grow in a line, or explode?

It is the language interviewers use to ask “is your solution fast enough?”, and it is the difference between code that handles ten items and code that handles ten million. You do not need heavy math — you need to recognise a handful of growth patterns.

The core idea in three rules

1. Count the work as a function of input size n. How many steps for n items?
2. Keep only the fastest-growing term. n² + n becomes n²; the smaller term is noise at scale.
3. Drop constants. 3n and n/2 are both just O(n) — Big O cares about growth, not exact counts.

And by convention, Big O describes the worst case — the most work the algorithm could do — because that is what you must be able to survive.

The growth classes you must know

From fastest to slowest:

The jump from O(n log n) to O(n²) is the line most interview problems are fighting over: a brute-force double loop is O(n²), and the “good” answer usually uses a hash map or sorting to get to O(n) or O(n log n).

How to find the Big O of code

You can read it straight off the structure.

A single loop → O(n):

for (let i = 0; i < n; i++) {
  console.log(i);          // runs n times → O(n)
}

A nested loop over the same data → O(n²):

for (let i = 0; i < n; i++) {
  for (let j = 0; j < n; j++) {
    console.log(i, j);     // n × n → O(n²)
  }
}

Halving the problem each step → O(log n):

while (n > 1) {
  n = Math.floor(n / 2);   // 16 → 8 → 4 → 2 → 1 → O(log n)
}

Two separate loops → still O(n). O(n) + O(n) = O(2n) = O(n) — you drop the constant. Only nesting multiplies.

A quick heuristic: nested loops multiply, sequential loops add, halving is logarithmic, and a hash-map lookup is O(1).

Don’t forget space complexity

Big O also measures memory, using the same notation. An algorithm that builds a new array of size n uses O(n) space; one that swaps elements in place uses O(1). Interviewers often ask for both time and space, and the classic trade-off is “use more memory (a hash map) to save time” — turning an O(n²) search into O(n).

Recursion has a hidden space cost too: each pending call sits on the call stack, so deep recursion is O(depth) space even when it looks like it allocates nothing.

A data-structure cheat sheet

Big O is most useful when you know the cost of the operations you build on. Average-case costs:

This is why “use a hash map” is the most common interview optimisation: it turns linear searches into constant-time lookups. We cover each structure’s trade-offs in The 8 data structures every developer should know.

Common mistakes

• Confusing “fewer lines” with “faster.” A tidy nested loop is still O(n²). Structure determines Big O, not length.
• Forgetting hidden loops. A .includes() or .indexOf() inside a loop is a loop inside a loop — secretly O(n²).
• Ignoring space. A solution that is fast but allocates O(n²) memory can be just as disqualifying.
• Optimising the wrong thing. For genuinely small, fixed inputs, O(n²) is fine. Big O matters when n can grow.

Where this fits

Big O is the measuring stick for everything in coding interviews — data structures, recursion, and the algorithm patterns built on them. Learn it first; every other topic refers back to it.

The full set — analysing loops, recursion costs, and the time/space trade-offs interviewers love — is worked through in our job-ready tier: JavaScript in Three Months, Python in Three Months, and Java in Three Months, each in the same diagram-first handwritten style. Aiming at senior or staff interviews, where the questions shift toward system design and subtler algorithmic trade-offs? The for Staff Engineers tier goes further: JavaScript, Python, and Java.

Once you can glance at code and name its Big O, interview problems stop being puzzles and start being a checklist.