Dein Denken kommunizieren
Das Interview ist ein Gespräch, kein Test: wie man erzählt, gute Klärungsfragen stellt und den Interviewer einbezieht, sodass er dir Erfolg wünscht.
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
Two candidates solve the same problem. One gets the offer; the other doesn't. The difference often isn't the code - it's that the first treated the interview as a collaboration and the second treated it as a silent exam. This lesson is about the single highest-leverage interview skill: communicating your thinking so the interviewer becomes your ally.
The interviewer is a future colleague, not a judge
An interviewer is trying to answer one question: "do I want to work with this person on hard problems?" Your code is evidence, but so is how you think out loud, handle hints, and respond to feedback. A candidate who narrates a decent solution usually scores higher than a silent one who writes a perfect one - because the narration shows the collaboration the job actually requires.
Narrate the method
Use the problem-solving method from the DSA modules out loud:
- Clarify first. Restate the problem and ask about edge cases, input size, and constraints before writing anything. "Can the array be empty? Are there duplicates? Roughly how large is n?" This shows rigor and often reveals the intended approach.
- State your plan before coding. "I'll start with the brute force - nested loops, O(n²) - then I think a hash map gets us to O(n). Let me confirm that direction before I code." Now the interviewer can course-correct before you write the wrong thing.
- Think aloud while coding, but don't narrate every semicolon - explain the decisions: "I'll use a HashSet here so membership is O(1)."
- Test out loud at the end, walking your examples through the code.
Treat hints as gifts
When an interviewer offers a hint, they're helping you, not catching you out. Grab it, incorporate it visibly, and thank them. Candidates who get defensive or ignore hints signal exactly the wrong thing; candidates who integrate feedback gracefully signal a great teammate.
Silence is the most common failure mode
The number-one interview mistake isn't a wrong algorithm - it's going quiet for five minutes while you think. The interviewer can't tell whether you're making progress or stuck, and they can't help. If you need to think, say so: 'Let me think about the data structure for a moment.' Then share the options you're weighing. Externalize the process.
An algorithm interview feels like a written exam - solve the problem, get the marks - but it's really a driving test. The examiner isn't only checking whether you reach the destination; they're watching how you check mirrors, signal your intentions, respond when they say 'take the next left,' and stay calm at a tricky junction. A driver who reaches the destination recklessly and silently fails; one who navigates a slightly longer route while communicating clearly and adjusting to instructions passes. Narrate your driving.
Imagine you're given 'find two numbers in an array that sum to a target.' Instead of silently coding the hash-map solution, script the first 60 seconds of what you'd say out loud - from receiving the problem to starting to code.
Why does narrating your thinking often matter more than writing the optimal solution silently?
Key takeaways
- An interview is a collaboration, not a silent exam - the interviewer is assessing you as a future colleague.
- Narrate the method out loud: clarify and ask about edge cases first, state your plan before coding, then explain decisions as you go.
- Confirm your approach before writing it, so the interviewer can course-correct early.
- Treat hints as help - integrate them visibly and gratefully; getting defensive signals the wrong thing.
- Silence is the top failure mode: if you need to think, say so and share the options you're weighing.