Module 1
The problem-solving method
A live coding problem isn't a test with an answer key — it's a pair-programming session with a stranger, and the main thing being evaluated is whether your thought process is one they'd want on their team. The single biggest failure mode is silence: diving into code before the problem is understood, then debugging quietly while the interviewer watches a cursor blink. A method fixes that, because it gives you something true to say at every moment.
The six steps, in order:
- 1
Restate & clarify. Say the problem back in your own words, then ask about edges before they bite: empty input? duplicates? negative numbers? sorted or not? what should I return on no-solution? Two minutes here buys back twenty.
- 2
Work an example by hand. Pick a small input and produce the answer manually on paper. If you can't do it by hand, you can't code it — and the example becomes your test case later.
- 3
Name the brute force. Out loud, with its complexity: “The obvious approach checks every pair — that's O(n²). Let me see if we can do better.” This proves understanding and banks a working fallback. Never skip it, never apologize for it.
- 4
Optimize out loud. Interrogate the brute force: what work repeats? Would sorting help? Can a hash map make a lookup O(1)? Can two pointers replace the inner loop? Pattern-match against the structures you know, and narrate the dead ends too — rejected ideas with reasons are signal, not noise.
- 5
Code it cleanly. Real names (seen, left, right — not x1, x2), small helper functions, handle the edge cases from step 1. Talk while typing: “storing each value's index as I go, so the lookup later is constant time.”
- 6
Test it yourself — before being asked. Trace your step-2 example through the code line by line, then try an edge case. Finding your own bug is worth more than having none.
🎛 The method on the classic warm-up: two-sum
Find two numbers summing to 17 in [11, 3, 8, 15, 6, 2, 9].
This is the canonical “can you do better?” arc: name the brute force first (it proves you understand the problem), then trade memory for time with a hash map. Walking both, out loud, is the whole game.
Say it out loud
- “Before I code — can the array contain duplicates, and is it sorted?”
- “Brute force is every pair, O(n²). The repeated work is searching for the complement — a hash map makes that O(1), so one pass does it.”
- “That trades O(n) extra memory for the speedup — fine unless memory is constrained.”
- “Let me trace my example through before I call it done.”
If you get stuck
Stuck is a normal state, not a failed one. Return to your hand-worked example and narrate what your brain is doing to solve it — the algorithm is usually hiding in there. Try a smaller input. Say which part is unclear (“I know I need fast membership checks here; I'm deciding between a set and sorting first”). Interviewers routinely drop hints, and using a hint well — taking it, running with it, connecting it — reads as collaboration, which is precisely the skill being interviewed.