Quick Answer
To explain code out loud in English: narrate your intent before you type, say each decision in one short sentence, and use a fixed structure - state the approach, code it, test a case, name the trade-off. Never go silent.
Why narration matters more than syntax
In a UK/US coding interview, two candidates who write identical solutions will be scored differently if one narrates and one is silent. The interviewer cannot evaluate thinking they cannot hear.
For non-native English speakers this matters even more: silence under pressure reads as confusion, not concentration. Your job is to keep a running commentary - short, clear sentences - so the panel follows your reasoning in real time.
Key vocabulary
| Term | Plain meaning | Say it in an interview |
|---|---|---|
| Brute force | Simplest working solution, often slow | "I'll start brute force to confirm correctness, then optimise." |
| Trade-off | What you gain vs. lose | "The trade-off here is time versus memory." |
| Edge case | Unusual input that could break the code | "Let me check the edge case where the input is empty." |
| Pointer | Index or reference tracking position | "I'll use two pointers, one at each end." |
| In-place | Modify without extra space | "I can sort this in-place to avoid allocating a new array." |
| Overflow | Number too large for the data type | "I'll use a long to avoid integer overflow." |
ESL phrases and transitions
Opening and planning
- "Let me read through this once before I start."
- "My first instinct is to use a hash map - let me check if that works."
- "I'll think out loud as I go, stop me if I'm heading the wrong way."
While coding
- "Here I'm initialising the result array."
- "I'm choosing a while loop because I need to move both pointers."
- "This condition handles the case where left equals right."
- "Let me double-check this index - I don't want an off-by-one."
After writing the solution
- "Let me trace through with the example input."
- "Edge case: what if the array is empty? I'll add a guard at the top."
- "The time complexity is O(n) and space is O(1) because I'm not using extra storage."
Key English language pitfalls
| Pitfall | Sounds like | Say instead | |
|---|---|---|---|
| Translating silently | You're thinking, not communicating | Narrate even incomplete thoughts: "I'm thinking about…" | |
| Saying "it's easy" or "simple" | Dismissive, overconfident | Just code it - let the solution speak. | |
| Vague variable names in speech | "this thing" or "this value" | Use the variable name: "left pointer | current sum" |
| Apologising mid-solution | "Sorry, my English…" | Keep going - correct the code, not yourself. |
Common English mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Going silent for 60+ seconds | Panel loses thread | Say "let me think through this" and keep a slow verbal trickle going. |
| Explaining after you've already coded | Too late to show reasoning | Narrate before and during, not only at the end. |
| Only saying what the code does | Misses the why | State the decision: "I chose a set here because lookup is O(1)." |
What the interviewer is testing
UK/US interviewers in coding rounds test three things: does the candidate understand the problem, can they think through it systematically, and can they communicate decisions clearly in English.
They are not grading accent or grammar. They are listening for structured thinking - can you say why you made each choice before you make it?
How to open the problem in English
First 60 seconds
- "Let me restate the problem to make sure I understand: we need to find…"
- "A few clarifying questions before I start - can the input contain duplicates?"
- "My initial approach would be X. The time complexity would be Y. Let me see if we can do better."
Full spoken walkthrough template
| Phase | What to say |
|---|---|
| Restate (30s) | "So we're given X and need to return Y. Constraints: Z." |
| Clarify (30s) | "Can the input be empty? Can values be negative? Is the array sorted?" |
| Approach (60s) | "My first idea is brute force: [explain]. That's O(n²). I can improve it by using [structure] which gives O(n)." |
| Code (narrate throughout) | "I'm initialising a hash map. For each element I check if the complement exists. If yes, I return the indices." |
| Test (60s) | "Let me trace through the example: input [2,7,11,15], target 9. First element 2, complement is 7, not in map yet. Add 2→0. Second element 7, complement is 2, found at index 0. Return [0,1]. Correct." |
| Edge cases (30s) | "What if the array is empty? My guard at the top returns an empty array. What if there's no solution? The problem says one solution always exists, so I won't add that check." |
| Complexity (30s) | "Time O(n), space O(n) for the hash map." |
Weak vs strong answers
Weak
[Types for 3 minutes in silence] Here's my solution. It works.
Strong
I'll use a hash map. For each number I check if its complement is already stored. If yes, I return both indices. This runs in O(n) time and O(n) space. Let me trace the first example to confirm... [narrates trace]. The edge case I want to check is an empty array - my guard handles that. Done.
How to say the key terms
| Term | Say it |
|---|---|
| O(n) | "order n" or "linear time" |
| O(n²) | "order n squared" or "quadratic time" |
| O(log n) | "order log n" or "logarithmic time" |
| O(1) | "order one" or "constant time" |
| off-by-one | "off by one error" - say this if your index is wrong |
| null / None | "null" (Java/JS) or "None" (Python) - say the word, don't skip it |
Follow-up questions you will get
Expect these
- "Can you optimise the space complexity?"
- "What would you change if the input didn't fit in memory?"
- "How would you test this in production?"
- "What's the worst-case input for your solution?"
Practice drill
Pick any LeetCode medium problem. Set a timer for 25 minutes. Solve it out loud in English from start to finish - restate, clarify, approach, code with narration, trace, edge cases, complexity.
Record yourself. Listen back. Count how many seconds you went silent. Aim to reduce silent gaps to under 10 seconds throughout.
Answer frameworks you can reuse
Restate → Clarify → Approach (brute force first) → Optimise → Code → Trace → Edge cases → Complexity.
For every decision: state the data structure, say why you chose it, then use it.
When stuck: say 'I'm thinking about…' and reason aloud. Asking the interviewer for a hint is fine - say 'I have a direction in mind but I'm not sure about X, can you confirm Y?'
FAQ
Questions
More questions? Email us at contact@mocklyenglish.com.