← Mindset · guided lesson
Mindset & Problem Solving
the story
A problem-solving routine (Pólya → UMPIRE)
Every tool here exists because something was too slow or broke without it. Here is what.
In How to Solve It (1945), the mathematician George Pólya turned problem solving into a checklist. Its four headings: understanding the problem, devising a plan, carrying out the plan, looking back. CodePath's UMPIRE interview strategy — Understand, Match, Plan, Implement, Review, Evaluate — follows the same arc for coding rounds, adding "match it to a known pattern" and "evaluate the cost".
the problem it solved
Freezing in front of an unfamiliar problem: a routine always gives you a next step that needs no flash of genius.
why it matters: without it
You jump into code, solve the wrong problem, or hit a wall at minute 20 with nothing on the board — and panic makes it worse.
sources: Princeton University Press — How to Solve It (G. Pólya) ↗ · G. Pólya, How to Solve It — Penguin edition sample (contents: the four phases) ↗ · CodePath — UMPIRE Interview Strategy ↗
also in this chapter: Brute force first, then remove the bottleneck · Dry run (trace table) · Stress testing against a brute force
the idea
The idea in 30 seconds
Interview problems aren't solved by flashes of genius. They're solved by a routine you run every time: understand → brute force → improve → code → test.
A correct slow answer is worth far more than a fast answer you can't finish. Start slow, then make it fast.
Practice is about patterns, not memorised code: after roughly 150 well-reviewed problems (a common rule of thumb, not a study), most new questions look like old friends.
picture this
When a production server goes down at 2 a.m., a good on-call engineer doesn't improvise — they open the runbook: read the alert, reproduce, find the cause, fix, verify. UMPIRE is your interview runbook: under pressure you just do the next step.
watch it
Dry run — the trace table
Predict mode is on. Before each step, guess what happens, then watch. Wrong guesses are fine; that is how it sinks in.
Dry run — the trace table
Fill one row per loop iteration. Try n = 1230 and notice what happens to the trailing zero.
On this screen ← / → step the simulation. Use the buttons below to move through the lesson.
watch it
Brute force first: every pair
Predict mode is on. Before each step, guess what happens, then watch. Wrong guesses are fine; that is how it sinks in.
Brute force first: every pair
Each lit cell is one pair checked. The triangle grows like n²/2 — that's the bottleneck to remove.
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.
UMPIRE: Understand (restate, ask, examples) → Match (which pattern?) → Plan (brute force, then better) → Implement → Review (dry run) → Evaluate (complexity, trade-offs).
key idea 2 of 8
Read it once. Say it out loud once. Bas.
Constraints are hints. n ≤ 20 allows 2ⁿ; n ≤ ~5,000 allows n² comfortably (10⁴ is borderline); n ≤ 10⁵–10⁶ needs O(n log n) or O(n). Read them before choosing an idea.
key idea 3 of 8
Read it once. Say it out loud once. Bas.
Brute force first, out loud. It proves you understand the problem, gives you a fallback, and is often the starting point the optimal answer improves.
key idea 4 of 8
Read it once. Say it out loud once. Bas.
Find the bottleneck: ask "which step repeats work?" then pick a data structure that makes that step fast (HashMap for lookups, sorting for order, a heap for the minimum…).
key idea 5 of 8
Read it once. Say it out loud once. Bas.
Dry run with a table: one row per iteration, one column per variable. It catches off-by-one and edge-case bugs before the interviewer does.
key idea 6 of 8
Read it once. Say it out loud once. Bas.
Edge-case checklist: empty, one element, two elements, all equal, negatives/zero, already sorted, duplicates, max values (overflow).
key idea 7 of 8
Read it once. Say it out loud once. Bas.
Talk while you think. Silence looks like being stuck; narration lets the interviewer help and gives you credit for reasoning.
key idea 8 of 8
Read it once. Say it out loud once. Bas.
Practice smart: time-box with the 20-minute rule, re-solve with spaced repetition (1 → 3 → 7 → 16 → 35 days, the same ladder as the recall cards), and keep a log of why you got stuck.
spot the pattern
When you see this, think this
"Find two/k items that add up to / match something"
HashMap of what you've seen (or sort + two pointers)
Input is sorted
Binary search or two pointers
Contiguous subarray / substring with a condition
Sliding window or prefix sums
"Top k", "k-th largest", "closest k"
Heap (PriorityQueue)
+4 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.
- Coding before you understand: the #1 reason for wrong answers. Restate the problem and run one example by hand first.
- Skipping the brute force because it feels "too easy" — then freezing with nothing on the board.
quick check
One question. No pressure.
What does the "M" in UMPIRE stand for?
now try
Your first real problem
You know enough to try this one. Stuck? Use the hints; that is what they are for.
Running Sum of 1d Array
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.
You read a new problem and your mind goes blank. What exactly do you do in the first two minutes?
Question 1: You read a new problem and your mind goes blank. What exactly do you do in the first two minutes?
done
Lesson complete
Chalo, that is the core. The full chapter has the rest: cost tables, Java details and more problems.