The solver

Opening a problem gives you a toolbar across the top, the statement on the left, the editor on the right and a test-case console under the editor. Both seams drag - between the statement and the editor, and between the editor and the console - and double-clicking one puts it back. The expand button in the editor's header hides the statement when you want the whole width.

On a phone the panes become tabs - Problem, Code, Result - with the Run and Submit buttons pinned along the bottom. A split editor at 380px wide is unusable, so we do not draw one.

The toolbar#

• The problem list - the button on the left opens the list you are working through in a side panel, with the current problem marked, so you can jump ahead without losing the editor. It shows where you are, for example 3/12.
• Previous and Next - the arrows beside it. They follow the list you came from: the filters you set on the problem list, or, when you opened the problem from a track, the track's own order, section by section. Arrive from a search engine and they walk the whole catalogue.
• Shuffle - a random problem from the same list, one you have not solved when there is one.
• Run and Submit - in the middle. See running and submitting.
• The clock - on the right. It counts the time this problem has been open and in view on this device, and pauses when the tab is in the background. It is what "Time on problem" reports when you solve it. Its menu hides it, if you would rather not see a clock, or resets it.

The editor contains your function and nothing else#

The buffer you get is a stub: the class, the method signature and an empty body. There is no read-only region, no greyed-out preamble and no main for you to leave alone.

That is possible because the code that calls your function is a separate file you never see. It is sent to the sandbox alongside yours and compiled with it.

Choosing a language#

The picker above the editor lists the languages the problem's author offered. Switching regenerates the stub for that language.

It also remembers what you wrote in the language you left. Going Java → C++ → Java brings your Java attempt back, not a fresh stub. Drafts are kept per problem and per language for exactly this reason - one draft per problem would silently discard whichever you switched away from, which is worse than not saving at all because it looks like it worked.

Reset to the starter code is behind the reset button in the editor's header when you want the stub back.

Your draft is kept#

Every keystroke is saved to your browser shortly after you stop typing. Close the tab, refresh, crash the browser - the code is there when you come back, in the language you left it in.

The tabs#

Description#

The statement, the worked examples, the constraints, the topics, who wrote the problem (their name links to their profile), the acceptance rate, and the hint ladder. If the author declared a target complexity it shows here too - "Aim for O(n) time, O(n) space".

The examples are not prose somebody typed. Each one is a real sample test case, and its output was produced by the reference solution - which is why the example and what Run does can never disagree, and why pressing Run replays exactly what the statement shows.

Submissions#

Every submission you have made on this problem, newest first: verdict, language, runtime, memory and when. Open one to read the code you wrote and see which case failed.

This is the tab that makes a solved problem worth returning to. "I solved this three months ago, here is what I wrote" is the most useful reference material a person has, and it is yours.

Signed out, this tab invites you to sign in rather than showing an empty panel.

Approach#

The author's walkthrough, when one has been written, plus who last updated it and when. Covered in hints and approach.

Result#

Appears after a Submit, beside the other tabs, named after the verdict. An accepted submission shows what it took - runtime, memory, time on the problem and attempts - how it compares with other accepted solutions, and the next problem in your list or track. Anything else shows how far it got and the first failing case. Close it with its cross. See running and submitting.

The console underneath#

Testcase holds one editable field per parameter, prefilled from whichever example is selected. Typing into them turns your next Run into a custom run.

Test result fills in after a Run, and is covered in verdicts and test cases.

Shortcuts#

Ctrl ↵ runs, from anywhere on the page - ⌘ ↵ on a Mac. It is the same shortcut the Playground and the Projects editor use. Add Shift to submit instead.

Related#