Big-O notation describes how an algorithm grows as input size grows. It is not a stopwatch. It is a way to reason about scalability before the system is under pressure.
Constant time: O(1)
An operation is O(1) when the amount of work does not grow with input size.
Reading an array element by index is a classic example:
int value = numbers[3];A hash map lookup is usually treated as O(1) average-case, although collisions and implementation details can affect worst-case behavior.
Linear time: O(n)
An operation is O(n) when work grows in proportion to input size.
for (User user : users) {
if (user.id().equals(targetId)) {
return user;
}
}If the list doubles, the worst-case scan roughly doubles.
Logarithmic time: O(log n)
Binary search is O(log n) because each step cuts the search space in half. Balanced trees also often provide O(log n) insertion, lookup, and deletion.
For backend developers, this is the intuition behind many indexes: avoid scanning everything when a structure can narrow the search quickly.
Quadratic time: O(n^2)
Nested loops are often a warning sign.
for (User a : users) {
for (User b : users) {
compare(a, b);
}
}This may be fine for 20 users and painful for 200,000. Big-O helps you notice that growth curve early.
The practical mindset
Use Big-O to compare approaches, not to ignore real-world measurement. Constants, memory access patterns, network calls, database indexes, and caching all matter.
The best backend engineers combine complexity analysis with profiling and production evidence.
Related reading
Read Time Complexity of Java Collections for a Java-focused reference and use the Big-O Cheat Sheet when you need a quick lookup while reviewing code.