Being asked to solve a small problem while someone watches, sometimes typing on a shared screen, is one of the more stressful parts of a junior interview. Most of that stress comes from one specific and fixable habit: trying to work in silence.
An interviewer watching you code in total silence has almost no information about how you're thinking — only whether you eventually land on a working answer. That means every pause reads as being stuck, even when you're actually reasoning productively. Narrating your thinking gives them something to evaluate other than the final result, which is usually to your advantage, not a distraction from it.
Clarify what's actually being asked → think through the approach out loud before typing → start with something simple that works, even if not optimal → improve it if there's time, narrating why. A basic, working, clearly explained answer beats a clever, silent one that only half works or that nobody watching could follow.
It is completely acceptable to say "let me think for a second" and pause deliberately. A short, announced pause reads entirely differently from an unexplained silence — the first is composed, the second reads as stuck.
Say so plainly, then apply the honest-reasoning structure from the previous lesson: what you've tried, what you think the actual problem is, and what you'd try next. An interviewer who sees a candidate work through being stuck systematically often comes away more confident than they would from someone who happened not to hit any difficulty at all.
Solve small practice problems while talking through your reasoning out loud, alone or with a friend listening — the narration is the actual skill being built here, not the problem-solving itself, which you've mostly already practised elsewhere in your coursework.