By Deane Barker | January 7, 2012 | 2 Comments
Why we don’t hire programmers based on puzzles, API quizzes, math riddles, or other parlor tricks: I’ve always had a very uneasy feeling about those job interview programming puzzles because I suspected I would be terrible at them. I’m glad someone else feels the same. Having a candidate perform under such unnatural circumstances just can’t be an accurate indication of their potential value to your organization.
I’ve known fabulous programmers flame out in the quizzing cage and terrible ones excel. So unless you’re specifically hiring someone to design you the next sorting algorithm, making them do so on the white board is a poor gauge of future success.
The only reliable gauge I’ve found for future programmer success is looking at real code they’ve written, talking through bigger picture issues, and, if all that is swell, trying them out for size.
Read some of the comment – they’re quite good. The first one is great and completely true.
I once did not get a job because I couldn’t do vanilla JS on paper, and I couldn’t solve a faux columns problem in pure CSS without hacks or something…[…]
Anyway… I remember saying to the guy, “I don’t know how to do this but in a normal situation I would spend 5 minutes googling for it, find the solution, and implement it. After a couple of regular tasks, I’d probably have it memorized for a while.”
It’s like, dude: No one works like this. No one is forced to write code on whiteboards and paper in front of their boss without the internet to look things up. That would be very counterproductive.
Programming puzzles persist in interviews because they are measurable and tough-minded. But they don’t really relate to daily work. We have a developer test we give as a take-home project. Devs making it to the second round get the test, then come in after they say they are done to present a solution. So far that has worked very well for us.
So we’re trying to hire a C++ person for some massively parallel stuff we do. We get a resume which is FANTASTIC… the guy has not only done years and years of C++, but has mentored other people, lead teams… wow! We get him in and he’s, well, a little odd, and doesn’t seem to quite know C++ as well as we expect.
So our tech lead gives him the “Fizz Buzz” programming thing, and he gets it wrong. Worse, he says words to the effect of, “See? I’m good at this technical stuff!” So no offer to him.