The solver
The layout of a problem page, why the editor holds only your function, how your draft survives a refresh, and what each of the three tabs is for.
Opening a problem gives you the statement on the left and an editor on the right, with a testcase and result pane underneath it. The seam between the two panes drags, and double-clicking it puts the split back where it started.
On a phone the panes become tabs - Description, 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 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 in the editor's menu 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 three tabs#
Description#
The statement, the worked examples, the constraints, the topics, 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.
The panes 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.
Result fills in after a Run or a Submit, and is covered in verdicts and test cases.
Shortcut#
Ctrl ↵ runs, from anywhere on the page - ⌘ ↵ on a Mac. It is the same shortcut the Playground and the Projects editor use.
Related#
Was this page helpful?