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 are compiled with Roslyn against 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 runs under a hard time budget. If you hit it, the message tells you so — the usual cause is pathological generics, not ordinary code.

Multiple files

Most puzzles are a single file. Architecture katas are not: you get a small, multi-file project in tabs and refactor across all of it. The whole project compiles together, exactly as it would in your IDE.

Run, Submit, and the keyboard

Two buttons, two very different jobs — 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) and shows output immediately. Free and uncounted.
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: Run until the samples pass, reason about the complexity, then Submit.

Output and errors

When you Run, anything you write with Console.WriteLine is captured and shown beside the return value — 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.

Your work is saved

Your in-progress code is kept per puzzle, automatically, as you type. Close the tab in the middle of a thought and your buffer is there when you come back. Solved puzzles are marked with a ✓. When you want a clean slate, reset restores the original starter; when you're stuck, reveal solution loads a correct reference you can study, then reset and beat from memory.

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