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.

Choose the right puzzle

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.

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.

Read the problem panel

The problem panel shows the puzzle title, difficulty, category, number of visible sample tests, and number of hidden graded tests. Read the full goal, examples, constraints, and required method signature before editing.

Some puzzles add tools below the brief:

• Progressive hints reveal one hint at a time. Previously opened hints remain available in the current browser when you return.
• Database schema expands into the tables, columns, keys, relationships, and sample rows needed for a Database / EF puzzle.
• 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.

Work in the editor

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:

Action	What happens
Reveal solution	After confirmation, replaces the editor with a correct reference solution for study. It does not mark the puzzle solved.
Reset	Restores the original starter code for the current puzzle. This discards the current local buffer.
Run	Executes visible sample tests and an optional custom input.
Submit	Grades the full suite and records a successful solve for a signed-in learner.

Use Ctrl/Cmd + Enter for Run and Ctrl/Cmd + Shift + Enter for Submit. The editor shows compiler diagnostics inline. Your current buffer is saved in the browser as you type, separately for each puzzle and file.

Test your own input

Open the Output result tab and enter JSON-shaped arguments in the custom input box. 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 its Run button. 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.

Understand Output and 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 quality scorecard and the full graded evidence. After Submit, it includes hidden test names and verdicts. If the list is long, Only failing reduces it to the cases that need attention.

The quality scorecard 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.

After a clean pass

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 open a Why this works section after the pass. Use it to review the reasoning while the solution is still fresh; its open or closed state is remembered for that puzzle.

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

Reveal, reset, and retry

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.

Use the workspace on mobile

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.