In 2020 four researchers ran an experiment that should have changed how everyone preps. They took 48 computer science students and split them in two. Half solved problems on a whiteboard with an interviewer watching and asking them to explain. Half solved the same problems alone in a private room. The watched group performed worse by more than half. Same students, same problems, half the score. The finding got published at ACM FSE and the authors said the quiet part out loud: the interview was measuring anxiety, not coding ability (NC State, 2020).

I think that one study explains most coding interview failures better than any LeetCode count does. If you can solve a medium in your kitchen but freeze the second a stranger is watching your cursor, you don't have an algorithms problem. You have a performance problem. And the standard advice (grind 300 more problems) is treatment for the wrong disease.

So this isn't a grind-more post. It's about the parts that decide the outcome once you already know roughly what a sliding window is: how you talk, how you recover when you're stuck, and how to stop the observation effect from eating half your brain.

What the interviewer is actually scoring

Most rubrics at companies like Google, Stripe, and Meta break the score into four buckets, and only one of them is the code. The other three are things you can fail with a fully correct answer.

Notice that three of the four are observable behaviors, not correctness. An interviewer can give a hire on a partially solved problem if the communication and recovery were strong. They can give a no-hire on a fully solved one if you went silent for nine minutes and snapped when corrected. I've watched both happen.

The talking is the skill

Here's the thing nobody practices because it feels stupid to practice. Talking through code while you write it is a separate motor skill from writing code. Your brain has a limited working memory budget, and under the gaze of an interviewer that budget shrinks (that's the cognitive-load finding from the NC State study). Trying to narrate and solve at the same time, for the first time ever, during the highest-stakes 45 minutes of your month, is a setup to fail.

The fix is unglamorous. You rehearse talking out loud until it's automatic, the way you'd rehearse a presentation. Not "I'll explain after." During. Out loud. To an empty room if you have to. Record one session and play it back. It's painful. You'll hear yourself say "um" forty times and trail off mid-sentence. That's the point, you can't fix what you can't hear.

A structure that holds up under pressure:

1. Restate the problem in your own words and ask one clarifying question, even if you're sure. It buys thinking time and shows you don't just charge in.
2. Say the brute force out loud first. "The obvious approach is nested loops, that's O(n squared). Let me see if I can do better before I commit." Now you have a fallback on the table.
3. Narrate the decision, not the syntax. Nobody cares that you typed a for loop. They care why a hash map instead of a sorted array.
4. Test out loud at the end. Walk one real input through your code line by line. This is where you catch the off-by-one before they do.

Getting stuck is not the failure. Staying stuck is.

Every interviewer expects you to get stuck. The good ones build it in on purpose. What they're watching is the next 90 seconds.

The worst move is the silent freeze, where you stop talking and stare at the screen hoping the answer arrives. From the other side of the call that looks like panic, and panic reads as "can't function under pressure," which is the exact thing the rubric punishes. The recovery move is to externalize the stuck-ness. Narrate the wall. "I'm stuck because my approach needs the array sorted but then I lose the original indices. Let me think about whether I can store the index alongside the value." Half the time you solve it just by saying it. The other half, you've handed the interviewer a clean place to drop a hint, and taking that hint gracefully scores points on the feedback bucket.

Pattern recognition beats problem count

On the prep itself, I'll say something a little contrarian: solving 400 problems is mostly a waste if you're not sorting them by pattern as you go. Interview problems aren't infinite. They cluster. Two pointers, sliding window, BFS and DFS on graphs, binary search on the answer, a handful of DP shapes, intervals, heaps. Maybe fifteen patterns cover the overwhelming majority of what gets asked at the phone-screen and onsite level.

The skill you're building is not "I have seen this exact problem." It's "this smells like a sliding window because I'm asked for a contiguous subrange and a running max." Once you can name the pattern in the first 60 seconds, the coding part gets a lot calmer, because you're retrieving a known shape instead of inventing one live. I'd rather you do 5 problems per pattern and be able to explain why the pattern fits than 50 random ones you half-remember.

Python is worth a mention here. It's now the most popular language among people learning to code according to the 2024 Stack Overflow Developer Survey, and it's the language I'd reach for in an interview unless the role demands otherwise. Less ceremony, fewer lines, more of your shrinking working-memory budget left for the actual problem.

Where AI tools sit, and where they don't

A quick reality check on the tools, because the temptation in 2026 is to lean on them too hard. Developers themselves are split on trusting AI output. In the same Stack Overflow survey, 62% of respondents said they currently use AI tools, but only 43% felt good about their accuracy, and around 45% of professional developers thought AI was bad at handling complex tasks (Stack Overflow, 2024). That gap matters in an interview. If you outsource your thinking to a tool you don't fully trust, and the interviewer asks "why did you choose that," you've got nothing to say. The tool can't pass the communication and recovery buckets for you. Those are yours.

What we hear from candidates using the copilot

We talk to a lot of candidates who run the LastRound AI copilot during live rounds, and the pattern in what they tell us lines up almost exactly with that NC State finding. The thing they say helped wasn't the answer appearing. It was that having a quiet prompt nudge them ("state your approach before you type", "you've gone silent, narrate") broke the freeze loop. They describe it less like cheating and more like a metronome that kept them talking when their instinct under pressure was to clam up and stare.

The candidates who get the least out of it are the ones who treat it as a crutch for not knowing patterns at all. When you don't have the underlying shape in your head, no real-time hint saves you, because you can't explain a borrowed idea convincingly. The ones it helps most already know the material and just lose access to it when watched. Which is, again, most people.

A four-week shape, not a four-week rule

If you want a rough plan, here's one. It's not gospel and the durations depend heavily on where you're starting from. Adjust.

The one thing I'd tell my earlier self

Stop measuring prep in problems solved. Start measuring it in minutes spent solving while someone, or something, watches and you keep talking anyway. That's the rep that transfers. Everything else you can already do alone in your kitchen, and your kitchen is not where you'll be when it counts.