Two candidates write the same correct solution. One gets the offer. The difference is almost always communication: interviews are a proxy for working with you, and the interviewer can only evaluate the reasoning you make visible. Silent brilliance reads as luck; narrated reasoning reads as a colleague. This is a skill you can practise deliberately.
Lead with the headline
Before you dive into detail, say the shape of your plan in one sentence: “I’ll use a hash map so lookups are O(1), trading some memory for speed.” This orients the interviewer, lets them redirect you early if you have misread the problem, and demonstrates that you think in approaches, not just steps. Then fill in the detail underneath the headline. The same habit works in a design round: state the architecture in a sentence before you draw the boxes.
Narrate structure, not a monologue
“Think out loud” is good advice that people over-apply into an anxious stream of consciousness. The useful version is narrating your decisions: what you are choosing, and why, and what you are ruling out. “I could sort first, but that is O(n log n); a set gets me there in O(n), so I’ll do that.” You do not need to voice every keystroke — you need to voice every fork in the road. That is the reasoning the interviewer is there to hear.
Stay unstuck, out loud
Getting stuck is not the failure; going silent is. When you are stuck, say what you are stuck on: “I know I need to detect a cycle, I’m deciding between a visited set and fast/slow pointers.” This does two things. It keeps you scored on visible reasoning even when the answer has not arrived, and it gives the interviewer a place to nudge you — they can help a candidate who is thinking aloud and can do nothing for one who has frozen. A good habit: when stuck, retreat to the brute force and say so. A working slow solution beats an elegant one that never appears.
Talk about trade-offs like a senior
Junior answers present one solution as simply correct. Senior answers name the cost: “This is faster but uses O(n) extra memory,” or “This is simpler to read but re-renders more than it needs to — in a hot path I’d memoise it.” Volunteering the downside of your own choice is one of the strongest signals you can send, because real engineering is choosing among imperfect options, not finding the one right answer. If you are asked to defend a decision, that is an invitation, not an attack — state the trade-off plainly.
Close the loop
Do not trail off into “yeah, so, that’s it.” Finish deliberately: dry-run the code on an edge case, catch your own off-by-one if there is one (catching your own bug reads as a strength), and restate the time and space complexity. A clean close leaves the interviewer with the impression that you are thorough — the same impression a good pull request leaves on a reviewer.
You cannot rehearse this by reading; you rehearse it by talking through problems. Take any question from the collection — the “Copy as prompt” button turns each one into a ready-made drill for an AI interviewer — and for the algorithm round specifically, pair this with the process in how to approach any DSA problem.