Live coding: five sentences for when you freeze
Freezing happens to everyone, senior engineers included. What fails the round is the silence around it: the interviewer can't see your thoughts and has to interpret the pause. Five sentences that turn a freeze into a conversation.
Freezing works like this: anxiety takes your working memory, and everything you know by heart goes with it. Fifteen seconds of silence feel like a minute, panic compounds, and it gets worse from there.
What matters is knowing what's graded. The interviewer doesn't need perfect code in twenty minutes; they need the process — how you handle unfamiliar problems, how you react when stuck, whether you're someone to work with. And silence is the one genuinely unrecoverable mistake. Everything else is fixable.
The three-step protocol
The moment you notice you're stuck, do these three things in order.
1. Name it out loud. "I'm stuck." One sentence removes the core problem: the interviewer stops guessing and joins the conversation.
2. Say what you already know. "I can see this is a breadth-first search, the state is a coordinate pair, I'm blanking on how to track visited nodes." That turns "I don't know" into a specific point where help applies.
3. Take one small concrete step. Trace an example by hand: take a three-element input and say what should come out. Most of the time the solution appears right there — concrete numbers show what abstraction hides.
Five sentences that work
"Let me restate the problem in my own words." Buys thirty seconds and catches the biggest failure mode — a misread problem. Sometimes the interviewer corrects an assumption and the freeze disappears along with the problem that never existed.
"I'll write the brute-force version first and optimise after." Brute force is a legitimate strategy and is almost always welcomed: you get working code and a baseline to improve. Candidates often feel embarrassed about it and end up writing nothing.
"I'm stuck here specifically: I know I need a hash map, I've blanked on the syntax." A precise stuck point invites a hint. Interviewers usually answer, and it doesn't count against you, because you named the boundary of what you don't know instead of asking for the solution.
"Can I walk through an example?" The most reliable move. Take a concrete input, trace it by hand, narrate as you go. It surfaces both the algorithm and the edge cases.
"I see two approaches, let me weigh them out loud." Turns a freeze into a trade-off discussion — which is the part that scores highest anyway. "Brute force is O(n²); a hash map gets O(n) time at O(n) space, I'll start there."
What to do with your hands while your head works
An empty screen amplifies panic. Write something — it both starts your thinking and shows movement.
- The function signature with types: it often reveals the shape of the solution.
- Input and output examples, including the empty and degenerate ones.
- A plan in comments: three lines —
# 1. count frequencies,# 2. sort,# 3. take top k. Then fill them in. - Edge cases as a list: empty array, duplicate elements, negative numbers.
A written plan is already partial credit, and it counts even if the code doesn't finish.
What not to do
Stay silent. A pause longer than ten or fifteen seconds reads as nothing at all.
Apologise. "Sorry, I'm usually better than this" burns time and deepens the feeling of failure on both sides.
Delete everything and restart. A silently cleared screen looks like surrender. If the approach is wrong, say why it's wrong and what you're doing instead.
Search silently. If searching is allowed, narrate what you're looking for. A quiet window switch looks worse than the search itself.
Argue with a hint. If the interviewer is nudging you, they're on your side — they want you to finish.
About live prompts
Tools help in a narrow band: a method's syntax, a library signature, the definition of an unfamiliar term. That's real but limited.
What they won't do is handle the discussion. After the code come "why this way", "what if the data grows a hundredfold", "what breaks here" — and on those questions reading off a screen is audible. The combination that actually works is rehearsal out loud beforehand, with a prompt as insurance during.
After the round
If it went badly, write down the problem and the exact sticking point within the hour, while you still remember the wording. A week later all that remains is the feeling of failure, and what you need is the specific gap.
Then don't grind a hundred problems — redo the ones you froze on, out loud, against a timer. Practice with a debrief fixes freezing faster than volume does, because the problem was never the algorithms: thinking works differently when someone is watching.
Pick the problem types by your stack and grade rather than at random: the question bank filters on exactly that, and it shows what gets asked at your level versus what only starts one grade up.
FAQ
What should I do if I freeze during live coding?
Three steps: say out loud that you're stuck; name what you've understood and where exactly the block is; take one small concrete step, such as tracing a three-element example by hand. Silence is the only mistake you can't recover from.
Can I ask the interviewer for a hint?
Yes, if you phrase it precisely: not "I don't know" but "I know I need a hash map, I've blanked on the syntax." A specific stuck point almost always gets a hint, and it isn't held against you.
Is it acceptable to write a brute-force solution?
Yes, and it's the recommended strategy. Working brute force gives you a baseline to optimise from and shows you understood the problem. Writing nothing while chasing the optimal answer is worse.
Will I fail if I don't finish the problem?
Not necessarily. The round grades the process: reading the problem, the plan, edge cases, how you think. A candidate with a clear plan and half the code often passes; one with twenty silent minutes doesn't.
Does an AI prompt help in live coding?
Narrowly — syntax or a definition. It doesn't cover the discussion after the code, where "why this way" and "what breaks at scale" expose reading immediately.
How do I stop freezing from nerves?
Practise in the same conditions: out loud, timed, observed. Freezing is a reaction to being watched rather than to difficulty, which is why problems solved alone don't inoculate you.
