Coding rounds are frequently described as unrepresentative, and they partly are — but what they measure well is whether you can make progress on an unfamiliar problem while thinking out loud, which is most of the job.

• Restate the problem and confirm. Cheap, and it catches the misunderstanding that would otherwise cost you the whole round.
• Say your approach before writing. Silence is the most common way strong candidates fail — the interviewer cannot give credit for reasoning they cannot hear, or redirect you before you have spent fifteen minutes.
• Start with something that works. Brute force, stated as such, beats an elegant thing that does not compile. Then improve it and say what you improved.
• Test it yourself, out loud, on the empty case, the single-element case and one real case, before being asked.
• If stuck, narrate the stuckness. ‘I think this needs a different data structure because lookup is O(n) here’ keeps you scored while you think.

The habit that separates people is refusing to guess. Form a hypothesis, decide what observation would falsify it, and make that observation — rather than changing something and seeing if it helps, which is how you fix symptoms and introduce two new bugs.

Bisect aggressively: in time (when did this last work), in space (which layer), and in input (what is the smallest case that reproduces it). And when identical comparators exist — another host, another environment, another user — diff them mechanically rather than reasoning about what might differ. That single move resolves more incidents than any amount of insight.