What participants see while solving
A participant sees the statement, the example tests you flagged, the code template for the language they picked, and — after they submit — as much or as little about the judging as the problem's feedback policy allows. They do not see the test data, the checker, the interactor, or anything those programs printed.
This page collects the participant's side of decisions you make elsewhere in the problem, so you can tell what a given configuration will look like from the outside.
Before they submit
The statement is what you wrote, rendered by the same renderer as the console preview, with the time, CPU and memory limits shown as an icon row above it. The Examples section is built from the tests you flagged as examples — and shows the per-test statement overrides where you set them, which is how an interactive problem shows a readable dialogue instead of the interactor's script.
Attachments appear as chips under the statement, not inline. The editor opens pre-filled with the code template for the runtime they choose, where you have written one; headers, footers and additional files are not shown to them, though in some languages a submission can read them at run time.
Every other test is hidden. Participants never see the inputs and answers of non-example tests, whether you uploaded them or generated them.
After they submit
What comes back is decided per testset, by its feedback policy:
Feedback policy | The participant is told |
|---|---|
Show each test individually | The result of every test in the testset. |
ICPC format | Only the first test that was not accepted — not which one it was. |
ICPC with test number | The first test that was not accepted, and its number. |
Because the policy is per testset, one problem can be generous about its samples and silent about the rest: give the example testset Show each test individually and the graded testsets ICPC format, and a participant can check that they understood the format without learning which hidden case breaks them.
Scores follow the scoring mode of each testset, and a testset whose dependencies were not satisfied is not run at all — so a participant may see a testset with no result rather than a failed one.
The vocabulary of statuses and verdicts is the same one used throughout the console; Statuses and verdicts defines it.
What is never shown to a participant
Three things are worth stating plainly, because problem authors write into them expecting the participant to read it, and the participant never does:
Their own program's standard error. Whatever a solution prints to stderr is internal, for administrators only. It is not a channel for telling a participant what went wrong.
Checker output. A message a checker writes when it rejects an answer is not passed on to the participant.
Interactor logs. Nothing an interactor reports about the interaction is shown to the participant either.
If a participant needs to know something, it belongs in the statement or in the editorial — those are the only two places you control what they read.
Test data and grading programs
Test inputs and answers, checkers, interactors, validators, generators and reference solutions are console-side content. They are never served to participants, and a test, checker or template marked secret is not even served to the console.
Once they have solved it
The editorial, if the problem has one, is a tab of the problem on the public site. So is the discussion thread, when discussions are enabled for the space — the same thread you see on the problem's Discussion tab, with the same moderation.
Participants who spot a mistake report it through the problem's issues; in the Basecamp space they can also propose a corrected statement, translation or classification as a suggestion.
Stand with Ukraine