š The Simple Version
Big-O answers one question: "If my input gets bigger, how much slower does my code get?" It's not about exact speed ā it's about the shape of the slowdown.
The Ones You'll Actually See
- O(1) ā constant. Doesn't matter how big the input is, it takes the same time. Looking up a value by its key in a hash map.
- O(log n) ā barely grows. Doubling the input adds just one more step. Binary search.
- O(n) ā grows in a straight line with the input. Looping through a list once.
- O(n log n) ā the "good enough" sorting speed. Most efficient sort algorithms live here.
- O(nĀ²) ā grows fast. A loop inside a loop over the same list. Fine for small inputs, painful at scale.
A Trick to Spot It in Your Own Code
Count the loops. One loop over the input, not nested = usually O(n). A loop inside a loop over the same data = usually O(nĀ²). A loop that keeps cutting the problem in half = O(log n). You will get this right 80% of the time just by looking at your loops.
Why It Matters Beyond Interviews
It's not just an interview trick ā it's why a search feature that feels instant on 100 rows can freeze the page on 100,000 rows. Big-O is the difference between "works on my machine" and "works in production."
The Honest Truth
You don't need to prove anything mathematically to use Big-O well. You need to recognize the shape of your loops and know which shapes get dangerous as data grows. That's it.