🛠️ How to Solve and Test

The workflow

1. Create a folder for your solutions anywhere (for example solutions/java/).
2. Write the program. Read the whole input from stdin; print only what the problem asks for — no prompts like "Enter n:".
3. Try it on an example by hand: python3 e01.py < tests/E01/01.in (any test file works).
4. Run every test at once with the runner (below), or paste your output into the checker on the problem page.

The test runner

Two equivalent runners live in runner/; use whichever you have installed (Python 3.8+ or Node 18+). Run them from the problems folder and put the command that runs your program after --:

Options: --timeout 5 (seconds per test, default 10) and --stop (stop at the first failure). A failing test shows the first line that differs:

The runner's exit code is 0 only when every test passes, so it also works in scripts and CI. Hard problems include large tests: an O(n²) solution may hit the time limit where O(n log n) is expected.

Input/output templates

Each template solves the same demo task (it isn't one of the problems), so you can see how reading and printing work in your language:

Reading line by line

Most problems can be read as a stream of tokens. Read whole lines when a line may contain spaces or be empty (e.g. M01 Balanced Brackets, E04 Reverse a String, O13 Text Editor): in Python sys.stdin.read().split("\n"), in JavaScript readFileSync(0, 'utf8').split('\n'), in Java in.readLine(), in C++ getline(cin, line) (after cin >> q, skip the rest of that line first with cin.ignore()).

The OOP command loop

Every object-oriented problem has the same driver: read q, then for each command line, split it into words and call a method on your objects. Keep the driver thin: the classes do the work and return results; the driver only parses and prints.

Common pitfalls

• Integer overflow. Constraints tell you when results exceed 32 bits — use long/long long/BigInt. Python integers never overflow.
• Integer division. E01 and the calculators use division that truncates toward zero, like Java and C++. Python's // and JavaScript's Math.floor round toward −∞ instead.
• Floating point. When a problem prints decimals it says exactly how (e.g. two decimals). Money problems use whole cents — never floats.
• Tie-break rules. Many problems define which answer to print when several are valid (“smallest index first”, “lexicographically smallest”). Read them carefully — they're part of the problem.
• Slow I/O. For 10⁵+ numbers, use the fast patterns above (buffered reading, one big print).
• Extra output. Debug prints break the comparison: send them to stderr (print(..., file=sys.stderr), console.error, System.err, cerr) — the runner ignores stderr.

A suggested path

• New to the language: E01–E25 in order — they cover I/O, loops, strings, lists and maps.
• Then M01–M25: stacks, hashing, two pointers, sorting with custom orders, recursion.
• H01–H25 are classic interview-level algorithms; aim for the complexity the constraints imply.
• For Java, C++, C#, Kotlin, TypeScript…: do O01–O25 to practise classes, interfaces, inheritance, generics and design patterns. Solve each one twice: once quickly, then refactor the design.