The round felt fine. You solved two of the three problems, your code ran, and the interviewer said "thanks, we will get back to you". The feedback that reaches you later says "poor communication", "could not explain the approach", or "not able to collaborate". You reread your own code and it is correct, which makes the note look unfair. Nobody told you that a correct answer can lose.
A live coding round on a shared screen or a shared editor, 45 to 90 minutes, one or two interviewers watching. Most common for candidates who prepared by solving problems alone with headphones on, and for candidates who speak English fluently in conversation but go quiet the moment they are thinking hard. It also shows up in the pair-programming stage of GCC and product interviews. Linked module: 6.3 (Coding round for AI roles).
From the other side of the screen, a thinking candidate and a stuck candidate produce exactly the same signal: a cursor that is not moving and a person who is not speaking. The interviewer cannot see your reasoning, so they cannot mark it. Everything you worked out in your head between minute 4 and minute 22 is, for scoring purposes, work that never happened.
There is a second cost that students miss. A wrong assumption made in silence runs all the way to the end. Said out loud at minute two, the interviewer would have corrected it in four words. Silence turns a five-second fix into a twenty-minute detour, and the detour is the thing that runs you out of time.
Three habits produce the silence. The first is treating the interview like an online judge, where only the final submission counts. The second is a fear of sounding wrong, so nothing is said until it is certain. The third is language worry: the belief that a half-formed English sentence is worse than no sentence. All three are wrong on the same point. The interviewer is scoring your process, and process that is not spoken does not exist for them.
Attach a sentence to each of the five protocol steps, and say it whether or not you feel ready. These are the sentences; put them on a card and rehearse them until they come out without thought.
1. Restate. "Let me say the problem back to you. I have transactions and a store master, and I need one row per city with the count, the failures and the rate, keeping cities with at least three transactions. Is that right?"
2. Assume. "I am going to assume the store id is unique in the master, and I will check that rather than trust it. I will treat a missing status as unknown and not as a failure. Tell me if either is wrong."
3. Brute force. "I will write the obvious slow version first so we have something correct on the screen, then improve it. This loops over every row and counts, which is fine but wordy."
4. Improve and cost it. "This version is one pass, so it is O(n) in the number of rows. The earlier one rescanned per key, so it was O(n times k)."
5. Test. "Before I say done, I will run my checklist out loud: empty input, one row, duplicates, nulls, unsorted, and a huge input. Empty gives zero rows, which is what I want."
For the gaps in between, keep four filler sentences that are honest and buy you thinking time: "Let me think about this for thirty seconds." / "I am comparing two approaches: a dictionary pass or a sort." / "I tried grouping first and dropped it, because the join has to come first." / "I am stuck on the tie-break rule. My next move is to test what happens with two equal counts."
If you have gone quiet for more than about twenty seconds, say something. It does not need to be a conclusion. "I am still on the assumption about duplicates" is a full sentence and a full mark.
Practise out loud from day one, even when alone, because the skill is physical and not intellectual. Record yourself solving two problems a week and play the audio back, marking every silence over twenty seconds with the sentence you should have said. Do at least four mock rounds with another person, and ask them for one number only: minutes of silence. English polish is not the target and never has been; short plain sentences score the same as elegant ones. If you freeze under a watcher, start every practice session by saying the restatement aloud before your hands touch the keyboard.
Q: "Walk me through how you approach a problem you have not seen before." Strong answer: name the five steps in order and give a real example of an assumption you stated early that turned out to be wrong, and what it saved. Interviewers use this question to predict what the coding round will feel like, so the answer to give is the one you can then demonstrate ten minutes later. Weak answers describe a feeling ("I analyse the problem carefully"); strong answers describe an order of operations and admit that the first version is deliberately the slow one.