Engineers who interview in their second language rarely fail on the code. They fail on the silence: two minutes of typing with nothing said, or a solution to the wrong problem because they didn’t ask. Interviewers can only score what they hear. This guide is about making your thinking audible, in simple English.
01What interviewers are listening for
In most coding interviews, communication is part of the score. Microsoft’s advice for technical interviews and Google’s interview tips both ask candidates to explain their thinking and ask clarifying questions. In practice, interviewers usually look for four things:
Clarify
You check the problem before solving it.
Plan
You explain the approach before you code.
Trade-offs
You say why you chose it and what it costs.
Test
You check your own code with examples and edge cases.
None of these needs advanced English. Short, clear sentences work better than long, perfect ones.
02Clarify before you code
Take the first two or three minutes to agree what you’re solving. It’s expected, and it also gives you time to think.
- Restate the problem in your own words: “So we need to…”
- Ask about the input: size, type, empty values, duplicates, negative numbers.
- Ask about constraints: time or memory, and whether a simple solution is fine first.
- Agree a small example and its expected output.
If you don’t understand a word in the question, ask. “Sorry, what do you mean by a ‘stable’ sort here?” is a good question, not a weakness.
03Think out loud without rambling
Thinking out loud doesn’t mean describing every keystroke. Say your decisions, not your typing.
Use simple signposts so the interviewer can follow: “First…”, “Next…”, “The tricky part is…”, “Now I’m handling the edge case where…”. When you need silence to think, say so: “Give me thirty seconds to think about this.”
04Say code and complexity aloud
Many people know Big-O perfectly but have never said it in English. Practise these until they sound natural:
| Written | Said |
|---|---|
| O(1) | “constant time” · “O of one” |
| O(n) | “linear time” · “O of n” |
| O(n log n) | “O of n log n” |
| O(n²) | “O of n squared” · “quadratic” |
| arr[i] | “array at index i” · “the i-th element” |
| i++ | “increment i” |
| != | “not equal to” |
| null / None | “null” · “none” · “if it’s empty” |
Explain each choice with “because”: “I’m using a set because I only need to know whether I’ve seen the value.” Then name the cost: “The trade-off is extra memory.”
05When you get stuck
Getting stuck is normal; going silent or apologising for your English is what hurts. Interviewers often want to see how you recover.
- Go back to the example and trace it by hand, out loud.
- Name the problem: “The issue is that I’m visiting nodes twice.”
- Offer two options and ask which direction they’d like.
- Accept a hint gracefully: “That helps, thank you. So if I…”
06System design in English
System design rounds are mostly talking, so structure matters more than vocabulary. Follow the same order every time:
Requirements
Functional and non-functional: users, scale, latency, consistency.
Estimates
Rough numbers: requests per second, storage per year.
High level
The main components and how data flows between them.
Deep dive
One or two components in detail, chosen with the interviewer.
Trade-offs
What you’d change at ten times the load, and what could fail.
Say the trade-off before they ask: “I’d accept eventual consistency for the feed, because a few seconds of delay is fine for users.”
07Phrases for every stage
| Stage | Phrases |
|---|---|
| Restating the problem | “Just to make sure I understand: we get a list of transactions, and we need the top three customers by total spend?” |
| Clarifying questions | “Can the input be empty?” · “Are the values always positive?” · “Roughly how large can n get?” · “Should I optimise for time or memory?” |
| Explaining the plan | “Let me walk through a small example first.” · “My plan is: first…, then…, and finally….” |
| Choices and trade-offs | “I’m choosing a hash map here because lookups are constant time.” · “The trade-off is extra memory.” |
| Testing your code | “Let me test this with the edge cases: an empty list, one element, and duplicates.” · “I think there’s an off-by-one here; let me check.” |
| When you’re stuck | “Let me think about this for a moment.” · “Could I talk through two options and get your view?” · “Would a hint be okay here?” |
| System design | “Before I design anything, can we agree the requirements?” · “Let me estimate the load first.” · “The bottleneck here is likely the database writes.” |
| When you didn’t catch something | “Sorry, could you repeat the last part?” · “Do you mean X or Y?” |
| Instead of | Try |
|---|---|
| “I will do the for.” | “I’ll loop through the list.” |
| “This is more fast.” | “This is faster.” · “This scales better.” |
| “I don’t know.” | “I haven’t used that, but here’s how I’d approach it.” |
| “Wait. Wait. Wait.” | “Give me a moment to think this through.” |
| “It’s finished.” | “I think this works. Let me test it with a couple of cases.” |
08Example: the first ten minutes of a coding interview
An invented transcript of a classic problem. Read the candidate’s part aloud and notice how little complex English it needs.
Two Sum, talked through
Interviewer: Given an array of integers and a target, return the indices of two numbers that add up to the target.
Candidate: Okay. Just to check: can I assume there’s exactly one solution? And can I use the same element twice?
Interviewer: Exactly one solution, and no, not the same element.
Candidate: Got it. Let me try a small example: two, seven, eleven, fifteen, with target nine. The answer is indices zero and one.
Candidate: The obvious approach is to check every pair. That’s O of n squared. I think we can do better with a hash map: as I go through the array, I store each number and its index, and for each new number I check whether target minus that number is already in the map.
Interviewer: Sounds good. What’s the complexity?
Candidate: One pass, so linear time, and linear extra memory for the map. If memory were tight, I could sort and use two pointers, but then I’d lose the original indices unless I store them. Shall I go with the hash map?
Interviewer: Yes, go ahead.
Candidate: [after coding] Let me test it. With the example, at seven the complement is two, which is in the map at index zero, so it returns zero and one. Now an edge case: negative numbers work the same way. And if the array has two elements, it still works.
09Before your technical round
- I restate the problem and ask at least two clarifying questions.
- I agree a small example before coding.
- I explain my plan in three sentences before I type.
- I can say Big-O and common code aloud in English.
- I give a reason with “because” and name the trade-off.
- I test my code out loud with an edge case.
- I have a phrase ready for when I get stuck.