Troubleshooting

Most "it should work!" moments have a short, specific cause. Here are the ones we see most, and how to read your way out of them.

"My Run passed but Submit failed"

This is the single most common one, and it almost always means your code is correct on the visible samples but not on the hidden suite — which deliberately includes the cases the samples leave out:

• Edge cases — empty input, a single element, all-equal elements, negatives, the maximum value, an empty string, null where it's allowed.
• Scale — inputs large enough that an inefficient solution times out even though it's logically right. If the failing test name mentions a large n, this is your problem; see Writing fast C#.

The fix is to stop trusting the samples. Before you Submit, run your solution in your head against the nastiest small input you can think of.

A test says Timeout

A timeout means your code exceeded the per-test time budget — it ran, it may even be correct, but not fast enough. Nine times out of ten the cause is complexity, not a slow line. An O(n²) approach on a large hidden input cannot be tuned into passing; it has to become O(n log n) or O(n). Start with the three questions in Writing fast C#.

A test says Error

The grader caught an unhandled exception. The result shows the exception type and message — read it first, it's usually decisive:

Exception	Usual cause
NullReferenceException	An input or intermediate value was null and you dereferenced it.
IndexOutOfRangeException	An off-by-one, or you assumed a non-empty collection.
ArgumentException / FormatException	Parsing input that isn't in the shape you assumed.
OverflowException or a wrong huge number	An int that should have been a long.
StackOverflowException	Unbounded recursion — add the base case or go iterative.

It won't compile

Compile errors come back with the full compiler diagnostics, and they show up inline in the editor as red underlines. A few platform-specific gotchas, beyond ordinary typos:

• You renamed Solution or the entry method. The grader binds to them by name — keep the class and method signature exactly as the starter gives them. See The editor & runtime.
• A missing using. Implicit usings aren't on; add the namespace yourself at the top.
• You reached for a NuGet package or unsafe. Neither is available — the base class library only, and unsafe is disabled by design.
• You wrote a Main / top-level statements. Submissions are a library; put the logic in the method instead.

The hidden test won't show me its input

That's intentional, not a bug. Hidden tests reveal only their name, pass/fail, and timing — never the input, expected output, or your output — so the suite can't be reverse-engineered. The test names are written to be honest hints (Large input (n = 200,000), must be O(n)). Read the name; it's pointing at the case you're missing.

My console output disappeared

Console.WriteLine output is shown when you Run, next to the return value. Submit hides it — grading reports pass/fail, timing, and allocations, not your trace. If you need to see what your code printed, Run it.

My code reset itself

Your in-progress code autosaves per puzzle, in this browser. Two things clear it: hitting reset (which deliberately restores the original starter), and clearing your browser's site data (which wipes the local save). If a puzzle looks blank when you expected your work, you most likely reset it — reach for reveal solution to study a correct version, then try again.

Still stuck?

If something looks genuinely wrong — a test you're convinced is mis-graded, a puzzle that won't load — email [email protected] with the puzzle name and what you saw. Real bug reports make the platform better.