Here's a pattern that plays out constantly in technical interviews.
A candidate spends three weeks grinding LeetCode. They can reverse a linked list in their sleep. They've memorized the sliding window template. They feel ready.
They sit down for the interview, get a medium-difficulty problem they basically know, work through it in their head... and say nothing for 20 minutes. The interviewer writes "poor communicator" in their notes. The rejection lands on Thursday.
If that stings a little, it's because it's extremely common. The candidate wasn't bad at coding. They were bad at interviewing — which is a different skill that almost no one practices deliberately.
Let's fix that.
What you're actually being graded on
Most candidates assume the interview is a coding test. It kind of is, but it's also kind of not.
At any company worth interviewing at, your score comes from four things — and most candidates only prepare for one of them:
If you spend 100% of your prep time on problem-solving, you're walking in with one quarter of the skill set. The good news is the other three are learnable, and most of your competition isn't working on them.
The actual prep plan
The pattern recognition you need in Phase 1
Run through these core patterns in roughly this order:
Arrays, strings, two pointers, sliding window → hash maps and frequency counting → recursion → trees (BFS, DFS) → binary search → graphs → dynamic programming → heaps and tries if you're going senior.
The goal isn't to memorize every pattern. It's to recognize them. When you see "find the shortest path," you should immediately think BFS. When you see "count subsets with a property," you should think DP. It's like learning to spot chord progressions in music — eventually it becomes automatic.
What good spoken problem-solving actually sounds like
Most people have no idea what "think out loud" means in practice. It doesn't mean narrating your code line by line. It means explaining your intent before and while you code.
| ❌ What most candidates do | ✅ What gets you the offer |
|---|---|
| Reads the problem, starts typing immediately | Restates the problem, asks 2–3 clarifying questions before touching the keyboard |
| Goes silent for 15 minutes | Names the approach and explains why before writing a single line |
| Writes code without narrating | "I am using a hash map here so I can check for complements in O(1) later..." |
| Presents the solution at the end | Traces through a test case out loud and mentions edge cases proactively |
Before writing any code, spend at least 15 seconds stating your approach out loud and why you chose it. Even if you're confident, even if the problem is easy. This habit alone will noticeably change how interviewers perceive you.
The five mistakes that kill otherwise good candidates
Jumping straight to code. You read the problem, you start typing. You haven't stated your approach, you haven't asked clarifying questions, and the interviewer has no idea what you're trying to do. Even 30 seconds of thinking out loud before touching the keyboard makes a huge difference.
"Oh I know this one." You've seen this problem before — great. Walk through it anyway. Interviewers want to see your process, not your memory. Saying "this is a sliding window problem" and writing the solution in 90 seconds tells them very little about you.
Silence when stuck. The worst thing you can do. If you freeze and say nothing for two minutes, the interviewer can't help you. If you say "I'm not sure how to get below O(n²) here, let me think about whether sorting the input first would help..." — that's fine. They can work with that.
Optimizing before you have a working solution. Get a brute force that works, explain its complexity, then optimize. A correct O(n²) solution explained clearly is worth more than an incorrect O(n log n) you're still debugging.
Skipping edge cases. Before you write a single line, mention the cases that could break things: empty input, single element, all duplicates, negative numbers. You don't have to handle all of them, but naming them shows you're thinking carefully.
"Strong coder. Hard to read. Unclear how they'd work on a team." This shows up constantly in rejection decisions — not because the candidate failed the technical problem, but because the interviewer spent 45 minutes watching someone type and came away with no signal.
The week before your interview
Stop learning new patterns. Your last week is consolidation, not expansion.
- Review your notes on every pattern you've studied
- 2–3 problems a day in timed conditions, narrating out loud
- At least 2 full mock interviews with feedback
- Get comfortable in the exact environment you'll be coding in
- Sleep. This is not optional advice. Cognitive performance under observation drops noticeably on 5 hours.
The real thing the interview is measuring
Here's a frame that might help: the coding interview is a proxy for "what would it be like to work through a hard problem with this person?"
Teams don't need someone who can silently solve LeetCode hards alone. They need someone who can think alongside other people, explain their reasoning, ask good questions, and write code that other humans can read.
The candidates who get offers aren't necessarily the best coders. They're the ones who make the interviewer feel like they just had a productive 45 minutes. That's a skill. And unlike raw algorithmic talent, it's one you can meaningfully improve in a few weeks.
So go practice out loud. It'll feel weird at first. That weirdness is you closing the gap.
Rubduck is a spoken-first interview simulator — it listens to how you explain your thinking, not just what you type. Try a free interview here.