Quick Answer
When your code fails in a live interview: stay calm, say what you expected versus what you got, trace through a small example step by step, name the suspect line, fix it, and re-run. Never go silent and never apologise for the bug - debugging out loud is part of the test.
Why debugging English is its own skill
Most candidates practise writing code but not debugging it out loud in English. Yet a failing test case in a live interview - where you have to fix it under pressure while narrating - is one of the most common scenarios.
Interviewers often introduce a subtle bug intentionally, or wait to see how you react when your own code fails. The English you use in that moment signals composure, systematic thinking, and real engineering experience.
Key vocabulary
| Term | Plain meaning | Say it in an interview |
|---|---|---|
| Off-by-one | Index shifted by one | "I think there's an off-by-one error here - my loop runs one iteration too many." |
| Null pointer / NullPointerException | Accessing a missing reference | "I'm not checking for null before dereferencing - let me add a guard." |
| Stack overflow | Recursion too deep | "The recursion isn't hitting the base case - let me trace through why." |
| Trace / dry run | Step through by hand | "Let me trace this with a small input to find where it breaks." |
| Breakpoint | Where execution stops to inspect | "If this were production I'd set a breakpoint here and inspect the state." |
| Regression | Bug reintroduced after a fix | "I want to make sure my fix doesn't break the earlier test case." |
ESL phrases and transitions
When something fails
- "The output is X but I expected Y - let me find where they diverge."
- "Let me trace through this with the failing input step by step."
- "I think the issue is around line 12 - let me check that condition."
While tracing
- "At this point the value of left is 2, not 3 as I assumed."
- "Here's where it goes wrong - I'm updating the pointer before reading from it."
- "This condition should be less-than-or-equal, not strictly less-than."
After fixing
- "Let me re-run the failing test case to confirm."
- "And let me also check the original example still passes."
- "The fix changes the time complexity? No - the correction is inside the same loop, still O(n)."
Key English language pitfalls
| Pitfall | Sounds like | Say instead |
|---|---|---|
| Panicking and going silent | You can't handle pressure | Say "let me trace through this" and keep talking at any pace. |
| Saying "I don't know why it's wrong" | No debugging strategy | "Let me narrow down where the failure starts." |
| Fixing without explaining | Panel can't follow | Say the change and why before you make it. |
| Apologising repeatedly | Undermines confidence | One brief acknowledgement is fine, then move straight to the fix. |
Common English mistakes
| Mistake | Why it hurts | Fix |
|---|---|---|
| Rewriting the whole solution instead of isolating the bug | Wastes time, shows panic | Trace to find the exact failing line first. |
| Making a change and not testing it | Could introduce more bugs | Always re-run the failing case and one passing case. |
| Not saying why the bug existed | Misses learning signal | After fixing: "The root cause was that I assumed X but actually Y." |
What the interviewer is testing
Live debugging tests composure under failure, systematic thinking, and whether you can isolate a problem without brute-force rewriting everything.
It also tests whether you can explain your reasoning in English under stress - which is exactly what real engineering on-call incidents require.
How to open when something goes wrong
First 20 seconds after a failure
- "The output is [X] but I expected [Y] - let me trace through and find the divergence."
- "Let me isolate the failing case first before I change anything."
- "I'll add a quick mental print statement here to check the state at this point."
Live debugging walkthrough
| Step | What to say |
|---|---|
| State the failure | "Expected 5, got 4. Input was [1,2,3,4,5], target sum 9." |
| Hypothesise | "I suspect the issue is in the boundary condition of the while loop." |
| Trace the failing input | "Left starts at 0, right at 4. Sum is 6, too small. Move left. Sum is 7. Move left. Sum is 9 - should return here but it's not. Let me check the return condition." |
| Find the bug | "I see it - I have strict less-than but I need less-than-or-equal because left can equal right." |
| Fix and explain | "I'll change left < right to left <= right. That means we also test the middle element, which is correct." |
| Re-run | "Tracing again: … sum is 9 at left=2, right=2. Returns [2,2]. Correct." |
| Check regression | "And the original example still returns [0,3]. Good." |
Weak vs strong answers
Weak
[Long silence, rewrites entire function] Is that better?
Strong
The output doesn't match. Let me trace through the failing input. At this step the pointer moves past the target - I think my boundary condition is wrong. Here - I'm using strictly less-than but I should use less-than-or-equal. Let me make that change and re-trace. Now it returns the correct result. Let me also confirm the first example still passes.
How to say the key terms
| Term | Say it |
|---|---|
| off-by-one | "off by one" - not "one off" |
| null check | "null check" or "null guard" |
| base case | "base case" - the recursion termination condition |
| return early | "return early" or "short circuit" |
| dry run / trace | both are natural in UK/US engineering English |
Follow-up questions you will get
Expect these
- "How would you have caught this bug before submitting?"
- "What test cases would you write for this function?"
- "Is this the only edge case, or are there others?"
Practice drill
Take a working solution and deliberately introduce a bug - an off-by-one, a wrong condition, a missing base case. Then debug it out loud as if in an interview: state what failed, trace, identify the line, fix it, and re-verify.
Do this three times a week. The goal is to make the verbal debugging routine feel automatic so pressure doesn't freeze you.
Answer frameworks you can reuse
Observe (what failed) → Hypothesise (where the bug might be) → Trace (step through the failing input) → Identify (the exact line) → Fix (explain the change) → Verify (re-run the failing and one passing case).
Never skip Verify. Fixing a bug and not checking it is a common mistake that costs you time and signals carelessness.
FAQ
Questions
More questions? Email us at contact@mocklyenglish.com.