Using the puzzle playground

The Playground is where you choose a focused coding problem, work on it, and inspect the evidence from a Run or graded Submit. It is designed to keep the brief, code, and feedback in one place.

Open the puzzle list from the left side on desktop or the list button on mobile. The list has two views when the free Katabench Tour is available:

• All puzzles groups the complete catalog by track.
• Tour shows the curated next steps in the starter learning path.

In All puzzles, type into the search box to match a puzzle's title, summary, or category. Combine that search with the Easy, Medium, and Hard chips or the Solved and Unsolved chips. Sections open automatically while a filter is active, so a matching puzzle is not hidden in a collapsed track. The search and the chips are kept in the address bar, so a reload or a shared link shows the same filtered list.

Each track header shows solved progress. A check marks a solved puzzle. A lock identifies content outside the current plan, while a Free label identifies a preview that you can open inside an otherwise premium track. Selecting locked content shows what access it needs before anything is changed. System Design challenges are not in this list; they have their own catalog inside the System Design Studio.

The problem panel shows the puzzle title, difficulty, track, and what a submission is graded on: the number of visible sample tests and hidden graded tests, plus the architecture rules, design rules, or code-quality gates on those tracks. A Test Writing kata is graded on the planted bugs your tests catch instead. Read the full goal, examples, constraints, and required method signature before editing.

Some puzzles add tools below the brief:

• Database schema expands into the tables, columns, keys, relationships, and sample rows needed for a Database / EF puzzle.
• Progressive hints reveal one hint at a time and are free: they cost no run, submission, or reward. They are ordered from a reframing of the problem, through the name of the pattern or structure to reach for, to a concrete nudge that stops short of the solution. How many you have opened is remembered for that puzzle, so they are available again when you return.
• Code blocks in the brief are syntax highlighted and can be copied.

Hidden-test counts tell you how broad the final grade is, but hidden inputs and answers stay hidden. The test names and result dimensions are the clues you use instead.

Most puzzles have one editable file. Multi-file katas show file tabs, and all of the files compile together. Keep the starter class and required method signature intact; add helper methods and types as needed.

The toolbar provides four actions:

Use Ctrl/Cmd + Enter for Run and Ctrl/Cmd + Shift + Enter for Submit. The editor shows compiler diagnostics inline. Your current buffer is saved as you type, separately for each puzzle and file, and signed-in learners get it synced to their account as a draft. In multi-file katas you can add and remove files from the tabs. See The editor & runtime for the details.

Open the Output result tab and expand Try your own input below the results, then enter JSON-shaped arguments. For a method that accepts an integer array and a target, for example, the value might look like:

[[2,7,11,15], 9]

Press Enter in that box or select Run with input. Your case is listed first, as Your input. Custom input is exploratory: it shows the return value and console output but has no expected value, so it does not produce a pass or fail verdict. The input is remembered per puzzle in the current browser, and the section stays open while it holds a value. Database and test-writing puzzles have no custom input: database inputs are the seeded fixtures, and a test-writing Run executes your own tests.

The results area has two tabs:

• Output focuses on visible and custom cases. It shows inputs, expected and actual values, a character-level mismatch, return values, console output, timing, and memory information when available.
• Tests shows the full graded evidence, failing cases first, with the run or graded result recap. After Submit, it includes hidden test names and verdicts. If the list is long and mixes passes with failures, Only failing at the end of the verdict line reduces it to the cases that need attention.

Both tabs open with a verdict line that names the gate that decided the result. The graded result recap on Tests adapts to the exercise. It can report correctness, runtime and allocation headroom, security checks, query-plan rules, structural or design rules, planted bugs caught by your tests, and your best-time standing. Only dimensions that apply to the selected puzzle are shown.

Database puzzles can show the query plan that was graded and which plan rules held. Secure-coding puzzles separate functional behavior from adversarial checks. Refactoring, architecture, design, and test-writing puzzles list their relevant rule results. How grading works explains each result in more depth.

A successful Submit marks the puzzle solved, updates signed-in progress and rewards, and offers a Next puzzle action when there is another useful step. Many puzzles also add a Learning tip tab beside the problem after the pass (System Design calls it the Lesson). Use it to review the reasoning while the solution is still fresh; it stays available whenever you reopen a solved puzzle.

After your first solve, the results panel may suggest one puzzle from a track you have not tried yet. It is a single card that disappears once you have solved in more than one track.

If you arrived through a learning path, Next follows that path. In ordinary catalog mode, it moves to the next appropriate unsolved puzzle.

Revealing a solution is a study tool, not a completion shortcut. A good recovery loop is:

1. Reveal and read the reference.
2. Run it and inspect the result evidence.
3. Reset the puzzle.
4. Rebuild the idea from memory.
5. Submit only when you can explain why it works.

Free accounts have a daily reveal allowance shown in the toolbar when available. A cached reveal can be reopened in the same browser without spending another reveal. Current allowances are listed on Pricing.

On smaller screens, use the bottom tabs to switch between Problem, Code, and Results. The primary actions remain available in the code view, and contextual hints explain the mobile layout the first time you use it. Open the puzzle list as a drawer and close it after choosing an exercise.

For multi-panel comparison, detailed query plans, and larger refactoring katas, a desktop-sized viewport is more comfortable, but the core Run, Submit, result, hint, reset, and reveal workflows are available on mobile.