Stop Failing Live Coding Interviews: Lessons from 100+ Real Sessions

I hired a developer once who didn't solve the problem. They got about halfway through, ran out of time, and their code didn't compile. I recommended them for an offer anyway. They'd spent the entire hour thinking out loud, asking clarifying questions, and treating me like a colleague debugging something together. That's when I realised live coding interviews are badly named. They're not really about the code. I've been in this industry for 12 years. I've interviewed for hundreds of roles, passed over 50 technical rounds, and conducted over 100 live coding interviews at places like Monzo and Superbet. The pattern is consistent: the best coders don't always get hired. The most vocal ones do. You can write flawless code in silence and fail. You can struggle through a mediocre solution while communicating beautifully and succeed. The interview is testing whether the team wants to spend 40+ hours a week working with you. The code is just the excuse to have that conversation. Why do we have to do live coding interviews? I remember one evening I was visiting my mum and she asked me: "How did the interview at Company X go? Did you get the job?". I'm sorry mum, I don't have an answer for you. It was only round 3 out of 7. I still have a system design, a live coding, a behavioural and team fit round to go. "What?" - she asked, mortified - "Isn't this for the same role you had before?" My mum's a medical doctor, you see. Changing jobs for her consists of spending 15 minutes with a medical director, mostly discussing salary and starting time and that's that. "How did the interview at Company X go? Did you get the job?" "What?" "Isn't this for the same role you had before?" Software engineering is a low-trust profession — and for a good reason too. The skill gap between developers can be staggering. You can have someone who's been coding for 15 years still struggling with basic algorithms, while an intern saves TikTok $300k by rebuilding a microservice in Rust. The landscape's also shifting rapidly. Adaptability is becoming more valued, whilst strong fundamentals and solid principles are going out of flavour. intern saves TikTok $300k by rebuilding a microservice in Rust You applied for your dream role and you got a call from HR. They're "impressed by your experience" and are "looking forward to advancing you to the next stages". You check your calendar. Live coding interview — tomorrow 3PM. Panic sets in. You start Googling "how to pass live coding interview", and finally land here. Let's get you that job. "impressed by your experience" "looking forward to advancing you to the next stages" Live coding interview — tomorrow 3PM "how to pass live coding interview" Types of live coding interviews Not all live coding interviews are created equal. Before you panic, it helps to know what format you're walking into. Here are the main types: LeetCode-style interview: Similar to a programming competition, you'll get a task that requires an understanding of a well-known algorithm ahead of time. This tells you very little about a software engineer's actual proficiency. I recommend two strategies to beat these: LeetCode-style interview Grind a website like LeetCode for a couple weeks, until you can comfortably solve easy and medium issues. This should prepare you for hard questions too. Generally, you'll need to know the same algorithms (DFS, BFS, FF, etc) but you'll use more than one as part of a more complex solution. Refuse to participate. If the company's specifically looking for competitive programmers, this style of interview makes sense. Otherwise, you can signal your disapproval by respectfully declining the interview. Grind a website like LeetCode for a couple weeks, until you can comfortably solve easy and medium issues. This should prepare you for hard questions too. Generally, you'll need to know the same algorithms (DFS, BFS, FF, etc) but you'll use more than one as part of a more complex solution. LeetCode DFS BFS FF Refuse to participate. If the company's specifically looking for competitive programmers, this style of interview makes sense. Otherwise, you can signal your disapproval by respectfully declining the interview. Take-home exercise with live counterpart: You'll start with a take-home exercise. Once you submit this, the hiring team will do a cursory pass to review your solution. If they're happy with it, you move onto round 2 — a live session where you'll have 10-30 minutes to make a small change or implement a tiny new feature. This proves you can actually write code and it wasn't a helpful acquaintance (whose name rhymes with Chad Jeep ET) who did it for you. Take-home exercise with live counterpart Pair-coding exercise: There's usually just one task, designed to take roughly one hour. This tests your problem-solving skills end-to-end. You'll get a well-defined problem statement and an environment to write code in. You'll collaborate with the interviewer(s) to converge on a solution. There's often a scale to this too — if you can't finish the entire task on time, it's often still acceptable. Pair-coding exercise Live programming trivia: You'll get a bunch of questions related to programming, usually increasing in difficulty. The first few questions simply check if you have some level of proficiency in the language. The next few will take a bit of time to think. You might start taking notes here — using code comments before you implement works well. The final 1-3 questions are designed to mislead you, mess with you, and make you want to give up working in software. Depending on language, this will include typical foot-guns, usual suspects when debugging, and sometimes exotic edge cases the interviewers came across. You may not solve these, and that's fine. Walk the interviewers through how you'd approach them. Live programming trivia Whiteboard: The final boss of tech interviews. I'm fortunate to have only taken part in two whiteboard interviews in my career. They're not as popular now as they once were. You'll often find them in use by legacy tech companies that hadn't revisited their hiring process in this millennium. If you're lucky, you can use pseudo-code to illustrate your ideas. You rarely have to write out the entire program. Visualising your intended solution using illustrations can also help (if allowed). Whiteboard Remember, your mileage may vary. Not everybody does interviews the same way, so if you want to be safe, prepare for multiple formats. 1. RTFM Read The Friendly Manual. Or in this case, read the email the hiring team sends you. Some companies will send you detailed instructions before the interview. They'll tell you what type of problem to expect, what technologies you'll be using, how long the interview will be, and what tools you'll need. Read this email. Then read it again. I've watched candidates show up unprepared for things that were explicitly spelled out in the invitation. Here's what you need to sort out before the interview starts: Get your webcam working. Most interviewers want to see you. It sucks talking at two letters in a circle for an hour. If your laptop webcam is broken, use your phone. If you don't have a webcam at all, let them know in advance — but understand that this might be a dealbreaker for some companies. Get your webcam working. Test your screen sharing. You'll probably need to share your screen or use a collaboration tool like CoderPad, Replit, or whatever the company provides. Make sure you can actually do this before the interview. I've seen 5 minutes wasted while a candidate tried to figure out how to share their screen. Test your screen sharing. CoderPad Replit Check your internet connection. If your internet is choppy, the interview will be painful for everyone. Audio cutting out, screen sharing freezing, code not syncing — all of this kills the collaborative feel of the interview. If you know your connection is unreliable, reach out to the hiring team up-front. They might let you use a different platform or reschedule for when you can get to a better location. Check your internet connection. Work with your recruiter. Sometimes you'll have an outside HR contact — a tech recruiter from an agency, for example. At my current job at Speakeasy, I worked with a recruiter who thoroughly explained each step and did his best to prepare me. Use them. Ask questions. They want you to succeed because they get paid when you get hired. Work with your recruiter. The worst thing you can do is show up to the interview and spend the first 15 minutes troubleshooting technical issues that you could have sorted out the day before. That's 15 minutes you're not solving problems and demonstrating your skills. Don't waste it. 2. Prove you're a good colleague Pretty boring point, right? Be employable. But here's the thing — you're not being interviewed just for your coding ability. You're being evaluated on whether the team wants to spend 40+ hours a week working with you. I've seen brilliant engineers get rejected because they were condescending during the interview. I've also seen average programmers get hired because they were pleasant to work with and showed they could learn. From my experience conducting over 100 live coding interviews, the most successful candidates all have one quality in common. They are vocal. They communicate their thought process, they ask clarifying questions, and they treat the interview like a collaborative problem-solving session rather than an exam they're being tested on. The interviewers are trying to answer one question: "Would I want this person on my team?" Your technical skills matter, but so does how you handle frustration, how you respond to hints, and whether you're gracious when you're stuck. Nobody wants to work with a genius who makes everyone around them miserable. "Would I want this person on my team?" A good rule of thumb: if the interviewer seems engaged, asking follow-up questions, and the conversation flows naturally, you're probably doing well on the "colleague" test. If there's awkward silence and you're typing away without speaking, that's a red flag. 3. Converse, but don't deflect Talk through your thought process. Constantly. It feels unnatural at first — like you're narrating a nature documentary about your own brain — but it's the single most valuable thing you can do in a live coding interview. "I'm thinking we need to iterate through this array. We could use a for loop, but since we're transforming each element, map might be cleaner here. Let me start with that and we can optimise if needed." "I'm thinking we need to iterate through this array. We could use a for loop, but since we're transforming each element, map might be cleaner here. Let me start with that and we can optimise if needed." This serves two purposes. First, it shows the interviewer how you think. They're not just evaluating your final solution; they're evaluating your problem-solving approach. Second, it gives them opportunities to course-correct you before you spend 15 minutes going down the wrong path. But here's the catch — don't use conversation as a deflection mechanism. I've interviewed candidates who, when asked a direct question, would launch into a 5-minute philosophical discussion about software engineering principles to avoid admitting they don't know the answer. If the interviewer asks "What's the time complexity of this?" and you don't know, don't respond with "Well, that's an interesting question. You see, complexity depends on many factors, and in the real world, we have to consider cache locality and..." Just say: "I'm not certain about the exact complexity. I think it might be O(n log n) because of the sorting step, but I'd want to verify that." "What's the time complexity of this?" "Well, that's an interesting question. You see, complexity depends on many factors, and in the real world, we have to consider cache locality and..." "I'm not certain about the exact complexity. I think it might be O(n log n) because of the sorting step, but I'd want to verify that." Honesty wrapped in thoughtfulness beats deflection every single time. 4. Your questions are just as important as your answers Have you ever wanted to say during an interview: "I'd just Google this"? Well, we actively encouraged candidates to use Google, Stack Overflow, and documentation during live coding interviews. Many companies follow this approach, but not all. Always ask your interviewer at the start: "Am I allowed to look things up?" The worst they can say is no, and you'll know where you stand. "I'd just Google this" "Am I allowed to look things up?" But even with Google available, asking questions is still crucial. In real work, you're constantly asking questions. You ask your product manager for clarification. You ask your colleagues about the existing architecture. You look at documentation. The interview should mirror this reality. When you're given a problem, don't immediately start coding. Ask questions: "What's the expected size of the input? Are we talking 10 items or 10 million?" "Should I optimise for time complexity or space complexity?" "Are there any edge cases I should be particularly aware of?" "What should happen if the input is null or empty?" "What's the expected size of the input? Are we talking 10 items or 10 million?" "What's the expected size of the input? Are we talking 10 items or 10 million?" "Should I optimise for time complexity or space complexity?" "Should I optimise for time complexity or space complexity?" "Are there any edge cases I should be particularly aware of?" "Are there any edge cases I should be particularly aware of?" "What should happen if the input is null or empty?" "What should happen if the input is null or empty?" I remember interviewing a senior engineer who spent the first 8 minutes of a 45-minute interview just asking questions about the requirements. I started getting concerned they wouldn't have enough time to develop a solution. But then, armed with the extensive set of requirements and conditions they'd built up, they breezed past the implementation. They got the offer. Be careful, though: the questions need to be genuine clarifications, not thinly-veiled requests for hints. There's a difference between "What's the expected input size?" (legitimate question) and "Would a hash map be useful here?" (fishing for the solution). "What's the expected input size?" "Would a hash map be useful here?" A good rule of thumb is, if you're about to answer a question starting with "it depends", instead, explain that you need further clarification and list what factors your solution would depend on. This shows you understand the tradeoffs without making the interviewer drag it out of you. "it depends" 5. If you don't know - ask This sounds identical to tip 4, but it's subtly different. Tip 4 is about asking questions to clarify requirements. This tip is about asking questions when you're genuinely stuck or don't know something. I've watched candidates waste 20 minutes trying to remember the exact syntax for something trivial, too embarrassed to ask. Meanwhile, I'm sitting there thinking "just ask me, I'll tell you, and we can move on to the interesting part." "just ask me, I'll tell you, and we can move on to the interesting part." If you can't remember whether JavaScript's sort() mutates the array or returns a new one, just ask. If you're blanking on the name of that algorithm you learned in university, describe what you remember and ask if the interviewer knows what it's called. If you're stuck on a problem and can't see a way forward, explain where you're stuck and ask for a hint. sort() The key is being specific about what you don't know. Not "I don't know how to do this" but "I'm stuck on how to efficiently find duplicates in this array. I'm thinking about using a Set, but I'm not sure if that's the right approach here." "I don't know how to do this" "I'm stuck on how to efficiently find duplicates in this array. I'm thinking about using a Set, but I'm not sure if that's the right approach here." This does two things. First, it shows you're not just giving up — you've thought about the problem and have a hypothesis. Second, it gives the interviewer useful information about where to help you. They can say "the Set approach is good" or "think about what you'd need to achieve with a Set" or "there's actually a simpler approach if you sort first." "the Set approach is good" "think about what you'd need to achieve with a Set" "there's actually a simpler approach if you sort first." Nobody expects you to know everything. But they do expect you to be resourceful when you don't. 6. This is not the time to try new things During one coding interview I conducted, the candidate mentioned they knew C# better — one of the languages we offered for the interview. But they'd been writing Scala for the past couple of years, and since Scala runs on the JVM just like Java, they decided to do the interview in Java instead. Perhaps they anticipated that knowledge of the runtime environment might prove more useful. It didn't. Our live coding task is very simplistic — it's purely about comprehension and basic programming concepts. The bet did not pay off. They spent precious time fighting with Java syntax they weren't fluent in, when they could have breezed through the problem in C#. The interview is not the time to experiment with that new framework you heard about on Hacker News. It's not the time to try functional programming for the first time. It's not the time to optimise for what you think the interviewer wants to see. Use the tools you know well. Stick to what you're comfortable with. If you know Python better than Java, use Python (if you have the choice). If you normally use a for loop instead of reduce, use the for loop. The interviewer wants to see you solve the problem, not watch you struggle with syntax you don't know. reduce There's one exception: if the interviewer specifically asks you to use something you're not familiar with, that's different. But even then, you can say: "I haven't used X much before, so I might need to look up the syntax, but here's my approach..." "I haven't used X much before, so I might need to look up the syntax, but here's my approach..." 7. Your interviewers are also human They're probably nervous too. Maybe this is their first time conducting an interview. Maybe they had a rough morning. Maybe they're worried about whether they're asking the right questions. I've been on both sides of this. As a candidate, I used to treat interviewers like judges — distant, infallible authorities evaluating my worth. As an interviewer, I realised we're just regular developers trying to figure out if we'd work well together. This means a few things practically: If something's unclear in the problem statement, it's probably because the interviewer didn't explain it well, not because you're supposed to magically intuit it. Ask for clarification. If the interviewer seems distracted or checks their phone, don't take it personally. Something might have happened at work. It's not a reflection on you. If you notice a typo in the problem or think there's an issue with the test cases, point it out politely: "I think there might be an edge case here that we haven't covered — what should happen when...?" "I think there might be an edge case here that we haven't covered — what should happen when...?" And here's the big one: you can build rapport. A bit of small talk at the start helps. "How's your day going?" or "Thanks for taking the time to interview me" goes a long way. During the interview, when they give you a hint, you can say "Ah, that's a good point, I hadn't considered that." Show you value their input. "How's your day going?" "Thanks for taking the time to interview me" "Ah, that's a good point, I hadn't considered that." The interview is a two-way street. You're evaluating them as much as they're evaluating you. 8. A clear thought process is worth a thousand lines of code I'd rather see a candidate write 20 lines of clear, well-reasoned code than 200 lines of clever, convoluted nonsense. When you're coding in an interview, clarity trumps cleverness. This means: Name your variables properly. Not x and y, but userCount and maxRetries. Yes, even in an interview. It takes 3 extra seconds and makes your code infinitely more readable. Name your variables properly. x y userCount maxRetries Break down complex logic. If you're writing a gnarly one-liner that does five things, split it into multiple steps with intermediate variables. The interviewer needs to follow your logic. Break down complex logic. Add comments if it helps. A quick // Find all users who haven't logged in for 30+ days before a complex filter operation can save the interviewer from having to reverse-engineer your intent. Add comments if it helps. // Find all users who haven't logged in for 30+ days Think out loud before you code. Say "I'm going to iterate through the array and build a hash map of values to indices" before you start typing. This way, if you're on the wrong track, the interviewer can course-correct you early. Think out loud before you code. "I'm going to iterate through the array and build a hash map of values to indices" I once interviewed a candidate who solved the problem with an incredibly elegant recursive solution that I couldn't follow. When I asked them to explain it, they couldn't articulate why it worked. Compare that to another candidate who wrote a straightforward iterative solution with clear variable names and walked me through each step. The second candidate got the offer. Your goal isn't to impress the interviewer with your brilliance. Your goal is to demonstrate that you can write code that your teammates will understand in six months. 9. Know your bounds Time management in interviews is brutal. You're being evaluated while simultaneously trying to solve problems under a ticking clock. Here's what I recommend: At the start, clarify the time limit. "We have 45 minutes, right?" This sets your internal timer and helps you pace yourself. At the start, clarify the time limit. "We have 45 minutes, right?" If you're stuck for more than 3-5 minutes, speak up. Say: "I've been thinking about this for a few minutes and I'm not making progress. Can I get a hint?" Don't burn through half your interview time being stubborn. If you're stuck for more than 3-5 minutes, speak up. "I've been thinking about this for a few minutes and I'm not making progress. Can I get a hint?" Know when to move on. If the interview has multiple problems and you're stuck on the first one, ask: "Should I keep working on this, or would you like me to move to the next problem?" Sometimes interviewers want to see breadth, not just depth on one problem. Know when to move on. Save time for testing. Don't spend 40 minutes coding and then have no time to test your solution. If you finish with 5-10 minutes left, walk through your code with some example inputs. Find your own bugs before the interviewer does. If the environment already has tests, make sure you run them! Save time for testing. make sure you run them Be realistic about optimisation. If you have a working O(n²) solution with 5 minutes left, don't try to refactor it to O(n log n). Mention what you'd optimise given more time, but deliver a working solution first. Be realistic about optimisation. O(n²) O(n log n) I failed an interview once because I spent 35 minutes perfecting the first of three problems, then had to rush through the other two. I was so focused on making the first solution perfect that I lost sight of the bigger picture. Don't be me. 10. Show depth, but don't force it If you've worked with distributed systems, caching strategies, or complex architectural patterns, and the problem naturally leads there, mention it. But don't shoehorn advanced concepts into a simple problem. I've interviewed candidates who, when asked to implement a simple string reversal function, launched into a 10-minute dissertation on Unicode normalisation, grapheme clusters, and right-to-left text handling. Yes, those are real concerns in production systems. No, they're not relevant when the interviewer just wants to see if you can iterate backwards through a string. The key is reading the room. If the interviewer seems interested and asks follow-up questions about your experience with distributed systems, expand on it. If they're nodding politely and trying to move on, you've gone too deep. Here's a good pattern: solve the problem first, then offer depth. "This solution works for the requirements we discussed. In production, I'd also consider [specific advanced concern], but I'm assuming that's out of scope for this exercise. Should we discuss that?" "This solution works for the requirements we discussed. In production, I'd also consider [specific advanced concern], but I'm assuming that's out of scope for this exercise. Should we discuss that?" This approach shows you understand the broader context without derailing the interview. You demonstrate expertise while respecting the interviewer's time and agenda. I once made the mistake of spending 15 minutes explaining how I'd implement rate limiting for an API endpoint when the question was just "write a function that validates email addresses." The interviewer had to politely interrupt me to get back on track. Learn from my failure: answer the question asked, not the question you wish they'd asked. "write a function that validates email addresses." +1 Always ask for feedback Whether you get the job or not, ask for feedback. Most companies won't give you detailed feedback (liability reasons, mostly), but it's worth asking anyway. If you get the offer: "Thanks so much! Can I ask what went well in the interview? I'm always looking to improve." "Thanks so much! Can I ask what went well in the interview? I'm always looking to improve." If you get rejected: "Thank you for letting me know. I understand you may have policies around feedback, but if you're able to share anything about how I could improve for future interviews, I'd really appreciate it." "Thank you for letting me know. I understand you may have policies around feedback, but if you're able to share anything about how I could improve for future interviews, I'd really appreciate it." Some interviewers will ignore this. Some will give you generic platitudes. But occasionally, you'll get genuine, actionable feedback that helps you in your next interview. Some invaluable feedback I've received in the past: "you over-explained things, didn't consider your audience" "your solution was correct but I struggled to follow along with your thought process" "it's clear you have a lot of breadth, but we'd appreciate a bit more depth on some topics" "you over-explained things, didn't consider your audience" "you over-explained things, didn't consider your audience" "your solution was correct but I struggled to follow along with your thought process" "your solution was correct but I struggled to follow along with your thought process" "it's clear you have a lot of breadth, but we'd appreciate a bit more depth on some topics" "it's clear you have a lot of breadth, but we'd appreciate a bit more depth on some topics" Interviews are a gold mine for your self-improvement journey. Here's something most candidates don't know: some interviewers are comfortable chatting about the interview afterwards directly — via email or LinkedIn. I'd always ask if this is an option. At the end of the interview, you can say: "Would it be alright if I reached out to you directly on LinkedIn if I have any follow-up questions?" Most will say yes, and it opens a channel for more candid feedback than what HR might provide. "Would it be alright if I reached out to you directly on LinkedIn if I have any follow-up questions?" At the very least, asking for feedback shows you're someone who wants to grow. Even if you don't get useful information, you leave a positive impression. During my time at Docler, we had a frequent flyer candidate, who'd come back diligently, every six months. He always left with feedback and never made the same mistake twice. On the last occasion, he did a perfect interview. Still works there to this day. The worst outcome is you hear nothing. The best outcome is you learn something that gets you the next job. Always worth asking. Good luck! Good luck! I wish the best of luck to you in your upcoming interview! If my tips helped you, or if you have more useful tricks to share, let's chat!