Wie man es löst
Eine wiederholbare Methode für jedes Interviewproblem - klären, Beispiele, Brute Force, optimieren, coden, testen - und wie man dabei laut denkt.
Deutsche Übersetzung in Arbeit
Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.
Auf dieser Seite
The hardest part of an algorithm interview isn't knowing the answer - it's not freezing when you don't. The engineers who pass aren't the ones who instantly see the trick; they're the ones with a method they can fall back on every time. This lesson gives you that method, so a blank problem becomes a series of small, calm steps.
The method: clarify → examples → brute force → optimize → code → test
Every good problem-solver, whether they know it or not, runs roughly this loop:
- Clarify — restate the problem in your own words. What are the inputs, the output, the constraints? What about empty input, duplicates, negatives, huge sizes? Ask before you assume.
- Examples — work one small example by hand, and one tricky edge case. This is where you actually understand the problem, and where interviewers see how you think.
- Brute force — state the obvious, slow solution out loud. It proves you understand the problem and gives you something to improve. A working O(n^2) beats a broken O(n).
- Optimize — now look for a better approach: a pattern, a data structure, a way to avoid repeated work. Ask "what am I computing more than once?"
- Code — write it cleanly, narrating as you go. Small helper methods, clear names.
- Test — walk your code through your examples, especially the edge cases from step 1.
Think out loud - it's half the interview
Interviewers are hiring a colleague, not a compiler. A silent candidate who writes the perfect answer often scores worse than one who talks through a decent one. Narrate your clarifying questions, your brute force, and why you reach for a particular data structure. The story of your thinking is the thing being graded.
Optimize by naming the wasted work
Almost every "clever" algorithm is just the brute force with one insight bolted on: stop redoing work. The two-pass array scan, the hash map that remembers what you've seen, the sorted input that lets you skip - all of them answer the same question: what is this brute force recomputing that it could remember or avoid?
// brute force: for each element, re-scan the rest → O(n^2)
for (int i = 0; i < n; i++)
for (int j = i + 1; j < n; j++)
if (a[i] + a[j] == target) return new int[]{i, j};
// insight: a hash map remembers what we've seen → one pass, O(n)
Map<Integer, Integer> seen = new HashMap<>();
for (int i = 0; i < n; i++) {
if (seen.containsKey(target - a[i])) return new int[]{seen.get(target - a[i]), i};
seen.put(a[i], i);
}Asked to find a word, you don't read the dictionary front to back (the brute force). You exploit its structure - it's sorted - and jump to roughly the right page, then narrow down. Every algorithmic optimization is the same move: find the structure in the problem (sorted input, a repeated subproblem, a bounded range) and exploit it so you can skip work the brute force repeats.
Given an array and a target, return indices of two numbers that add to the target. Don't jump to the answer - practice the method: name one clarifying question you'd ask, give a small example, state the brute force and its complexity, then the one insight that makes it O(n).
In the problem-solving method, why state the brute-force solution before optimizing?
Key takeaways
- Interviews reward a repeatable method, not instant brilliance: clarify, examples, brute force, optimize, code, test.
- Clarify inputs, outputs, and edge cases before coding - ask, don't assume.
- State the brute force first: it proves understanding, gives a baseline, and reveals the repeated work to remove.
- Most optimizations are one insight over the brute force - stop recomputing, via a data structure, sorted order, or a remembered value.
- Think out loud: the interviewer is grading how you reason, not just the final code.