How to explain code and technical decisions in English

Narrate decisions before and while you type: the approach, the data structure, and the trade-off. Interviewers cannot score reasoning they cannot hear. Short sentences beat polished silence.

Restate the problem, ask about constraints, edge cases, and output format, then confirm the plan. A short phrase bank keeps clarifying questions confident when you are translating under pressure.

Name the next tiny step: “I am checking the empty input,” then type. A bridging phrase is better than a long pause. If you are stuck, say the two options you see and pick one. Panels help candidates who stay audible.

After one example, say time and space in one sentence each: “This is O of n time and O of 1 extra space because we scan once and reuse two pointers.” Then invite edge cases. Do not apologise for the numbers.

No. You need to restate the problem, narrate an approach, and explain complexity. Candidates fail when they solve silently or cannot discuss a bug. Accent and small grammar errors almost never decide the round.

Say what you expected, what you see, and the first place you will look. “I expected 3, got 2, so the last element is off. I will check the loop bound.” Keep the interviewer in the diagnosis. Silent staring at red tests looks like panic.

Yes. “I want to make sure I heard the constraint on duplicates — could you say that part again?” That sounds professional. Guessing the problem in a second language is how people solve the wrong question.

At home you can stay quiet. In the room, speech is the product. Practise the English of clarify → approach → code → complexity on a timer. A slower correct narration beats a fast silent solution they cannot follow.