Your Coding Interview Prep Is Broken. Five Diagnoses.

You've been grinding for weeks. Daily LeetCode, solution reviews, NeetCode walkthroughs at 1.5x speed. The thought of an actual interview still makes your stomach drop.

The problem probably isn't effort. It's method. Five coding interview mistakes that quietly explain why the grinding isn't converting into confidence.

You're Reading Solutions, Not Building Them

You get stuck, peek at the solution, read it, think "okay, that makes sense," and move on. Satisfying. Efficient. Completely useless.

Recognition and recall are completely different cognitive skills. A 1978 paper by Slamecka and Graf, in the Journal of Experimental Psychology, ran five experiments and showed that information you generate yourself is recalled substantially better than information you simply read. The interview problem will be slightly twisted from what you practiced. Your pattern recognition won't fire. Your recall, which you haven't trained because you've been reading, will have nothing to give you.

You know that feeling when you've watched a cooking tutorial three times and then can't boil an egg? Same energy. Different stakes.

The fix: close the solution, open a blank editor, write it from scratch. If you can't, you didn't understand it yet. Do this for every problem you've peeked at in the last month. It's slower and more frustrating. That's the point.

Shooting star wish meme: "I wish I could ace the interview without grinding LeetCode" The wish. The problem is not that you're grinding. It's that you're grinding without producing anything.

You've Never Solved Anything on a Clock

A 45-minute timer changes everything. Your working memory shrinks. Syntax you've typed a thousand times suddenly feels uncertain. Simple bugs take three re-reads to spot.

The interview isn't testing whether you can solve the problem. It's testing whether you can solve it under these exact conditions. If you've never practiced with a countdown running, you've been training for a completely different event. Like training for a race by napping.

Set a timer every session. Finish or fail on the clock. The discomfort at minute 38 is the specific thing you're building tolerance for. Uncomfortable now. Useful later.

You're Grinding the Wrong Difficulty

Hards feel productive. They're hard. You must be getting sharper. Right?

Meta's frequently-asked question pool breaks down to 26 Easy, 60 Medium, and 14 Hard. Amazon's is similar. Mediums train something hards don't: the ability to navigate a layered problem. Hard problems are often binary. You either see the key insight or you spend 90 minutes in silence. Mediums have a brute force, then an optimization, then usually one more level. That structure gives interviewers three or four independent signals to score you on. A hard you don't crack gives them one signal: nothing. The sliding window algorithm is a great example of the layered medium archetype: a brute-force O(n²) first attempt, a one-idea collapse to O(n), and then a follow-up twist.

Andrej Karpathy tweet announcing he joined Anthropic, with a reply asking "what leetcode questions did they ask you during the interviews" Nobody escapes the LeetCode question. The only variable is whether you've prepared for the format it actually shows up in.

If you're below 50 mediums in a category, skip the hards. More on why the difficulty split matters here.

You've Never Practiced Talking While Thinking

Most people prep by writing code in silence. Headphones in, focused, no distractions. Also: not what the interview looks like.

Coding interviews are scored on four dimensions: algorithms, coding, communication, and problem-solving. If you've only practiced writing code, you've trained exactly one of those four. The other three require speaking out loud while your brain is simultaneously solving a problem. These two things actively interfere with each other until you've practiced them together enough times that they don't.

An interviewer who logged over 600 interviews on interviewing.io ranked going silent as one of the five most common problems candidates show, alongside jumping straight to code and finishing thoughts internally. The silence signals no process. Your interviewer is building a written record of what you did and said. An empty page is difficult to argue for in a debrief.

You don't need a partner to start. Narrate to yourself. Explain your approach to your monitor. It feels ridiculous. Do it anyway. A concrete method for doing this.

You've Never Done a Full Mock Interview

Everything above assumes you can actually execute when it counts. Most people discover they can't the first time they try.

A full mock means a real problem, a timer, verbal narration, no pausing, no Googling, and honest feedback at the end. The goal isn't to test yourself. It's to desensitize yourself to the format.

The first mock will be rough. The fifth will feel like practice. The tenth will be boring. Boring is exactly what you want walking into the real thing.

Which of These Is Actually You?

Look at your last two weeks. Did you produce solutions from scratch or read them? Did you use a timer? Were you working mediums or chasing hards? Did you say a single word out loud? Did you run one full mock?

Most people find at least three of the five missing. That's why the effort isn't converting into confidence.

SpaceComplexity runs voice-based mock interviews with rubric feedback on all four dimensions. Start fixing the gaps tonight.