How to explain your code while solving a live coding problem
In a live coding interview, silence turns a correct solution into weak evidence because the interviewer cannot see your assumptions or trade-offs. You do not need to narrate every keystroke. You need to make the decisions visible: what the problem requires, why the data structure fits, what invariant the loop preserves, and how you know the result is correct. The principles match Google's technical-writing guidance: put the key point first, use a clear structure, and match the explanation to what the audience needs to know.
Before you type: state the target
Restate the input, output and success condition in one sentence. Ask about constraints that change the algorithm: input size, duplicate values, ordering, memory limits, invalid input and whether a mutable result is acceptable. This prevents a fast solution to the wrong problem.
Then give a short plan: I will use a hash map to remember values seen so far, scan once, and return as soon as the complement appears. That is linear time and linear extra space. The interviewer now knows what to evaluate before the code exists.
While coding: narrate decisions, not punctuation
Say why a new variable exists, why a branch handles an edge case, or why an operation has the stated complexity. Do not read every line aloud. A useful rhythm is: describe the next small step, write it, then check whether the invariant still holds.
- Name the invariant. For example, before index i, the map contains exactly the values from earlier positions.
- Name the boundary. Explain what happens for empty input, one item, a duplicate or the largest allowed value.
- Name the trade-off. If you spend memory to avoid a nested loop, say so.
After coding: test the story, not only syntax
Run a normal example, then a case designed to break the tempting mistake. Say what output you expect before running it. If an environment does not let you execute code, trace two or three iterations aloud. This is especially important in live coding rounds and code review interviews.
How to handle a follow-up
When the interviewer changes a constraint, pause and classify the change. Does it affect correctness, complexity, data representation, concurrency or deployment? Then state what you would keep and what you would replace. For example: if input no longer fits memory, I would keep the validation rule but change the in-memory map to a sorted external or streaming approach, after clarifying latency and storage constraints.
This same discipline makes system-design follow-ups easier: identify the changed constraint, explain the affected path, choose a trade-off and name a measurement.
How to recover from a mistake
Do not hide it. Say what you noticed, why it is wrong, and what you will change. For example: I used the index as identity, but the list can reorder, so I will switch to the stable ID. A calm correction demonstrates debugging and judgement; continuing with a known mistake does not.
A one-minute answer template
- Clarify: here is the input, output and constraint that matters.
- Plan: I will use this structure because it gives this complexity.
- Implement: this loop maintains this invariant.
- Verify: I will test these edge cases.
- Trade-off: this is what I gain and what I spend.
Practise the template with one technical interview problem each day. Confirm the employer's rules before using any external tool or reference during a live assessment. If English is not your first language, see technical interview in English as a non-native speaker for restating questions and phrases to pre-load.
Sources
- Google Technical Writing One — official documentation
FAQ
How much should I talk during a live coding interview?
Talk at decision points: clarify the problem, state the plan, name the data structure and complexity, explain the invariant, test edge cases and describe trade-offs. Do not narrate every keystroke.
What should I say before writing code?
Restate the input and output, ask about constraints, then give a short plan with the chosen data structure and expected time and space complexity.
How do I explain an algorithm invariant?
State what remains true before and after each iteration. For example, before index i, a map contains exactly the values seen at earlier positions. Then explain how the current step preserves it.
What if I make a mistake during a coding interview?
Say what you noticed, why it is wrong and how you will correct it. A clear correction demonstrates debugging and judgement better than trying to hide the mistake.
How do I handle a coding follow-up?
Classify the changed constraint, identify which part of the solution it affects, keep what still works, state the new trade-off, and explain how you would verify the revised approach.