Live Coding Without Freezing: Narration, Checklists & Partial Credit

The interviewer pastes a problem into a shared editor, says "take your time," and your mind goes blank. You knew this material yesterday. The real problem is not knowledge. It is that live coding asks you to think, type and be judged at the same time, and nobody practises that combination on purpose.

I wrote this with help from AI tools and checked every script, rubric and example myself. I am a Principal Software Engineer in Karachi with 9+ years across PHP/Laravel, Vue, Node and .NET, I have run live coding rounds as an interviewer and frozen in them as a candidate, and I build Smart Resume Analyzer. This is Part 2 of the series Interview Proof Beyond the Resume. Part 1 covered take-home tests; this one covers the round where you cannot go away and think quietly.

📚 Series Roadmap — Interview Proof Beyond the Resume

Part 1: Take-Home Tests That Prove Depth Without Unpaid Labor Theater

Part 2 (This Post): Live Coding Without Freezing: Narration, Checklists & Partial Credit

Part 3: System Design Interviews From Production Scars, Not Blog Diagrams

Part 4: Case-Study Portfolios That Humans and ATS Both Parse

Part 5: Async Video & Written Interview Answers That Sound Like You

Part 6: Negotiating Level From Evidence: Mapping Proof to Staff vs Senior

Related earlier posts: How AI/LLM Resume Screeners Rank Engineers in 2026 · Surviving ATS Knock-Out Questions

How do you avoid freezing in a live coding interview?

Direct answer: Use a fixed opening routine instead of improvising: restate the problem, write two examples, name a brute-force approach, then improve it. Narrate decisions, not keystrokes. When stuck, say what you are checking and write a failing case. Interviewers score communication, testing and progress, so a correct, explained partial solution earns real credit.

Why people freeze, and why it is not about talent

Freezing is a working-memory problem. You are holding the problem statement, the half-formed algorithm, the syntax of a language you may not use daily, and a running estimate of what the interviewer thinks of you. The last item is the expensive one. The fix is to offload as much as possible onto the screen: write the problem down, write examples down, write the plan down. Once the plan lives in the editor, your head is free for the next decision.

The second cause is silence. Thirty seconds of quiet feels like five minutes to you, and the interviewer has no idea whether you are close or lost. Narration is not performance. It is a way of giving the interviewer something to grade and giving yourself a checkpoint.

The five-minute opening routine

I practise this exact sequence until it is boring. Boring is the goal, because a routine you do not have to invent is the one you can run while nervous.

1. RESTATE "So I get a list of log lines and return the top-k IPs by count, ties by IP asc?" 2. EXAMPLES Write 2 inputs in the editor: a normal case and an edge (empty / all ties). 3. LIMITS Ask: input size? memory? can I use the standard library? 4. BRUTE "Simplest version: count in a map, sort all entries. O(n log n)." 5. IMPROVE "If k is small, a size-k heap gets O(n log k). Want me to start simple?"

Step 5 ends with a question on purpose. Many interviewers would rather see a working simple version first, and asking hands them control over the trade-off you were going to agonise about anyway.

Here is what the code should look like at minute fifteen: correct, readable, tested by hand, not clever.

from collections import Counter import heapq def top_k_ips(lines: list[str], k: int) -> list[str]: # Assumption (said out loud): IP is the first space-separated field.  counts = Counter(line.split(" ", 1)[0] for line in lines if line.strip()) # heapq.nsmallest with a key gives count desc, IP asc in O(n log k).  return [ip for ip, _ in heapq.nsmallest(k, counts.items(), key=lambda kv: (-kv[1], kv[0]))] assert top_k_ips([], 3) == [] assert top_k_ips(["1.1.1.1 GET /", "2.2.2.2 GET /", "1.1.1.1 POST /x"], 1) == ["1.1.1.1"] assert top_k_ips(["b x", "a x"], 2) == ["a", "b"] # tie broken by IP ascending

Notice the comment that states an assumption. That one line is worth more than an elegant one-liner, because it shows you know where the solution could break.

Narration: what to say and what to skip

Bad narration describes typing: "now I am writing a for loop, now I am adding an if." Good narration describes decisions and risks.

