Big-O Complexity Estimator
Enter an input size and read the operation count and feasibility for each common complexity class — the fastest way to build the scaling intuition coding interviews are really testing.
Why the class matters more than the code
Two correct solutions to the same problem can differ by a factor of a billion at scale. Seeing the operation count jump from thousands to ten billion as you move from O(n log n) to O(n²) at the same input size is the moment Big-O stops being abstract. That instinct — knowing which class you need before you write a line — is what separates a passing interview from a timeout.
Fold this into a structured plan with the Coding Interview Countdown, which schedules the data-structures and algorithms topics these complexities show up in.
Frequently Asked Questions
What is Big-O notation, quickly?
Big-O describes how the work an algorithm does grows as its input grows, ignoring constant factors. O(n) means the work rises in step with the input; O(n²) means doubling the input roughly quadruples the work; O(log n) barely grows at all. It is the vocabulary interviewers use to ask 'will this scale?', and it is the difference between a solution that returns instantly and one that hangs.
How does the estimator turn a class into an operation count?
For an input size n it evaluates the class directly: O(1) is one, O(log n) is the base-2 logarithm, O(n) is n, O(n log n) is n times that logarithm, O(n²) is n squared, and O(2ⁿ) doubles per element. The counts are order-of-magnitude, not exact — a real routine has constants and lower-order terms — but they make the gap between classes concrete at a glance.
What do the feasibility bands mean?
They map the operation count onto a rough '~100 million simple operations per second' rule of thumb. A few thousand operations is instant; tens of millions is comfortably under a second; a billion or more starts to hang. So an O(n²) pass over 100,000 items — ten billion operations — is flagged intractable, which is exactly the intuition an interview wants you to reach without running the code.
Can I trust these numbers for real performance?
Treat them as intuition, not a benchmark. Actual runtime depends on the language, memory access patterns, cache behaviour, and constant factors the notation deliberately hides. Use the estimator to reason about which complexity class you need before you code, then measure the real thing when performance matters.
Order-of-magnitude estimates for building intuition, not a benchmark. Real runtime depends on constants, memory, and hardware.