Code questions
The candidate implements a function. You supply test cases; the platform runs their code against every one of them in an isolated container and reports which passed.
The editor has four tabs — Description, Function, Test Cases and Guidelines. Each is a real URL, so you can send a colleague straight to the tab you mean.
Description
Everything that frames the question, plus its settings.
| Field | Notes |
|---|---|
| Points | This question's weight in the assessment total |
| Time Limit (min) | Per-question limit, separate from the assessment's overall duration |
| Difficulty Level | For your own filtering later; invisible to candidates |
| Tags | Free-form, e.g. algorithms, recursion; how you find the question again |
| Question Description | The rich-text body the candidate reads |
Write the description against the signature you are about to define on the next tab. The single most common authoring mistake is a description that says the function returns a list while the signature says it returns an integer — the candidate believes the prose, and every test case fails.
State the constraints you actually test: input ranges, whether the input can be empty, whether values can be negative. Anything you leave unstated will be handled inconsistently, and you will be marking that inconsistency rather than skill.
Function
Where the shape of the problem is defined. This tab is what makes the question language-independent.
Programming language. Pick the primary language candidates see first. You can optionally allow extra languages, and candidates then switch at runtime — switching replaces the editor contents with the starter code for the new language, so their work is discarded and they are asked to confirm first.
Function signature. The function name, the return type, and each parameter's name and type. Available types cover the usual scalars (int, long, float, double, string, bool, char, void), one- and two-dimensional arrays (int[], string[], int[][], string[][]), and Python's list forms (List[int], List[str], List[List[int]]).
Parameter names matter beyond readability. They are the keys your test-case JSON must use — rename a parameter and every existing test case stops matching. See Test case format.
Starter Code. Generated from the signature, in each allowed language, and editable before you save. This is exactly what the candidate sees when they open the question.
The candidate never writes the surrounding program. Reading input, parsing it, calling the function and printing the result are added automatically at execution time. That is deliberate: a strong engineer should not lose marks for misremembering how to read stdin in a language they use less often.
Test Cases
Input and expected output as JSON, one pair per case, each marked Public or Private.
Public cases are shown to the candidate as worked examples. Private cases are hidden and are what the score is really based on, which is what stops a solution that hardcodes the visible answers.
There is a lot to get right here, and it is where questions break. The full rules — the JSON shape, how output is compared, and the traps around floats and parameter names — are in Test case format.
Guidelines
Two optional fields, neither of which is ever shown to the candidate.
Solution Code — a reference implementation. Worth writing even when it feels redundant: solving your own question is how you discover that the signature is awkward or a test case is wrong, and reviewers comparing a candidate's approach against a known-good one review faster and more consistently.
Interviewer Guidelines — notes for whoever reviews the answers. Key points to look for, common mistakes, what separates a passing solution from a good one. This is the field that makes two reviewers agree.
Before you invite anyone
Open the assessment's Preview and solve your own question in at least one language. Preview runs the real execution path against your real test cases and creates no attempt.
A wrong expected value scores a competent candidate zero and looks to them like their code is broken. They cannot tell the difference, they cannot appeal it, and you will not find out.
What execution costs the candidate
Each test case runs with its own time limit and memory ceiling. Candidates see two timings per run: how long their code actually ran, and the total including compilation and container startup.
Compiled languages — Java, Kotlin, Scala, C#, Rust, Go, C++ — carry a fixed compilation cost on every run that interpreted languages do not. On a code-heavy assessment with a tight overall duration, a candidate on Kotlin has meaningfully less thinking time than one on Python. Either allow for that in the duration or be deliberate about which languages you allow.