The live coding interview: what to do when the solution will not come
The round tests how you think aloud more than it tests algorithms. Here is how to use that.
Live coding breaks people who write perfectly good code at work. The reason is that the round tests something other than it appears to: not solving problems, but solving them out loud and under observation.
What is being assessed
- How you approach the problem statement. It is usually underspecified on purpose. Clarifying questions are part of the test, not a sign of confusion.
- Whether your reasoning is audible. A silent candidate with correct code often loses to one who talked their way to something simpler.
- What happens when you are stuck. This models real work better than the problem does.
- Whether you check your own work. Edge cases, tests, complexity.
Spending the time
First five minutes: clarify
Do not touch the keyboard until you have restated the problem in your own words. Ask about input size, allowed values, and what counts as correct in degenerate cases.
"Can the array be empty? Integers only, positive? Are duplicates possible? How large does the input get — does a million elements need to fit in memory?"
These questions are often the hidden half of the problem: the answers change the solution.
Next seven: talk through the approach
Say how you plan to solve it and why before writing. Starting from the naive solution is fine and often useful.
"The simple version is two nested loops, quadratic. That will not hold for a million elements. One pass with a dictionary gives linear time and linear memory — I will write that one unless you would rather see something else."
You have now shown that you see several solutions and understand their cost. Even if the code never finishes, that part counts.
Then twenty-three: write
Narrate in blocks rather than line by line: "handling the empty input now", "this is the main loop".
Last ten: check
Walk through the example from the statement by hand, out loud. Then the edge cases: empty input, one element, all identical, negatives.
A bug you find is a plus. A bug the interviewer finds is not.
When the solution will not come
This is the scenario worth preparing for separately, because it happens often and because people give up too early.
Say where you are stuck. Not "I do not know", but specifically: "I can see how to find the pairs in quadratic time, I cannot see how to speed it up." The interviewer will almost always offer a hint — they want you to pass.
Write the naive solution. A working brute force beats an empty screen, and it gives you something to improve from.
Work a small example by hand. Take a tiny input and solve it on paper, narrating. The solution often appears there, and the interviewer sees your reasoning either way.
Ask about direction. "I am thinking hash map. Reasonable, or am I looking the wrong way?" That is how real work happens.
There is exactly one failing move: staring at the screen in silence. Five quiet minutes are read as "does not know", however hard you are thinking.
Small things that cost you
- An unfamiliar editor. If the round runs in CoderPad or a shared document, open it beforehand and type a few lines. Fighting the indentation on camera burns time and attention.
- An unreadable screen. Increase the font size when sharing: the interviewer sees your code through compressed video.
- Notifications. Turn them off before you start.
- Variable names.
a,b,tmpare forgivable alone and read as carelessness here.
How to prepare
Solving problems in silence trains the wrong skill. Narrate your solutions aloud even when alone. The first attempts feel absurd, and that is exactly the awkwardness worth spending at home.
Record twenty minutes of yourself and listen back. There are usually far more pauses than it felt like from the inside.
In short
- Your reasoning is assessed, not only the final code.
- Five minutes clarifying, seven on the approach — do not skip them.
- A naive solution out loud beats a silent search for the perfect one.
- Stuck: say so in words and ask for direction.
- Leave time for edge cases — your own bug beats theirs.
Shpora is an AI assistant that hears the interviewer's question and gives you something to build an answer on within a second. It runs on your own computer, with any video call.
Try it free