← I/O & Debugging · guided lesson
Fast I/O, Judges & Debugging
the story
Standard input and output
Every tool here exists because something was too slow or broke without it. Here is what.
Early Unix gave every program two ready-made files: standard input and standard output (file descriptors 0 and 1). The shell's < and > swapped them for files, so a program never needed to know where its data came from. Pipes appeared in 1972 at Doug McIlroy's suggestion, chaining one program's output into the next one's input. Online judges use exactly this: the test file becomes your stdin, and your stdout becomes a file they compare.
the problem it solved
Programs could be combined and tested without changing their code — just by redirecting where input comes from and where output goes.
why it matters: without it
Every program would need to know file names, and a judge couldn't run any submission the same way.
sources: Dennis M. Ritchie, The Evolution of the Unix Time-sharing System (1979; BLTJ 1984) ↗
also in this chapter: Fast input and output in Java · Online judges and verdicts · Exceptions and the call stack · Assertions (assert) · Debugging and testing your own code
the idea
The idea in 30 seconds
On LeetCode a hidden driver calls your method. In many online assessments there is no driver: you read the input from stdin yourself and print the answer to stdout.
Either way a judge runs your code on hidden tests with a time limit and answers in one word: AC, WA, TLE, RE or MLE.
This chapter teaches you to read and print fast, decode those words, and catch your own bug before the judge — or the interviewer — does.
picture this
A judge is like booking an IRCTC Tatkal ticket: the form must be exactly right, and it must arrive before the window closes. A perfect form submitted late still gets nothing — that's a TLE.
watch it
How a judge runs one test
Predict mode is on. Before each step, guess what happens, then watch. Wrong guesses are fine; that is how it sinks in.
How a judge runs one test
Try the submissions `off-by-one`, `crash`, `no-flush` and `slow` to see where each verdict comes from.
On this screen ← / → step the simulation. Use the buttons below to move through the lesson.
watch it
An exception unwinding the call stack
Predict mode is on. Before each step, guess what happens, then watch. Wrong guesses are fine; that is how it sinks in.
An exception unwinding the call stack
A bad token deep inside `parseRow` throws. Frames without a matching `catch` are discarded until `total` catches it.
On this screen ← / → step the simulation. Use the buttons below to move through the lesson.
key idea 1 of 8
Read it once. Say it out loud once. Bas.
Two judging styles: LeetCode calls your method on class Solution. Stdin (OA) mode runs your main, feeds the test on System.in, and compares what you print.
key idea 2 of 8
Read it once. Say it out loud once. Bas.
Fast input: BufferedReader + StringTokenizer (the FastReader template). Scanner is fine for small inputs, but was about 4× slower at 10⁶ numbers in our measurement.
key idea 3 of 8
Read it once. Say it out loud once. Bas.
Fast output: collect lines in a StringBuilder or PrintWriter and write once — and always flush(). println per line flushes every single time.
key idea 4 of 8
Read it once. Say it out loud once. Bas.
Budget first: ~10⁸ simple steps per second is the rule of thumb. Read n in the constraints and pick the complexity before you code.
key idea 5 of 8
Read it once. Say it out loud once. Bas.
Verdicts are diagnoses: WA = wrong output, TLE = too slow, RE = crashed, MLE = too much memory, CE = didn't compile.
key idea 6 of 8
Read it once. Say it out loud once. Bas.
Exceptions travel up the call stack to the nearest matching catch; every frame in between is abandoned. The stack trace is a map to your bug.
key idea 7 of 8
Read it once. Say it out loud once. Bas.
Debug in this order: shrink the failing input → dry-run it → print to System.err or set a breakpoint → assert your invariants (java -ea).
key idea 8 of 8
Read it once. Say it out loud once. Bas.
Test before the judge does: the samples, then edge cases you choose on purpose, then a stress test against a brute force.
spot the pattern
When you see this, think this
"Input: the first line has n, the next line has n integers"
Stdin mode: FastReader template in, StringBuilder or PrintWriter out
"Read until the end of input" / no count given
readLine()loop until it returns nulln up to 10⁵–10⁶ in the constraints
Need O(n log n) or better — and fast I/O in stdin mode
TLE, but your algorithm is O(n)
Suspect Scanner or println-per-line before the algorithm
+3 more signals on the chapter page
watch out
A trap or two
Many wrong answers in interviews come from small slips like these, not from the hard part.
- Forgetting
out.flush()(orout.close()) with a PrintWriter: empty output, WA with correct logic. nextInt()followed bynextLine()returns "" — the rest of the number's line.
quick check
One question. No pressure.
Your PrintWriter solution prints nothing on the judge but the logic is right. What did you forget?
now try
Your first real problem
You know enough to try this one. Stuck? Use the hints; that is what they are for.
First Unique Character in a String
Submit the O(n²) version once: its 50,000-char hidden test shows you a real TLE.
open the problem →recall
Flip a few cards
Answer in your head first, then flip. Grade yourself honestly; the schedule brings back what you forget.
Your PrintWriter solution prints nothing on the judge. Why?
Question 1: Your PrintWriter solution prints nothing on the judge. Why?
done
Lesson complete
Chalo, that is the core. The full chapter has the rest: cost tables, Java details and more problems.