Twelve. That's how many coding interviews I failed before I passed one.
Not "didn't get the offer." Failed. Frozen at the whiteboard. Blanked on a problem I'd literally solved the week before. One interviewer actually said, "Do you want a minute?" in the gentle voice you use on someone who's clearly drowning.
For a long time I thought the problem was that I didn't know enough algorithms. So I did what everyone tells you to do: I ground through hundreds of LeetCode problems. And I still failed. That's the part nobody warns you about — you can "study hard" and still lose, because you're practising the wrong thing.
Here's what those twelve failures actually taught me.
What was really going wrong (it wasn't the algorithms)
When I finally reviewed my failures honestly, a pattern showed up. I wasn't losing because I didn't know binary search. I was losing because:
- I jumped straight into code without understanding the problem.
- I went completely silent the moment I got stuck, so the interviewer had no idea what I was thinking.
- I panicked at "I don't know," instead of treating it as a starting point.
The interviewer isn't grading a finished solution. They're watching how you think when you don't have the answer yet. I was treating it like an exam. It's actually a conversation.
How I started preparing differently
After failure number eight, I stopped just solving problems and started practising the interview itself. Three changes did most of the work.
1. I talked out loud — always. Even alone, I solved every problem by narrating it. "Okay, the input is a sorted array, so maybe binary search… let me check the edge case where it's empty." It felt ridiculous. It also rewired how I think under pressure.
2. I spent the first two minutes asking questions, not coding. What's the input size? Can there be duplicates? What should happen on empty input? Half the time, those questions revealed the actual problem — and showed the interviewer I think before I type.
3. I practised being stuck. I'd deliberately pick problems slightly too hard, just to rehearse staying calm and reasoning out loud when I had no idea. Being stuck gracefully is a skill. Almost nobody practises it.
When the shift actually happened
The change wasn't sudden. It was interview number thirteen, and I got a problem I didn't fully know how to solve. Old me would have frozen. Instead I said, "I'm not sure of the optimal approach yet, but let me start with the brute force and improve it." I talked through it. I got stuck. I said so. I worked my way back out.
I didn't write perfect code. I wrote honest code, out loud, like a teammate would. They made me an offer two days later.
That's when it clicked: the interviewers were never looking for someone who already knew the answer. They were looking for someone they'd want next to them when nobody knows the answer.
What I'd tell my younger, terrified self
If you're failing interviews right now, please hear this: it probably isn't your intelligence, and it might not even be your preparation hours. It's what you're practising.
- Solve fewer problems, but solve them out loud.
- Treat "I don't know" as the start of the conversation, not the end of it.
- Remember the person across the table has been exactly where you are.
Twelve failures felt like proof I wasn't cut out for this. They were actually just twelve rehearsals for the one that worked. You're probably closer than you think.
