50 interviews taught me algorithms wrong. Here's what matters.

I bombed a Google loop in 2019. Four rounds, rejected at the debrief. I'd been shipping production code for two years, owned features used by millions, and couldn't implement a balanced BST on a whiteboard under pressure.

Furious. Then embarrassed. Then curious.

So I did 50 interviews over 18 months. On purpose. Real loops at FAANG, mock interviews, mid-size startups. I kept notes on every single one.

The thing nobody tells you about Leetcode

Most engineers study algorithms like they're memorizing a cookbook. Learn merge sort. Learn Dijkstra. Grind 300 problems. They optimize for pattern recognition, not for thinking out loud.

That's exactly backwards.

In 47 of my 50 interviews, the interviewer already knew I could code. They were watching something else entirely: how I behaved when I was stuck. Do I freeze? Do I spiral? Do I talk through the problem or go silent and hope?

One interviewer at Stripe told me afterward: 'We can teach algorithms. We can't teach someone to stay calm and think clearly under uncertainty. That's what I'm actually hiring for.'

As a manager now, I hire the same way. I've watched brilliant engineers crumble because they couldn't debug in production while three people watched. That's just a whiteboard problem with higher stakes.

What actually transfers to your career

Two-pointer problems taught me to question my assumptions about traversal. Dynamic programming taught me to stop solving the same subproblem twice, which I now apply to team decisions constantly. Graph problems taught me to draw the system before touching the keyboard.

The algorithms aren't the point. Learning to think visibly is. Start there.