Technical Interviews in English: A Guide for Software Engineers

Plenty of engineers can solve the problem. The trouble starts when they have to solve it while speaking English. Half your brain is on the algorithm, the other half is hunting for words. The result is either a long silence or an explanation that goes in circles.

This guide covers how to stay steady in a technical interview conducted in English: the common formats, phrases you can use word for word, and habits that make your thinking easy to follow.

Know which format you're walking into

Companies run technical rounds differently, but most fall into one of these:

Format	What happens	Language challenge
Live coding	You write code in a shared editor while they watch	Narrating while typing
System design	You sketch a system on a whiteboard tool	Naming components and justifying choices
Project deep dive	You walk through a project you built	Describing your role and decisions
Take-home review	You discuss an assignment you already submitted	Defending choices and admitting gaps

It's perfectly fine to ask the recruiter ahead of time. It shows you take the round seriously:

Could you tell me the format of the technical round? Is it live coding or system design?

Clarify before you code

The most common mistake is typing the moment the problem is read out. Interviewers want to see that you understand the problem first. Restate it in your own words, then ask about the limits.

Let me restate the problem. I get a list of numbers and a target. I return the two numbers that add up to it. Is that right?

Useful clarifying questions:

Can the input be empty?

Are the numbers always positive?

Should I optimize for speed or memory?

Can I assume the input fits in memory?

Then confirm your understanding with one small example. This helps when the problem was read quickly or the sentences were long:

Can I check one example? The list is 2, 7, and 11. The target is 9. So I return 2 and 7, right?

If your example is wrong, the interviewer will correct it now, not after ten minutes of coding.

If you missed part of the question because of an accent or a bad connection, ask again. Guessing is much worse. There's a full set of phrases in phrases for when you don't understand the question.

Think out loud, in short steps

Your interviewer can't read your mind. If you go silent for five minutes and then produce a solution, they have no idea how you got there. So narrate. Not a lecture, just short sentences that follow your work.

A simple rhythm: plan → step → check.

First, I'll write a simple version. Then I'll make it faster.

I'll loop through the list once. I'll keep each number in a hash map.

Now let me test it with a small example.

Transition phrases that help:

• "My first idea is…"
• "The problem with that is…"
• "A better approach might be…"
• "Let me walk through an example."
• "I think there's a bug here."

You don't have to talk nonstop. Short pauses are fine, as long as you announce them. More options are in phrases to buy thinking time.

Give me a moment to think about edge cases.

Explaining your code and its complexity

Once the code works, you'll usually be asked to explain or analyze it. Go top to bottom, one piece per sentence.

This function takes the list and the target. The loop visits each number once. If the matching number is in the map, I return the pair. Otherwise, I add the current number to the map.

Many candidates hesitate over how to say complexity. Here's the usual way:

Written	Spoken
O(n)	"O of n" or "linear time"
O(n²)	"O of n squared"
O(log n)	"O of log n"
O(1)	"constant time"

The time complexity is O of n. I go through the list once. Space is also O of n, because of the map.

Other terms people often trip over, like cache, queue, or SQL, are covered in commonly mispronounced tech terms.

When you're stuck or don't know

Everyone gets stuck at some point. What matters is how you handle it. Total silence is the worst option. Say what you're thinking and where the problem is.

I'm stuck on handling duplicates. Can I think out loud for a minute?

I know a brute force solution. It's O of n squared. I'll start there and improve it.

I'm not sure about this part. Could you give me a small hint?

If they ask about something you genuinely haven't used, don't bluff. Be honest, then show your reasoning:

I haven't used Kafka directly. I've used RabbitMQ for a job queue. I'd guess Kafka solves a similar problem at larger scale. I'd check the docs to confirm.

That answer shows honesty and logic, and both earn points with technical interviewers.

Deep dives and system design

In a deep dive, the interviewer wants to understand what you did. Use "I" for work you did yourself and "we" for team decisions. Don't claim the whole system if you built one part of it.

I built the payment webhook handler. The team picked the database before I joined.

For system design, start with requirements, then components. Explain each choice along with its downside. How to phrase those trade-offs is covered in explaining technical trade-offs in English.

Let me start with requirements. How many users do we expect? Do we need real-time updates?

Common mistakes and a practice checklist

The mistakes that cost candidates the most:

• Coding immediately without clarifying the problem.
• Long silences with no signal that you're thinking.
• Sentences that run too long, until you lose your own thread. One step, one sentence.
• Claiming tools you've never used. The follow-up questions will expose it.
• Saying "done" without testing on a small example.
• Using "we" for everything, so your own contribution disappears.

Practice checklist for the week before:

• Solve three problems out loud in English while recording yourself.
• Memorize five clarifying phrases and five transition phrases.
• Practice saying complexity and the technical terms you use most.
• Prepare a two-minute walkthrough of one real project, with your role clear.
• Prepare honest answers for technologies in the job post you haven't used.

Summary

An English technical interview grades how you think, not just what you produce. Clarify first, narrate in short sentences, test with an example, and be honest when you don't know. Simple English is enough as long as your reasoning is easy to follow.

For project deep dives and behavioral questions, Repartee can show a short English answer script based on the projects in your profile. Its practice mode also helps you get used to answering in English before the real day.