A live coding interview isn't really a test of whether you can produce an answer. It's a test of how you get there, with someone watching. Plenty of engineers who solve problems well at their desk find the interview version hard, not because the problems are harder, but because thinking, typing, and explaining at the same time is a separate skill. The good news is that it's a skill you can build.
This guide covers what the round looks like, what interviewers watch for, a structure for the 45 minutes, and how to prepare in the weeks before.
What a live coding interview looks like
You join a video call, the interviewer shares a link to a collaborative editor (or asks you to share your screen), and you're given a problem. It's usually small and well defined: work with a list, a string, a tree, or a graph, and return something. You write code while talking through your thinking, run it if the environment allows, and answer follow-up questions about edge cases, complexity, and how you'd change it.
Variations you might meet:
- Algorithm-style problems in a plain editor, the most common form for general software engineering roles.
- Practical problems: parse a log file, build a small class with a few methods, implement a rate limiter or a cache. Increasingly common, especially at smaller companies.
- Pair programming on an existing codebase, where you add a feature or fix a bug alongside the interviewer.
- Whiteboard coding, without an editor or the ability to run code. Rarer now, but it still happens in person.
The structure below works for all of them. The main difference is how much of the time goes to understanding existing code versus writing new code.
How long a live coding interview is
Usually 45 to 60 minutes. Take away a few minutes at each end for introductions and your questions, and you have 35 to 50 minutes for the problem. Often that's one main problem with a follow-up ("now what if the input is a stream?"), sometimes two smaller problems.
That's not much time, which is why a structure helps. Without one, it's easy to spend fifteen minutes coding the wrong thing or run out of time before you've tested anything.
What interviewers are watching
Most interviewers take notes against four things, whatever the problem:
- Problem solving. Did you understand the problem, ask about the inputs and edge cases, and choose an approach for a reason?
- Coding. Is the code readable and correct, in a language you clearly know?
- Communication. Could they follow your thinking while you worked? Did you respond to hints?
- Verification. Did you test your own code, find your own bugs, and reason about time and space complexity?
Notice that "got the optimal solution" isn't one of them on its own. A correct answer reached in silence often comes across less well than a slightly slower one where the interviewer could follow every step. A working brute-force solution, clearly explained, with a sensible step toward something better, is a reasonable place to finish.
A structure for the round
| Phase | Time | What you're doing |
|---|---|---|
| 1. Clarify | 3–5 min | Restate the problem, ask about inputs, agree an example |
| 2. Approach | 5–8 min | Say the brute force, improve it, agree on a plan |
| 3. Implement | 15–20 min | Write the code, narrating as you go |
| 4. Test | 5 min | Trace a normal case and an edge case, fix bugs |
| 5. Discuss | remaining | Complexity, follow-ups, what you'd change |
1. Clarify
Restate the problem in your own words, then ask about the things that change the solution:
- What's the input size? Does it fit in memory?
- Can the input be empty? Contain duplicates? Negative numbers?
- Is the input sorted? Can I modify it?
- What should happen on invalid input?
Then work through one example by hand, out loud, and confirm the expected output with the interviewer. It takes a minute and catches misunderstandings while they're cheap.
2. Approach
Say the brute-force approach first, even if you can already see a better one. It shows you can get to a working answer, it gives you a fallback, and its cost is usually the clue to the improvement: "This checks every pair, so it's quadratic. If I could look up the complement in constant time, I'd only need one pass, so a hash map."
Agree the approach with the interviewer before you start typing. If they're nudging you somewhere else, this is the cheapest moment to change direction.
3. Implement
Write clean code at a steady pace. A few habits make a big difference:
- Narrate briefly. You don't need a running commentary. "Now I'll handle the empty case, then the main loop" is plenty.
- Name things well.
seenandcomplementare easier for both of you to follow thanmandx. - Use helper functions for anything you can describe in a phrase. You can even leave a helper unimplemented at first, say what it does, and come back to it.
- Don't optimise yet. Get the agreed approach working first.
4. Test
Don't announce you're done. Trace the code instead, line by line, with a small normal input, saying what each variable holds. Then try an edge case: empty input, a single element, all duplicates. When you find a bug (and you often will), fix it calmly and say what was wrong. Finding your own bug is a good sign, not a bad one.
5. Discuss
State the time and space complexity, and why. Then expect follow-ups: a constraint changes, the input becomes a stream, memory becomes tight. Reason out loud about what changes in your solution rather than starting over.
When you get stuck
Everyone gets stuck at some point, and interviewers expect it. What they're watching is how you respond.
- Say where you are. "I've got the brute force, and I think the repeated work is in this inner loop, but I don't yet see how to avoid it." That's useful information for the interviewer, and it often prompts a hint.
- Go back to an example. Work a small case by hand and look for the pattern you're following in your head.
- Try the usual tools. Would sorting help? A hash map? Two pointers? A stack? Thinking of the problem as a graph?
- Take hints well. If the interviewer offers a hint, acknowledge it and build on it. Using a hint well is part of what they're assessing.
What doesn't help is going quiet for several minutes. If you need thinking time, say so: "Give me a moment to think about the edge cases." Then think out loud when you can. We go deeper on this in our guide to thinking aloud in a coding interview.
How to prepare
Pick your language and get fluent in it
Use the language you're fastest and most accurate in, unless the job requires a specific one. Then make sure you know its standard library well enough not to hunt for basics: sorting with a custom key, hash maps and sets, queues and heaps, string manipulation. Looking up how to sort a list in the middle of the interview costs time and composure.
If the job does require a language you use less, practise in that language from the start. Our guide to preparing from the job description covers reading a posting for the stack and turning it into practice prompts.
Cover the common patterns, not every problem
There are thousands of practice problems, and you don't need to do all of them. What you need is fluency with the patterns that most of them use:
- Hash maps and sets for lookup and counting
- Two pointers and sliding windows on arrays and strings
- Sorting, and binary search on sorted data
- Stacks and queues
- Trees: traversal, recursion, and breadth-first search
- Graphs: breadth-first and depth-first search, and detecting cycles
- Heaps for "top k" and scheduling problems
- Basic dynamic programming: recognising overlapping subproblems
For each pattern, solve a handful of problems until you recognise when it applies. Recognition is the skill; memorised solutions don't transfer.
Practise the way the interview works
This is the part most people skip. Solving problems silently in an editor with autocomplete and unlimited time builds problem-solving skill, but not interview skill. Mix in sessions that look like the real thing:
- Set a timer for 45 minutes and follow the five phases.
- Talk out loud the whole time, even alone. It feels strange at first. That's the point: the interview shouldn't be the first time you do it.
- Use a plain editor without autocomplete for some sessions, closer to what many interview tools give you.
- Test by hand before running the code, so tracing becomes a habit.
- Get someone to interrupt you. A friend, a colleague, or a mock interviewer who asks "why a hash map?" mid-implementation is much closer to the real thing than a solo session.
How long to prepare
It depends on how recently you've done this kind of problem. If you solve algorithmic problems regularly, a week or two of timed, out-loud practice is often enough to get the interview habits back. If it's been years, plan for several weeks: time to relearn the patterns, then time to practise them under interview conditions. Short daily sessions beat occasional long ones.
The day before and the day of
- Check your setup: camera, microphone, a quiet room, and the interview tool if you know which one.
- Do one easy warm-up problem, out loud, to get into the rhythm. Don't cram new patterns the night before.
- Have water and something to write on for working examples by hand.
- At the start, ask whether you can run the code and which language they'd like, if it's not already agreed.
Where live coding fits in the loop
Live coding usually comes early, as a technical screen, and often again in the final rounds. It's rarely the only technical round for mid-level roles and above: system design usually appears too, and many of the same habits carry over (clarify first, say your reasons, test your design against edge cases). If that's next on your list, our 45-minute system design framework applies the same structure-first approach to design rounds.
Hardmode's live coding round is coming soon. The round page describes how it will work: an in-browser editor and an interviewer that follows your reasoning as well as your code. In the meantime, everything in this guide works with a timer, a plain editor, and a friend willing to ask "why?".