Live data from Hacker News

Why we don't hire programmers based on puzzles and tricks

37signals.com

21–30 of 460 posts

Re: Why we don't hire programmers based on puzzles and tricks

#21
Exactly. I never ask those questions. I ask practical problems that we solve every day here. Some are simplified of course.

Also I don't try to be confrontational, I take the "let's solve this together". That often puts them at ease and makes for a better experience and a more productive interview.

Now it is still an interview and the selection process could be brutal but this way I get the most _relevant_ knowledge and information about the applicant in the shortest amount of time.

Re: Why we don't hire programmers based on puzzles and tricks

#22

I've been on both sides of the hiring process - and most recently was going through the interview process again as I sought out my next opportunity. One thing that stood out to me was the way companies would approach the white boarding or coding challenges. While I agree with the articles issue with coding up a specific question (especially when it is yet another fizz-buzz - even if it has a twist to it) - the puzzle…

Do you think you can elaborate a little more on the exercise that you find interesting?

Re: Why we don't hire programmers based on puzzles and tricks

#23

At ITA Software, we found in-person quizzing to be a lot less useful an indicator than looking at puzzle (or other) code someone had written "offline". We also found puzzles to be a useful talent magnet. If you're Google (or perhaps 37Signals) you don't need a talent magnet. If you're a small company nobody's heard of, one can be quite helpful.

I remember actually working on some of the puzzles that were posted by ITA in the Boston MBTA subway. I didn't submit them (since I wasn't interested in working at ITA) but they introduced me to interesting problems. For example, there was a problem related to generating rebusses* whose solution contributed to the solution to another problem I was working on.

*http://en.wikipedia.org/wiki/Rebus

Re: Why we don't hire programmers based on puzzles and tricks

#24
post #14

Damn right. Even worse than whiteboarding random algorithms are logic puzzles. I can sort of see how implementing my own hash table fits into a dev job, but I why manhole covers are round, or light bulbs in a room has absolutely nothing to do with anything relevant in our field. People who use logic puzzles as proxies for anything in an interview have my everlasting scorn.

Logic puzzles are definitely useful ... how else can the interviewer feel superior (after all, he/she already knows the answer and has probably forgotten how they came by that answer).

If I was given a logic puzzle I would ask them "so how many times in the last year this company had to solve this particular puzzle here?".

Re: Why we don't hire programmers based on puzzles and tricks

#25
All great and well spending 20-40 hours trying someone out to see if they are a good fit, but this is only practical once you are down to a very short list of final candidates.

Nothing is said about how you actually get to this final list and that of course is where the real challenge lies.

Re: Why we don't hire programmers based on puzzles and tricks

#27

At ITA Software, we found in-person quizzing to be a lot less useful an indicator than looking at puzzle (or other) code someone had written "offline". We also found puzzles to be a useful talent magnet. If you're Google (or perhaps 37Signals) you don't need a talent magnet. If you're a small company nobody's heard of, one can be quite helpful.

I think it's the opposite. If the first thing you confront me with in your interview process is a puzzle and I don't know anything about your IT department, I'm going to assume that all your managers are pointy-haired bosses.

Re: Why we don't hire programmers based on puzzles and tricks

#28
post #21

Exactly. I never ask those questions. I ask practical problems that we solve every day here. Some are simplified of course. Also I don't try to be confrontational, I take the "let's solve this together". That often puts them at ease and makes for a better experience and a more productive interview. Now it is still an interview and the selection process could be brutal but this way I get the most _relevant_ knowledge…

The "lets solve this together" approach is always great - I've had people simply give up and not ask any further questions - those are generally "pass" situations. I rather see someone be genuinely interested in how to solve the question - the more questions they ask, the more I will be willing to help them, and the better they will actually do in the interview.

Re: Why we don't hire programmers based on puzzles and tricks

#29

Damn right. Even worse than whiteboarding random algorithms are logic puzzles. I can sort of see how implementing my own hash table fits into a dev job, but I why manhole covers are round, or light bulbs in a room has absolutely nothing to do with anything relevant in our field. People who use logic puzzles as proxies for anything in an interview have my everlasting scorn.

I think that question about why manhole covers are round is more of a urban legend than anything else. Or it might be a question asked to someone applying for a non-technical role, to see how they reason about the issue (though it is most definitely not the best question to achieve so).

Entirely an informational note, but the manhole-covers question actually originated at Microsoft if I recall correctly. There are several references to it around the web, and at least one primary source confirmation by an interviewer that he used the question on multiple occasions [1].

That said, the fact that it was first introduced by a highly successful company doesn't lend it any merit in my book.

[1] http://blogs.msdn.com/b/bgroth/archive/2004/09/27/235071.asp...

Re: Why we don't hire programmers based on puzzles and tricks

#30
post #2

Eight minutes, 21 points, zero specifics. I don't understand the 37signals love sometimes.

They maintain a fresh, honest, pragmatic view of software development and engineering. Those are qualities people can aspire to and identify with.
Post reply on HN