Running Out of Time in a Coding Interview? How to Use the Last 10 Minutes
You glance at the clock and see ten minutes left. Your approach is right, or close to it, but the code is only half written, there is a helper function you have not started, and you have not tested anything yet. Your typing speeds up, your explanations stop, and the interviewer goes quiet on the other side of the call.
That moment decides more coding rounds than the algorithm choice does. Most interviewers are not grading whether every line got typed. They are grading whether you can reason, communicate, and make good decisions under a deadline, which is exactly what the last ten minutes put on display.
This guide is a short routine for the end of a live coding round: triage, finish the core, test one case, and narrate the rest. It works on CoderPad, shared docs, HackerRank-style editors, and whiteboards. It is about pacing and composure, not about shortcuts.
Why the last ten minutes go wrong
Three things usually happen when time runs short:
- You go silent. All of your attention moves to typing, so the interviewer loses the thread of what you are doing and why.
- You try to finish everything. Input validation, the optimized version, the edge-case branch, and a clean refactor all compete for the same few minutes.
- You skip testing. Many candidates hope the code works and say "I think that's it" with no evidence.
Each of these is a decision, even if it does not feel like one. The routine below makes those decisions on purpose.
Minute 10: say the time out loud
The first move is a single sentence: "I've got about ten minutes left, so here's how I want to use them."
This does two things. It shows the interviewer that you are managing the clock instead of being managed by it, and it opens the door for them to redirect you. Some interviewers will answer with "Skip the parsing, just assume valid input" or "I mostly want to see the main loop." That is free scope reduction, and you only get it if you ask.
Minutes 10 to 8: triage the scope
Look at what is left and sort it into three buckets:
- The core. The part that makes the algorithm work: the main loop, the recursion, the data structure update. This must get written.
- Supporting pieces. Helpers, input parsing, and boilerplate. Stub these with a clear name and a one-line comment, such as
parse_intervals(raw) # returns sorted list of (start, end). - Polish. Error handling for unlikely inputs, micro-optimizations, and renaming variables. Mention these, but do not write them now.
Say the triage out loud in one breath: "I'll write the main merge loop fully, stub the parsing helper, and talk through the empty-input case rather than code it." A clear plan for the final minutes earns more credit than a frantic attempt at everything.
Minutes 8 to 4: finish the core, while talking
Write the core logic and keep narrating, even briefly. You do not need full sentences. Short markers are enough:
- "Now updating the window when the count goes over k."
- "This is the base case, empty list returns zero."
- "Pushing the neighbor only if we haven't seen it."
Narration matters more at the end, not less. If you run out of time mid-line, the interviewer can still score what you were about to write, because you told them. Silent half-written code gives them nothing to work with.
If you hit a bug you cannot see quickly, do not dig for three minutes. Leave a marker comment like # TODO: off-by-one risk on right boundary and keep moving. Naming a likely bug is evidence of judgment, and spending the whole clock on it is not.
Minutes 4 to 2: test one case by hand
Pick the smallest meaningful input, not the example from the prompt if it is long, and trace it through your code out loud, line by line. One honest dry run beats three rushed ones.
While you trace, watch for the classic late-round bugs:
- Loop bounds that are off by one
- A variable that never gets updated inside the loop
- A return that sits inside the loop when it should sit after it
- An empty or single-element input that crashes the first line
If you find a bug, fix it if the fix is one line. If it is bigger, say exactly what is wrong and how you would fix it. "This misses the last interval because I only append inside the loop; I'd add one append after the loop" is a strong answer even if you never type it.
Minutes 2 to 0: narrate what you would do next
Close the round with a short summary, about thirty seconds:
- What works: "The main loop is complete and handles the example."
- What's stubbed: "Parsing is stubbed; it would sort by start time."
- Complexity: "O(n log n) for the sort, O(n) for the merge, O(n) extra space."
- Next steps: "With more time I'd add the empty-input guard and test overlapping-at-boundary cases."
This turns an unfinished solution into a finished explanation. Interviewers often write feedback like "ran out of time but clearly knew how to complete it," and that is a very different note from "did not finish."
What not to do when the clock is short
- Don't apologize repeatedly. One "I'm running short on time" is information. Five apologies are noise and use up minutes.
- Don't switch approaches with five minutes left unless the current one is clearly wrong. A complete brute force beats a half-written optimal solution.
- Don't go quiet to type faster. You will not type meaningfully faster, and you lose the narration that earns partial credit.
- Don't ask "Is that okay?" after every line. Ask once when you triage and then commit to the plan.
Practice the ending, not just the start
Most practice sessions end when you solve the problem, or when you give up and read the solution. That means the last ten minutes of a real round are the part you have practiced least.
Change that with a simple drill:
- Set a 35-minute timer for a medium problem.
- At the 25-minute mark, stop wherever you are and run the routine: say the time, triage, finish the core, test one case, and summarize.
- Record yourself or write the summary down. Check whether your narration stayed on during the final stretch.
- Do this at least twice a week until "ten minutes left" feels like a normal checkpoint instead of an alarm.
Over time you will notice that you start triaging earlier on your own, at 15 or 20 minutes left, which is when it helps most.
If you want a Chrome side panel next to your coding pad while you run timed mocks and rehearse your triage and closing summaries, Luna Interview is built for that kind of practice. Use it to build calm under time pressure, not as a substitute for knowing the material or for anything that breaks interview rules.
FAQ
Is it bad to not finish the code in a coding interview?
Not always. Many candidates get positive feedback without a complete solution, especially when the approach is correct, the core logic is written, and they explain clearly what remains. A missing helper with a clear plan is usually judged far more kindly than silent, incomplete code.
Should I ask the interviewer for more time?
Usually no. Rounds are scheduled back to back, and the interviewer rarely controls the clock. A better move is to ask what they most want to see in the time left, which often gets you a smaller scope.
Should I write brute force first if I'm worried about time?
Often yes. If the optimal approach is unclear after a few minutes, a working brute force plus a spoken plan for optimizing it shows reasoning and leaves you with something complete. See it as a floor, not a failure.
How do I know when to start the ten-minute routine?
Glance at the clock when you finish your approach discussion. If more than half the round is gone and you have not started coding, begin triaging right away instead of waiting for the final ten minutes.
Last-ten-minutes checklist
- [ ] Say the remaining time out loud and ask what matters most
- [ ] Sort what's left into core, supporting, and polish
- [ ] Write the core while narrating; stub helpers with clear names
- [ ] Mark any bug you can't fix quickly with a comment
- [ ] Trace one small input through the code out loud
- [ ] Close with what works, what's stubbed, complexity, and next steps
A round that runs out of time is not automatically a lost round. Triage the scope, finish the core, test one case, and narrate the rest, and the interviewer still sees how you work when it counts.
— Luna Interview
Rehearse with an AI interview copilot, then browse commonly reported interview questions.