How do you narrate your thinking in an interview without either rambling or going dead silent?
I've got two failure modes. Either I go completely quiet while I think and the interviewer has no idea if I'm stuck or cooking, or I over-explain every micro-thought and run out of time.
I know 'communicate your thought process' is the advice, but nobody says how much. What does the good middle actually sound like? Do you state the plan first and then narrate as you code, or something else?
2 comments
- 0
AnonymousAnon The ramble-or-silence trap is so real. What helped me: narrate in headers, not a stream. "First I'll clarify the input, then a brute force, then optimize" — say the plan, then execute it out loud. Gives the interviewer a map and gives you a structure so you don't spiral.
- 0
AnonymousAnon State the plan out loud first ('I'll start brute force to confirm I understand the problem, then optimize'), then narrate decisions, not keystrokes. Nobody needs to hear 'now I write a for loop' — they want to hear why you reached for the hashmap. And when you do need to think, just say 'give me a sec here' so they know you're not frozen.