Coding Interview Execution: You Know the Approach. Here's Why You're Still Failing.
- Implementation mechanics break under pressure when they haven't been drilled to reflex, even on patterns you know cold.
- Edge cases are part of the problem, not afterthoughts. List empty input, single element, all duplicates, min/max values, and final-element handling before writing a line.
- Variable naming under stress directly impairs your own debugging.
windowStartbeatslevery time. - Coding interview time management: commit to an approach by minute 12, even if it's not optimal. A working O(n²) beats an unfinished O(n).
- Deliberate practice means testing at least three inputs per solution and doing a phase debrief after every medium to pinpoint where the breakdown happened.
The debrief always sounds the same. "I knew it was sliding window. I just couldn't get the implementation right." Your friend says this. You've said this. Everyone has said this at least once. The gap between recognizing the pattern and not fumbling the code is where most candidates actually lose.
Knowing the algorithm is maybe 30% of a medium problem. Executing it cleanly, under pressure, in 35 minutes is the rest. Here are the four things actually killing you on mediums. None of them are the algorithm.
The Moves You Think Are Automatic Aren't
Two pointers sounds like a beginner pattern. You've done it a hundred times. Then you're 20 minutes into an interview, your loop condition is wrong, your pointers are crossing each other like they're having an argument, and you genuinely cannot figure out why the last element never gets processed.
The moves you think are automatic often aren't. Off-by-one in binary search. Forgetting prev = curr before curr = curr.next. Returning result instead of result[0]. These aren't tricky edge cases. They're mechanics, and mechanics fail under pressure when you haven't drilled them to actual reflex. The drill works. The vibes don't.
When you practice, slow down on implementation even when you already know the approach. Code from scratch. Read every line. Name every variable deliberately. Fluency comes from boring repetition on the mundane stuff, not from grinding hards at midnight.
Edge Cases Are Not "Oh Right" Moments
Empty array. Single element. All duplicates. Integer overflow. Negative numbers when you assumed positive.
Your solution works on the example input. Then the interviewer says "what happens with an empty list?" and your code throws on line three. The interview just got a lot quieter.
Edge cases are not afterthoughts. They are part of the problem. Before you write a single line, spend thirty seconds listing them out loud. It costs nothing. Missing them costs you the offer. The five worth checking every time: empty or null input, single element, all elements the same, min and max values, and whether your loop processes the final element. That covers about 80% of the bugs you will actually hit.
This is also free interviewer points. Saying "let me think through the edge cases before I start coding" signals you know what you're doing. Even if you then miss one, you've already shown the habit.
When You Can No Longer Read Your Own Code
Fifteen minutes in, stressed, you have variables named i, j, left, l, res, and ans. You are no longer sure what j tracks. You fix a bug on line 12 and introduce one on line 8. You stare at your own code like it was written by someone else. Someone worse than you.
Messy variable names under pressure make you your own worst enemy. The interviewer can't follow your logic. More importantly, you can't either. Your brain is already at capacity and the last thing it needs is to decode what ans2 means in a function that also has ansFinal and temp.
Ah yes, temp, tempFinal, and tempFinalActual. A model of clarity.
Use names that say what the variable does: windowStart, maxSoFar, prevNode. It takes three extra seconds and saves five minutes of confusion. If you can't name a variable, you don't know what it is yet. Stop and think before writing. That pause is a feature, not a bug.
You're Spending the Wrong 45 Minutes
The 45-minute interview has four phases: understand, approach, implement, test. Most candidates who "ran out of time" spent 20 minutes on the approach and had 12 minutes left to code.
Commit to an approach at minute 12, even if it's not perfect. A working O(n²) solution with a note about the optimization beats an unfinished O(n) every time. Interviewers can evaluate a working brute force. They cannot evaluate a half-written optimal one. "I had the right idea" doesn't pass the bar.
If you're stuck past minute 10, say what you have out loud and ask whether it's worth implementing. That's not admitting defeat. The interviewer will often confirm it or nudge you somewhere better, and you'll still have time to finish. Asking is always better than staring at a blank editor for four more minutes.
Execution, Not Algorithm, Is the Offer
The algorithm is 30% of a medium problem. The rest is the implementation reflex you've built (or haven't), the discipline to check edge cases before coding, the names you choose when you're nervous, and your ability to treat 45 minutes as a finite resource that counts down whether you're ready or not.
You don't close these gaps by solving more problems at random. You close them through deliberate practice: code without peeking, test at least three inputs before declaring done, and after every medium ask which phase broke down and why. The debrief after each problem is where the actual learning happens.
Two things worth reading alongside this: four coding mistakes that get candidates rejected covers the communication failures that compound these execution gaps, and the debugging framework for when implementation goes sideways gives you a structured way to recover mid-interview instead of spiraling.
If you want to catch these gaps in real time, SpaceComplexity runs voice-based mock interviews with rubric feedback that tells you exactly which of these four areas is costing you.