Technical Interviews in English as a Non-Native Speaker

Why it costs points that are not about English

Interviewers are not scoring your language. They are scoring how quickly you understand a problem, how clearly you reason out loud, and how you respond to a hint. Every one of those signals travels through language — so a two-second delay while you translate reads, from the other side of the call, exactly like hesitation about the algorithm. The interviewer has forty-five minutes and no way to tell the difference. They write down “slow to grasp the problem”, and they are not being unfair. They are reporting what they saw.

This is why the fix is not “improve your English”. Your English is already sufficient. The fix is removing the specific places where language competes with thinking for the same few seconds.

The three places it actually breaks

Missing part of the question. Interviewers speak fast, with an accent you may not have trained on, using idioms that never appear in documentation — “ballpark it”, “off the top of your head”, “let us punt on that”. You catch eighty percent, reconstruct the rest, and start solving a subtly different problem. Ten minutes later you are deep in the wrong direction and it is expensive to come back.

Translating instead of thinking. Under pressure many people compose the sentence in their first language and render it into English. That is two jobs running on the same working memory that is supposed to be holding the algorithm. The algorithm loses.

Vocabulary blanks mid-sentence. You know exactly what you mean, and the word for it is gone. You stop, restart the sentence, apologise. The content was correct; the delivery signalled uncertainty.

Fix one: make restating the question routine

Open every problem the same way, out loud, before you write anything: “Let me restate it to make sure I have it — we get an array of intervals, possibly unsorted, and we return the merged set. Should I assume they fit in memory?” This takes twenty seconds and does four things at once. It catches the twenty percent you missed. It buys you thinking time that looks like diligence rather than delay. It signals a habit senior engineers have. And it converts a listening problem into a speaking problem, where you control the pace.

Crucially, it is not an admission of weak English. Native speakers who do this are called thorough. Do it every time and it never reads as a language issue.

Fix two: pre-load about forty phrases

Technical interview English is a small, closed vocabulary. You do not need general fluency — you need instant access to roughly forty phrases, and they are the same ones every time. Write your own list, say it out loud until it is automatic:

• Framing: “My first thought is the brute-force approach, then I will improve it.” “Let me walk through a small example.” “I will come back to edge cases once the main path works.”
• Complexity: “That is linear in the number of elements and constant extra space.” “We are trading memory for lookup time.”
• Recovering: “Give me a second to think.” “Let me reconsider — I think there is a cleaner way.” “I do not remember the exact library call, but the idea is…”
• Asking: “Can you say that once more?” “When you say sorted, do you mean by start time?”

Forty phrases is an evening of work. It removes almost every blank, because the blanks cluster in the same handful of moments.

Fix three: short sentences, always

Non-native speakers under stress often attempt long subordinate clauses, run out of grammar halfway, and restart. The restart is what sounds uncertain, not the accent. Deliberately speak in short declarative sentences: “This is O of n squared. That is too slow. I will use a hash map. Now it is linear.” Nobody in the history of technical hiring has been marked down for speaking plainly. Plenty have been marked down for trailing off.

On accent, speed, and asking people to slow down

Asking an interviewer to repeat something is not a penalty. Doing it four times in a row without explanation starts to feel like one, so frame it once at the start: “Quick note — English is not my first language, so I might ask you to repeat something. It is not the problem, it is the audio.” In practice interviewers respond well to this, slow down slightly, and stop reading pauses as confusion. It costs one sentence and reframes everything that follows.

If the round is remote, the audio itself is often the real culprit. Wired headphones, a quiet room and a stable connection remove more comprehension errors than any amount of vocabulary work.

Where real-time assistance fits — and where it does not

Tools that transcribe or assist during a call genuinely help with the comprehension half of this problem: seeing the question in text while it is being spoken removes the “I caught eighty percent” failure entirely, and terminology support closes the vocabulary blanks. That is a real accessibility gain, and it is the part of the problem that is purely linguistic.

What no tool fixes is the reasoning. The interviewer will ask why you chose that data structure, and will ask it as a follow-up to whatever you just said. If you deliver an answer you cannot defend, the follow-up exposes it immediately and you are worse off than if you had reasoned slowly in your own words. Use assistance to understand the question and to find the word. Do the thinking yourself — that is the part being graded, and it is also the part you are already good at.

What to practise this week

Record yourself solving two medium problems out loud in English, forty minutes total. Then listen back — which is unpleasant and the entire point. Count the restarts and the blanks. They will cluster around four or five recurring situations. Write the phrase you needed for each, and rehearse those. Most people find their list is shorter than they feared, and that two evenings of it changes how the next interview sounds.

Read next