Talking About Big-O in a Coding Interview Without Fumbling

Almost every coding interview ends with "what's the time and space complexity?" Many candidates who solved the problem cleanly then lose points by guessing, hedging or getting space wrong. A short, repeatable way of answering fixes that.

State it at three moments

  1. Brute force, before coding: "The naive approach checks every pair, O(n²) time, O(1) space." This frames the improvement you're about to make.
  2. Your plan: "With a hash map I can get O(n) time at the cost of O(n) space." Now the interviewer knows the target.
  3. After coding, verified against the code: point at the loops and data structures that produce each term.

Justify, don't just declare

"O(n log n)" on its own sounds memorised. "We sort once, O(n log n), then a single pass, O(n), so the sort dominates" shows you derived it. Name what n is, too, especially when there are two inputs: O(m + n) and O(m · n) are very different answers.

Costs people forget

Quick reference

PatternTypical time
Single pass / two pointersO(n)
Sort then scanO(n log n)
Binary search on sorted dataO(log n)
Heap of size k over n itemsO(n log k)
BFS/DFS on a graphO(V + E)
Backtracking over subsetsO(2ⁿ)

When asked "can you do better?"

Ask yourself what the lower bound is. If you must look at every element, you can't beat O(n); say so confidently rather than hunting for a trick that doesn't exist. If the bottleneck is repeated lookups, a hash map or precomputation usually helps. If it's sorting, ask whether the input range is small enough for counting sort.


Disclosure: I'm with the team at Linkjob AI, a real-time interview assistant. This guide is general and product-independent.