It's Not About Seconds
When we ask "How fast is this code?", the answer shouldn't be "100 milliseconds." Why? Because 100ms on a supercomputer is different from 100ms on an old phone. And 100ms for 5 users is different from 100ms for 5 billion users. Clock time is a property of the machine, not the algorithm.
What we actually want to measure is how an algorithm behaves as the problem gets bigger. Does it stay fast? Does it slow down a little? Does it grind to a halt?
Scalability
Big O Notation describes how the runtime of an algorithm grows as the input size grows. It measures scalability, not raw speed. The input size is conventionally called N — the number of items in a list, the number of nodes in a graph, the number of characters in a string.
- If an algorithm is $O(N)$, doubling the input doubles the time.
- If an algorithm is $O(N^2)$, doubling the input quadruples the time ($2^2 = 4$).
- If an algorithm is $O(1)$, doubling the input changes nothing.
This is the common language used in every technical interview to discuss trade-offs between approaches. When an interviewer asks "what's the complexity?", they are asking you to characterize the shape of the growth curve, not the exact runtime.
Interviewers often ask: "Can you do better than O(N²)?" This is an invitation to discuss a more efficient approach — not a trick question. The expected answer is to identify why the current approach is quadratic (usually a nested loop), then propose a data structure (like a hash map) that reduces the inner loop to O(1), bringing the total to O(N). Always think about what data structure could eliminate redundant work.