Skip to content
CCC Python Course

How judging works

Module
M0.5
Lesson
1 of 1
Reading time
5 min

In this lesson

  • Explain that the judge runs your program once for each hidden test case, feeding it that test's input and comparing what it prints.
  • Describe how tests are grouped into subtasks, and that a subtask stops at its first failing test.
  • Recognize the verdicts AC, WA, TLE and RTE, and what causes each one.
  • Say that the grader keeps your best submission, within the submission limits.

You never see the judge run your program. This lesson opens up what happens between your submission and the result that comes back, so the words on the results screen mean something the first time you see them.

One program, many hidden tests

A problem is never checked with a single example. The judge holds a set of hidden test cases. Each one is a full pair: some input, and the exact output your program should produce for it.

Your program runs once per test case. Each run starts fresh, with that test's input on standard inputThe stream of text a program reads its input from, normally whatever the judge feeds it.In the glossary and nothing carried over from the test before it.

Each run ends the way the module on exact output described. The judge reads whatever your program wrote to standard outputThe stream of text a program writes its output to, normally what the judge reads and compares.In the glossary. It compares that against the expected output, line by line. A run that matches earns credit for that test. A run that does not match, whatever the reason, does not.

Subtasks: tests grouped into batches

A problem's tests are grouped into subtaskA named group of hidden test cases within one problem, run and reported together as a batch.In the glossary. Each subtask is a named batch, often built around a bound stated in the problem. One subtask might promise a small input; another, a much larger one that needs a faster program to finish in time. Passing a subtask usually means passing every test inside it.

That grouping matters for how a subtask fails. The judge checks a subtask's tests in order. Once one test in the batch fails, the rest of that batch is skipped rather than run. A wrong answer on the first test of a subtask can look the same as failing the whole subtask, because the tests after it never ran at all.

Picture a subtask built around three tests, from smallest to largest. If your program passes the first but runs out of time on the second, that subtask's result shows a pass, a time limit failure, and one skipped test. The third test never runs at all, even though it might have passed on its own. Reading which test a subtask stopped on tells you more than the subtask's overall result alone.

The four tests in the figure below are not one subtask's batch. Picture each one as the first test of a different subtask, or from a problem with no subtasks at all. Every one of them still runs, regardless of how the others turned out.

Judge, step 1 of 151234Test inputYour programIts outputCompare with expectedVerdictTest cases
Speed
The judge has your program and 4 test cases. It runs your program once for each test case, starting fresh every time.
  • Current
  • Done
  • Not reached
  • Answer path
  • Compared

Figure 1The judge running four hidden tests, one after another

Read the steps as text

The judge runs the program on 4 test case(s) one after another: it feeds each test's input, compares the program's output with the expected output, and records a verdict for each test (AC, WA, TLE, RTE).

  1. The judge has your program and 4 test cases. It runs your program once for each test case, starting fresh every time.
  2. Test 1: the judge starts your program and gives it this test's input on standard input.
  3. Your program reads the input and prints its answer on standard output.
  4. The judge compares your output with the expected output for this test, line by line.
  5. Test 1: the output matches, so this test is accepted (AC).
  6. Test 2: the judge starts your program and gives it this test's input on standard input.
  7. Your program reads the input and prints its answer on standard output.
  8. The judge compares your output with the expected output for this test, line by line.
  9. Test 2: the output is different, so this test gets wrong answer (WA).
  10. Test 3: the judge starts your program and gives it this test's input on standard input.
  11. Your program starts reading the input and working on its answer.
  12. Test 3: before any output could be compared, the program was still running when the time limit ran out, so this test gets time limit exceeded (TLE).
  13. Test 4: the judge starts your program and gives it this test's input on standard input.
  14. Your program starts reading the input and working on its answer.
  15. Test 4: before any output could be compared, the program stopped with an error, so this test gets a runtime error (RTE).

Four tests here, four separate runs. The second one prints a different answer than expected. The third one is still running when the time limit arrives. The fourth stops with an error partway through. None of these three failures are the same problem, even though all three mean the test does not pass.

Verdicts: what each result means

A verdictThe judge's recorded result for one test case, such as accepted or wrong answer.In the glossary is the judge's recorded result for one test case. Four verdicts cover most of what you will see.

AC is short for accepted. Your output matched the expected output exactly for that test.

WA is wrong answer. Your program ran to completion and printed something, but it was not the expected output. The mismatch could be the wrong number, the wrong case, an extra space, or a blank line that should not be there.

TLE is time limit exceeded. Your program was still running when its time ran out, usually because it does too much work for how large that test's input is.

RTE is runtime error. Your program stopped on its own before finishing, most often because of one of the errors the next module covers.

The grader's own results screen spells these out in words rather than short codes: "correct" for AC, "wrong answer" for WA, "time-limit exceeded" for TLE, and "run-time error" for RTE. The words and the codes name the same four outcomes.

The judge can also report a compilation error, when your submission cannot even start, and a skipped test, for one of the tests after a subtask's first failure. Neither of those is a verdict about how your program behaves on that test's input. Both mean the test was never really tried.

Your best submission counts

Submitting is not a single attempt. You may submit again after fixing a mistake. The judge keeps the best result you got across every submission to a problem, not the most recent one.

A submission that fails outright costs you little. The 2026 CCC rules allow up to fifty submissions per problem, at most one per minute to any single problem.

That changes how you should treat an early attempt. Submitting a simple version of your solution first, before you have handled every case, still helps. It can pass some subtasks and lock in that result. A later, better submission can only improve on it; it never takes those results away.

A common mistake is stopping the moment you see the first WA and assuming the whole problem is wrong. Read which test failed before you change anything. A wrong answer on a large test tells you something different from a wrong answer on the very first one.

Try it: next time you read about a contest problem with several subtasks, notice which subtask a small, simple input belongs to. That is usually the one a first, unfinished attempt can already pass.

This lesson covered how the judge runs your program once per hidden test. It also covered how tests group into subtasks that stop at the first failure, the verdicts AC, WA, TLE and RTE, and why your best submission is the one that counts.