Hacker News new | ask | show | jobs
by tawb 1681 days ago
We've been having a larger internal debate about the type of leetcode interview and architecture questions we ask, and how valuable the signal is for testing something completely unrelated to our real work.

My two cents, the interviews here are going to help them assess how you work your way through problems, how you think and process, and how you communicate. That is a very valuable signal to get out of someone you're potentially going to be in the trenches collaborating with. That is the true value behind these route sets of challenges, much more son than "can this person code?"

We've hired engineers that have been absolutely amazing teammates in our department that on paper have had wonky technical interview questions, but it was because of the attitude and their approach in the moment that won us over.

They know you can code, they can see the OSS. The "hoops" here are for the intangibles.

1 comments

I have hired quite a few interview candidates that did AMAZING on the interviews and code tests, but turned out to be terrible programmers when it came to real world problems and/or team dynamics.

I've also had candidates that utterly bombed their interviews, but we gave them a chance and they turned out to be some of the best employees we ever had.

Unless someone's daily job is going to actually be writing leet puzzle code all day, leet puzzle code tests don't tell you all that much about how someone can actually perform their job, especially when under the pressure of a stressful interview environment.

I'm at a point now where I firmly believe that what all these leet code tests are actually about is GATEKEEPING. It's about making devs feel smug about themselves as they administer the test to the candidate, and it's about inflating their own egos. It's basically just a form of hazing. After all, anyone can ace those puzzles if they study them beforehand. You might as well be hiring them based off of whether or not they can solve a Rubik's cube.

So I stopped doing those types of interviews. I have a "gut check" conversation with the dev to get a rough sense of their skill level, and then I might hire them on a contract basis to do REAL work on my projects. If I like their work, I might hire them full time. It's the ONLY REAL way to find out how someone actually works, and whether or not you get along with them.