Pick a problem you can almost solve
The useful problem sits just past what you can already do. If you know the answer ten seconds after reading the statement, you’re doing reps. If you can’t say what a brute force would even look like, you’re reading a lesson in disguise. Aim for the one where you can write the slow solution and get stuck making it fast.
On Arise that’s usually the next unsolved row in your current set. Codeforces ratings give you a second check: problems 100 to 300 above your rating are where most of the learning happens, and problems 500 above it mostly teach you to read editorials.
Pick one problem for the session. A list of ten turns the evening into a race to tick rows, and the hard one at the bottom never gets a real attempt.
Attempt it before looking anything up
Read the output format first, then the constraints, then the story. The constraints tell you how fast the answer has to be before you’ve thought about how to get it: n ≤ 2·10⁵ rules out anything quadratic, and n ≤ 20 is asking for bitmasks.
Solve two tiny inputs by hand, and make one of them annoying: all equal values, a single element, a negative number. If you can’t produce the right output by hand, no algorithm is going to save you yet.
Write the brute force down even when it’s too slow, then ask what it computes twice. Most fast solutions are the slow one with the repeated work cached, sorted away or counted in a single pass.
Give it a real attempt: 30 to 45 minutes for most problems, longer while you’re still producing new ideas. When the ideas stop, take a hint. The hints guide covers which one.
After the verdict
Once it’s accepted, close your code, open a blank file and write the solution again from memory. The line you get stuck on during the rewrite is the part you didn’t understand, so go read that part again.
If you get Wrong answer, find the smallest input where your output differs from the right one (the stress-testing guide shows how to find it automatically), then trace your code on that input. Print three or four variables per step and the bug usually shows up fast.
Then write a two-line note: the idea that cracked it and the mistake you made. “Count prefix sums, check the earlier ones. Forgot the empty prefix.” That note is what you read before the problem comes back for review.
Plan the week around return visits
Most of what you solve this week is gone in a month unless you see it again. Turn on Arise’s review: when you mark a problem solved it asks how much help you needed and schedules the next visit from your answer. Start each session with whatever is due.
If you have five evenings, three or four new problems, two return visits and one timed contest or virtual round is plenty. If you only have three, keep the return visits and cut new problems first.
At the end of the week, look at what failed. If most attempts died on the statement, drop a difficulty level. If you solved everything without a hint, move up one. Treat the plan as a guess you correct every week.