Problem types

A problem's type governs how a submission is produced and how it is graded — whether the participant writes a whole program, a single function, a SQL query, or uploads answer files instead of code. It is set in the Testing → Configuration dialog, alongside the time and memory limits, and not on any metadata screen. That is the part people miss: there is no Type field on the Statement tab or in the problem's header.

The type also decides which editors the console shows you. Set it before you configure anything else, or you will go looking for rows that are hidden because the type is wrong.

Fig 1. Testing → Configuration: the problem type, the limits, run count and interactive followup.

The types

Type	What a submission is
Classic	A complete program that reads input and writes output.
Function	A function. A header and a footer from the code template wrap the submitted source into a full program before compilation.
Output only	Answer files, uploaded by the participant. There is no program to run.
SQL	SQL queries. Results are compared with the Query results checker.
Machine learning	A machine-learning problem.
Interactive	A program that communicates with an interactor instead of reading a static input file.

What the type controls in the console

Three parts of the problem editor appear or disappear with the type, silently:

The interactor row in Testing exists only when the type is Interactive. If you have written an interactor and cannot find where to paste it, the type is not set to Interactive.
The header and footer editors in the code template editor are editable only for Function problems, because only there is the participant's source wrapped into something larger.
The code templates row on the Solutions tab is hidden for Output only problems, since there is no source code to pre-fill.

Nothing else about a problem changes when you change the type: statements, tests, testsets and scoring work the same way throughout.

Choosing a type

Classic is the default shape of a problem and the right answer unless something below applies.

Choose Function when you want participants to implement one routine rather than a program — you supply the input parsing and the output printing in the template's header and footer, and the participant fills in the middle. Anything a participant could read in the header, footer or additional files is effectively public, so grading logic does not belong there.

Choose Interactive when the input a solution needs depends on what the solution has already done — a guessing game, a query budget, an adaptive adversary. The interactor supplies the other half of the conversation, and the protocol has to be written out in the statement. Interactive problems usually keep instructions for the interactor in the test's input and answer, rather than data a participant would recognise, so their example tests use the statement overrides described in Test cases.

Choose Output only when the participant is meant to produce answers by any means they like — by hand, by a program run on their own machine, by a spreadsheet — and upload them. Attach the input data to the statement so they have something to work on.

Choose SQL for problems answered with a query. Pair it with the Query results checker, which compares JSON-encoded query results and can be told whether row order matters.