Time management over 3 hours

A CCC contest runs for exactly three hours, and you have a fixed number of problems to solve. Unlike a take-home assignment, you cannot spend more time on a problem you find tricky. The three-hour limit is fixed. This means your strategy for which problems to work on, and when to stop work on one, shapes how many points you earn.

The shape of a CCC contest

When the contest starts, you see all problem statements at once. In most CCC contests, there are five problems arranged roughly in order of difficulty, though not always by a strict line. Each problem has subtasks. Some contests give you the full score only if your solution handles all subtasks. Others award partial credit per subtask. A typical pattern is: one problem with three subtasks, one or two with four, and one with five. Not every problem on the contest is expected to be solved by most contestants.

The three-hour window is tight. If you spend an hour on the first problem, you have two hours left for four more. If you cannot figure out the second problem, you have spent time on one problem and gotten nowhere on another, and your clock runs down. The key skill is reading the problem statements quickly, judging their difficulty, and choosing which problems to spend time on.

Deciding what to work on first

Read all the problem statements before you start coding. Skim them in the first ten to fifteen minutes. As you read, note which problem sounds closest to patterns you have already seen, and which one sounds unfamiliar. Unfamiliar usually means harder. This is not always true, but it is a good starting guess.

A common mistake is to start on the first problem and code until time runs out. The first problem is rarely the hardest, but it is not always the fastest to solve either. Some contestants solve the first two problems completely, then spend time on subtasks of the third. Others solve problem 1 and 3 completely, skip 2 entirely, and earn partial credit on 4 and 5 by coding the slow brute-force version. There is no single winning order. Your own strength in certain topics shapes which problems you can solve fastest.

The subtask structure matters. Before you write code, check whether the problem awards marks for solving only the first subtask. If it does, you can earn some points by solving just that part, then move to another problem. If a problem has five subtasks but the first one constraints are so small that you can brute-force it, coding that brute-force solution first gives you at least some marks for that problem. Then you can either refine that solution to handle larger subtasks, or abandon it and work on another problem entirely.

Time allocation in practice

Imagine you have 180 minutes and five problems. A reasonable split might be: 15 minutes to read all statements and plan, leaving 165 minutes for coding. If you solve problems 1 and 2 completely in 60 minutes, you have 105 minutes left for problems 3, 4, and 5. Spending 45 minutes on problem 3's first subtask, then abandoning it for a brute-force of problem 4, gives you partial credit on both and leaves 60 minutes for the last problem.

Another split: spend 45 minutes on problem 1 (all subtasks), 40 minutes on problem 2 (all subtasks), then 95 minutes trying to solve problem 3 completely. If problem 3 is harder than expected, you may run out of time and earn no points on 4 and 5. But if you solve problem 3, you have earned a lot of points on the three hardest problems.

The exact allocation depends on your reading of which problems are easiest for you. One tool to use is your own solved problems from past contests. If you find that certain topics trip you up, know this before contest day. When you sit down in the contest, you can make a smarter guess about which problem to tackle first based on your own history.

Common mistakes in pacing

Spending too much time on one problem is the most common mistake. If you have been stuck on a problem for forty minutes with no clear path forward, that is a sign to stop. Write down what you have figured out so far, move to the next problem, and come back if time allows. Staying stuck longer than that almost never pays off.

Another mistake is coding without testing. If you write a solution for a subtask and do not test it against the sample input before moving on, you may waste time on a bug in your code rather than on the logic of the next problem. Test each subtask solution once before submission.

A third mistake is leaving time on the table. If you have twenty minutes left and have solved only two problems, spend those minutes trying to earn partial credit on a third problem. Even a single subtask is better than zero points. Try the brute-force version first. It is faster to code than an optimized solution.

A fourth mistake is misjudging a problem's difficulty based on the problem number alone. The second problem on a contest is not always harder than the first. Read the statements and think about what the problem is asking before you decide it is out of reach.

Recap

You have 180 minutes and must decide which problems to work on and for how long. Read all statements first, then estimate difficulty based on patterns you have seen, not just the problem number. Allocate time so that you can attempt all problems, earning points on some and partial credit on others, rather than polishing one solution while leaving the rest untouched. Stop work on a problem after forty to forty-five minutes if you have no clear path forward, and move to the next one. Test your solutions before moving on. These decisions, made quickly and without panic, let you maximize your score across the full three-hour window.