Confessions of a Hiring Manager: Why Your LeetCode Score Doesn't Matter

The Interview Theater

We have a problem in our industry. We interview for "Computer Science Professor" and then we hire for "Web Plumber."

I manage a team of 15 senior engineers. In the last five years, exactly zero of them have needed to implement Dijkstra's algorithm from scratch. Yet, our interview process—until recently—demanded it.

I recently reviewed the data from my last 50 hires. I looked at their interview scores (coding performance) versus their actual job performance ratings one year later.

The Correlation was Zero.

In fact, it was slightly negative. The candidates who optimized purely for LeetCode "Hards" often struggled with the ambiguity of real-world engineering. They could optimize a loop, but they couldn't gather requirements from a confused Product Manager. They treated conversation as a distraction from the code, whereas in reality, conversation is the work.

What I Actually Look For

If I'm not looking for algorithm memorization, what am I looking for?

1. The "Debug Mindset"

In my new interview loop, I give candidates a broken codebase. It's a simple Todo app that crashes when you add a blank item.

I watch how they debug. Do they console.log randomly? Do they pause to read the error message? Do they make a hypothesis before changing code?

One candidate spent 20 minutes silently reading code, then changed one line and fixed it. Another candidate frantically typed for 30 minutes, changed 50 lines, and introduced three new bugs. I hired the first one. She is now my Tech Lead.

Debugging reveals how you think. It shows patience, systematic logical deduction, and comfort with the unknown. LeetCode shows memorization; debugging shows intelligence.

2. Communication Under Pressure

Engineering is a team sport. I ask questions like, "Tell me about a time you disagreed with a technical decision."

I don't care who was right. I care about how they handled the conflict. Did they sulk? Did they sabotage the project? Or did they "disagree and commit"?

I once interviewed a rigid "10x engineer" who mocked the interviewer for not knowing a specific Rust crate. He technically aced the coding challenge. represent. I gave him a "Strong No Hire." A brilliant jerk will destroy your team culture faster than a mediocre coder will destroy your unexpected uptime.

The "Airport Test": It's a cliché, but valid. If I was stuck in an airport with this person for 4 hours, would I want to talk to them, or would I pretend to sleep?

3. Curiosity Over Knowledge

Technology expires. React will die. Kubernetes will be replaced.

I ask: "What have you learned recently that had nothing to do with work?"

The best candidates light up. They talk about 3D printing, or baking sourdough, or learning how LLMs actually work under the hood. This curiosity is the leading indicator of long-term success. It means they will learn whatever tool we use in 2028.

I once hired a bootcamp grad over a CS major because the bootcamp grad had built a "Pokemon Team Builder" app simply because he wanted to. He faced problems he didn't have to face, solved them, and deployed it. That "hacker spirit" beats a 4.0 GPA every time.

The Resume Red Flags

Job Hopping without Growth: If you've had 5 jobs in 4 years, I'm worried. Not because of "loyalty"—loyalty is dead—but because you've never stayed long enough to live with the consequences of your own code. You ship features and leave before the bugs appear. You are a "greenfield" developer who has never maintained a legacy codebase.

Keyword Stuffing: If you list 30 languages, I assume you know none of them deeply. Be a specialist. Tell me you know Python and TypeScript inside out. Don't tell me you know C++, Java, Rust, Go, Haskell, and Fortran unless you are 60 years old. Honesty about what you don't know is a green flag.

The Take Home Assignment Controversy

I've moved away from whiteboard coding to paid take-home assignments. "Build a small API endpoint." "Refactor this React component."

It mirrors the real job. You can Google things. You can use your own IDE. You can listen to music.

The results are stark. Some "Senior" engineers submit code that doesn't compile. Some "Junior" engineers submit code with perfect documentation and unit tests. It is the great equalizer.

Conclusion

Stop grinding dynamic programming problems for 4 hours a day. Instead, build something. Put a messy, half-finished project on GitHub. Write a blog post about a bug you couldn't solve. Show me you are a human who loves building things, not a robot who memorized Cracking the Coding Interview.

When I hire, I'm hiring a colleague, not a function runner. Be the colleague you'd want to sit next to.