Read Constraints, Pick Complexity

Every problem lists limits on n and the values. Those constraints quietly tell you which complexity the setter expects. 🔍

Before designing anything, find the largest n in the constraints. The size of n decides whether quadratic, linear, or log is required.

When n is at most 20, even exponential brute force fits. Small limits are an invitation to try every combination without fear.

If n reaches a few hundred, an O(n^3) solution still passes. Triple loops or basic DP over pairs are fair game here.

Around n = 5000, aim for O(n^2). Nested loops over the array cost about 2.5 times 10^7 steps, which still fits the budget.

When n hits 10^5 or 10^6, you need O(n log n) or O(n). Sorting, prefix sums, and two pointers become your go-to tools.

If n is a billion, no loop over n survives. You must be O(log n) or O(1), using math or binary search on the answer.

Constraints on values matter as well. Large numbers warn about overflow in other languages and may hint at modular arithmetic.

Multi-test problems often bound the sum of n, not each n. Read this carefully, since it changes how big your loops can safely be.

Pick the target complexity from n, then choose an algorithm that hits it. Letting n guide design beats guessing and rewriting later.

Keep this table in your head. The constraint-to-complexity map turns a quick glance at limits into an instant plan during contests.

Let n point you to the right complexity.

You now read constraints as a target: tiny n allows brute force, 10^5 needs n log n, and 10^9 demands log or math. Let n choose the approach. 🗺️