I put off learning Big-O for years. Every explanation I found started with limits and asymptotic bounds and lost me by the second paragraph. It felt like math homework that had nothing to do with writing code.
It turns out you can get most of the value without any of that. Big-O is just a way to answer one question: when the input gets bigger, how much slower does this get? That's it. The rest is detail.
The whole idea in one sentence
Big-O describes how the work grows as the input grows.
If you double the size of the input, does the work stay the same? Double? Quadruple? Blow up entirely? That's the question Big-O answers, and that's the question interviewers are really asking when they say "what's the complexity of this?"
You're not measuring seconds. You're measuring the shape of the growth.
The five you actually need
There are a lot of complexity classes. In practice, you'll meet five of them over and over.
O(1) - constant. The work doesn't change with input size. Looking up a value in a hash map. Reading the first element of an array. It costs the same whether the array has 10 items or 10 million.
O(log n) - logarithmic. You throw away half the work each step. Binary search is the classic example. Going from 1,000 items to 1,000,000 only adds about 10 more steps. This is the good kind of slow.
O(n) - linear. You touch each item once. A single loop over an array. Double the input, double the work. Honest and predictable.
O(n log n) - linearithmic. The ceiling for good sorting algorithms. Slightly worse than linear, way better than the next one. When a sort shows up in your solution, this is usually the cost.
O(n^2) - quadratic. A loop inside a loop, where both run over the input. Comparing every item to every other item. This is where things get slow fast. At 1,000 items you're doing a million operations.
If you can recognize these five on sight, you're ahead of most candidates I've seen.
How to read your own code
You don't need to memorize a table. You need two habits.
First, count the loops. One loop over the input is usually O(n). A loop nested inside another loop, both over the input, is usually O(n^2). Three deep is O(n^3), and at that point you should be suspicious of your own approach.
Second, watch for the halving. If something cuts the problem in half each pass, that's a log in there. Binary search, balanced tree operations, certain divide-and-conquer patterns. The word "half" is your tell.
Sorting is the third thing worth memorizing flat out: a good sort is O(n log n). If your solution sorts the input and then loops through it once, the sort dominates, so the whole thing is O(n log n).
The mistakes that trip people up
Drop the constants. O(2n) is just O(n). Two loops back to back, each over the input, is still O(n), not O(2n). Big-O cares about the shape of the growth, not the exact count.
Keep the biggest term. If your function does an O(n^2) chunk and an O(n) chunk, it's O(n^2). The smaller term gets swallowed as the input grows.
Don't forget space. Big-O also describes memory. If you build a new array as big as the input, that's O(n) space. Interviewers ask about both, and people forget the space half.
And know that hidden costs exist. That innocent-looking call to check if an item is "in" a list might be O(n) under the hood, which can quietly turn your O(n) loop into O(n^2). Know what your built-in operations actually cost.
How to talk about it in an interview
You don't need to be perfect. You need to reason out loud.
Say what the loops are doing. Name the dominant operation. Land on a class and explain why. "I'm looping over the array once, and for each item I do a constant-time hash lookup, so this is O(n)." That sentence does more for you than reciting definitions ever will.
If you get it slightly wrong but your reasoning is sound, most interviewers will nudge you, and you'll correct it. They want to see how you think, not whether you memorized a chart.
This is also the kind of thing that clicks with reps. Take a handful of problems you've already solved and state the complexity of each, out loud, before you check. Do it in mock interviews where someone can push back. After a couple dozen, you'll stop reaching for the table and start seeing the shape directly.
You don't have to love Big-O. You just have to read it well enough to talk about your own code. That part is learnable in an afternoon.