Moment	Weak narration	Strong narration	What the interviewer records
Choosing a structure	"I'll use a dictionary."	"A hash map gives O(1) counts; order doesn't matter until the end."	Data-structure reasoning
Hitting a bug	Silence, then frantic edits	"Output is off by one. Checking the loop bound against example 2."	Debugging method
Edge cases	Not mentioned	"Empty input and ties are my two risky cases; adding asserts."	Testing instinct
Running out of time	"Sorry, I didn't finish."	"The remaining piece is X; here is how I'd do it and its complexity."	Prioritisation
Getting a hint	"Oh, right."	"That removes the sort. Let me update the complexity: O(n log k)."	Coachability

A useful rhythm is one sentence every 30 to 60 seconds. If you notice a long silence, say the next thing you are going to check. That alone resets the room.

How partial credit actually works

Most structured interview rubrics I have used or seen score several dimensions separately, typically problem understanding, approach, code quality, testing and communication. Correctness is one column, not the whole grade. That matters because a candidate who reaches a correct brute force, tests it, and clearly explains the optimisation they did not finish often scores higher than someone who silently writes a buggy optimal solution.

Outcome at the bell	Typical read from the panel	How to tilt it upward
Optimal, untested, unexplained	Strong coder, unknown teammate	Add asserts early; narrate trade-offs
Brute force, tested, optimisation explained	Solid hire signal for most mid/senior roles	Write the improved approach as comments
Half an optimal attempt, no working version	Weak, hard to grade	Always get a working simple version first
Stuck, but clear reasoning and good questions	Borderline; depends on level	State what you'd look up and why

The practical rule: never trade a working version for a chance at a better one unless you have time left to test it.

When you get stuck: a recovery script

Getting stuck is normal. Staying silent while stuck is what costs you. Use a small script:

Say it plainly: "I'm stuck on how to handle ties."
Shrink the problem: run your code by hand on the smallest example.
Write the failing case as an assert, so the bug becomes concrete.
Offer a fallback: "If I can't get the heap version right in five minutes, I'll keep the sort and explain the heap."
Accept hints out loud and restate them in your own words.

Interviewers often have a hint ladder prepared. Asking a precise question ("is it fine to assume the input fits in memory?") pulls the useful hint without signalling that you are lost.

Practising the right thing

Grinding hundreds of puzzles silently trains the wrong muscle. Practise talking. Record yourself solving one medium problem out loud with a 35-minute timer and watch the replay at double speed. You will hear the silences and the vague sentences immediately.

I also suggest a tiny warm-up script before each real interview, run in the same editor or language you will use:

# 10-minute warm-up: same language, same editor, out loud python3 - <<'PY' from collections import defaultdict g = defaultdict(list) for a, b in [("a","b"),("b","c")]: g[a].append(b) print(dict(g)) PY

It looks trivial. The point is to have your fingers and your syntax warm, so the first minutes of the interview are not spent remembering how a default dict works.

Finally, connect the round back to your resume. Interviewers often pick problems near the skills you listed. If your resume says "built log ingestion pipelines," expect parsing and counting problems. Before the loop, run your resume through the resume score calculator and check what an ATS parser actually extracts from it. The skills that come out of that parse are the ones interviewers will probe, so those are the ones to rehearse.

Diagnostic checklist before your next live round

[ ] I can run my five-step opening routine without notes.
[ ] I have practised in the exact language and editor the company uses.
[ ] I write at least two examples, including one edge case, before coding.
[ ] I state assumptions as code comments.
[ ] I get a working simple version before optimising.
[ ] I add asserts or a tiny test harness while coding, not at the end.
[ ] I narrate decisions every 30 to 60 seconds, not keystrokes.
[ ] I have a recovery script for being stuck and I have rehearsed saying it.
[ ] I can explain the time and space complexity of whatever I wrote.
[ ] I reviewed which skills my parsed resume claims, and practised problems near them.

FAQ

Should I start with the optimal solution if I already know it?

Say that you know it, explain it briefly, and ask whether to code it directly. If you are confident and the interviewer agrees, go. Still add tests.

What if the interviewer is silent and gives no feedback?

Some panels are trained to stay neutral. Treat silence as normal, keep narrating, and ask a checkpoint question every so often, such as "does this approach look reasonable to continue?"

Is it okay to look up syntax?

Ask first. Many interviewers allow it. Saying "I'd normally check the exact signature of heapq.nsmallest" is fine; it shows you know what to look up.

How do I handle a language I use less often?

Ask to use your strongest language. If the role requires a specific language, practise basic collections, string handling and sorting in it beforehand.