Reading a problem set: difficulty estimation and order of attack

A contest is not solved top to bottom. The single most expensive rookie habit is opening problem A, grinding until stuck, and never noticing that C and D are easier. The first few minutes are reconnaissance, not problem-solving: skim every problem and rank them, because you are about to spend your scarcest resource — time — and you want to spend it on the cheapest points first.

The constraints are a difficulty oracle. The bound on n all but tells you the intended complexity, which tells you how hard the problem is:

n <= 20          2^n  or  n*2^n      bitmask / meet-in-the-middle
n <= 40          2^(n/2)             meet-in-the-middle
n <= 500         n^3                 Floyd-Warshall, interval DP
n <= 5000        n^2                 quadratic DP, n^2 pair scans
n <= 2*10^5      n log n             sort, segment tree, binary search
n <= 10^6        n  or  n log n      linear scan, two pointers, sieve
n <= 10^18       log n  or  digits   fast exponentiation, digit DP, math

The other oracle is the scoreboard. CodeChef and Codeforces show how many people have solved each problem in real time — that is a crowd-sourced difficulty sort, free for the reading. If 800 people solved C and 40 solved B, you do C first, whatever the letters say. Statement length lies (a long statement is often just a wordy easy problem); solve counts and constraints do not.

So the order of attack is: read everything, rank by estimated difficulty, and solve in increasing order — banking the easy problems fast. In every major format a solved easy problem is worth exactly as much as a solved hard one, and finishing it sooner lowers your penalty time. Index order is a trap; difficulty order is the game.