Big-O — Name the Complexity of the Code
Read the snippet, name its time complexity, then watch the growth curve. Six classes, six rounds. Free, no sign-up.
Five snippets, five of the six complexity classes, each asked once.
How to play
- Read the snippet and pick its time complexity from the six.
- The growth curve is drawn after each answer — yours in red, the right one in green.
- Five of the six classes per run, never repeated, so answering the same thing every time is right at most once.
- Consecutive correct answers pay more. A wrong one resets the streak.
How it works
Each round shows a short piece of code and asks for its time complexity. Answer, and the growth curve is drawn for you — yours against the right one — so the choice stops being a label and becomes a shape you can see. A run asks five of the six classes, shuffled and never repeating, which means answering the same thing every time is right at most once — and the class left out changes, so the last round is never free by elimination. The snippets are chosen so each has one defensible answer: no early exits, no hidden library costs, and nothing that gives its own complexity away in a comment. Sorting is taken as O(n log n) throughout, which is what every mainstream standard library actually provides. Runs on your device, nothing is sent anywhere, and there is nothing to sign up for.
Big-O describes how cost grows, not what it is. A well-constant-factored O(n²) beats a bloated O(n log n) at the sizes most code actually sees — which is the subject of a different game on this site.
Frequently asked questions
Why is the curve drawn on a log scale?
Because six classes will not otherwise fit one chart. At n=24 a constant-time function costs 1 and an exponential one costs sixteen million, so on a linear axis five of the six curves would be the same flat line along the bottom. A log scale turns each class into a distinguishable slope, which is the thing worth seeing.
Is sorting really O(n log n)?
For comparison sorts, yes — that is a proven lower bound, and it is what every mainstream standard library provides. Counting and radix sorts beat it by not comparing, but they need assumptions about the keys. When a snippet here calls sort(), it costs n log n.
Why are there no snippets with an early return?
Because an early return turns a worst case into an average case, and then the answer is not a single class. A linear search that returns on the first match is O(n) in the worst case and O(1) if the match is always first, so asking for "the" complexity would be unfair. Binary search is the exception: it exits early and is still exactly O(log n).
Does the streak matter?
Yes. Every second correct answer in a row adds to what the next one pays, up to a cap, so a clean run is worth substantially more than four right and two wrong. A wrong answer resets it.