The editor & runtime

The editor is where you'll spend your time, so it's worth two minutes to learn what it expects and what it gives you back.

What you write

Every puzzle hands you a starter file with a single public class and one method to implement:

using System;

public class Solution
{
    // TODO: return the sum of two binary strings, as a binary string.
    public string AddBinary(string a, string b)
    {
        throw new NotImplementedException();
    }
}

The grader calls that method by name, so a few rules follow from it:

• Don't rename Solution or the entry method, and don't change its signature. They're the contract the grader binds to. Everything else inside the class is yours: add helper methods, fields, nested types, whatever the solution needs.
• There is no Main. Submissions compile to a library, not a program, so top-level statements won't run. Put your logic in the method.
• Add the using directives you need at the top of the file. The full .NET base class library is referenced. Collections, LINQ, Span<T>, System.Text, System.Numerics, regular expressions, and the rest all resolve.

The C# you can use

Submissions use C# 12 in Release mode, so the modern language is at your disposal: pattern matching, records, switch expressions, collection expressions, spans, and so on. Two deliberate limits:

• unsafe code is disabled at the compiler level. It's a sharp edge you don't need for these puzzles, and turning it off is one more guard around the sandbox.
• No external NuGet packages. You get the base class library and nothing else, so a solution is always your algorithm, not a one-line call into someone else's. The Database / EF Core track is the exception: those puzzles also reference EF Core so you can write LINQ over the model.

Compilation has its own time limit. If you hit it, the result tells you so. Ordinary puzzle code should compile comfortably within it.

Multiple files

Most puzzles are a single file. Architecture katas and some other project-shaped exercises are not: you get a small multi-file project in tabs and work across it. The selected tab is the file shown in the editor, but the whole project compiles together.

Each file has its own browser-saved buffer. Reset restores the complete starter file set, including files you changed or removed from the local tab list.

Run, Submit, and the keyboard

Two buttons have two very different jobs. They are covered in full in Getting started:

Action	Button	Shortcut	What it does
Run	▶ Run	Ctrl/Cmd + Enter	Executes the visible sample cases and any custom input you typed. It does not use a submission.
Submit	Submit	Ctrl/Cmd + Shift + Enter	Grades you against the full hidden suite. Counts toward your daily quota on the Free plan.

Run is for iterating; Submit is for the verdict. The rhythm that works is: Run until the samples pass, add a custom edge case, reason about complexity, and then Submit.

Custom input

The Output tab includes a custom input box. Enter the method arguments as a JSON-shaped array, then press Enter or its Run button. Custom input shows the return value and console output without a pass/fail verdict because you did not provide an expected answer.

Custom input is remembered per puzzle in the current browser. It is not included in Submit and does not become part of the hidden suite.

Output and errors

When you Run, anything you write with Console.WriteLine is captured and shown beside the return value. This is handy for a quick trace while you debug. Compile errors appear inline in the editor as red underlines, with the same diagnostics the compiler produced, so you can fix them without leaving the keyboard.

The result area separates Output from Tests. Output is where you inspect inputs, return values, console output, and visible differences. Tests is where you inspect the quality scorecard, hidden-test verdicts after Submit, track-specific rules, and failing-only filter.

Your work is saved

Your in-progress code is kept per puzzle in the current browser, automatically, as you type. Close the tab in the middle of a thought and your buffer is there when you come back on that browser. Clearing site data removes local buffers.

Signed-in solved progress and submission history follow your account, but the in-progress editor buffer is browser-specific. Do not rely on an unfinished buffer appearing automatically on a second device.

When you want a clean slate, Reset restores the original starter. When you are stuck, progressive hints preserve more of the struggle; Reveal solution loads a correct reference you can study. Reset afterwards and reproduce the approach from memory. Revealing does not mark the puzzle solved.

See How grading works for what happens after you hit Submit.