Why we don't hire programmers based on puzzles and tricks
1–10 of 460 posts
Re: Why we don't hire programmers based on puzzles and tricks
#2Eight minutes, 21 points, zero specifics.
I don't understand the 37signals love sometimes.
Re: Why we don't hire programmers based on puzzles and tricks
#3I think in addition to the measures he says, if you're hiring for a web position, it's good to make sure they understand how the stuff they're using functions. If they don't have a good grasp of how http works / url parameters / that kind of thing, then they can have some nice looking code which seems to work, but has faulty assumptions that can be security and bug nightmares down the road.
Of course, you could always take smart people and train them - but seriously, who does that anymore?
Re: Why we don't hire programmers based on puzzles and tricks
#4Ok... I was under the impression that 37Signals hired mainly remote workers. Could this account for the lack of a white board?
Personally, I use a whiteboard when hiring. It's not the deciding factor... but it's a part of the bigger picture. As part of a small start up I need to know right then and there if they know what I need them to know.
Re: Why we don't hire programmers based on puzzles and tricks
#5At 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.
Re: Why we don't hire programmers based on puzzles and tricks
#6Because no one will hire a writer based on his knowledge of long words.)
Excellence in the grammar is also irrelevant.
Re: Why we don't hire programmers based on puzzles and tricks
#7Eight minutes, 21 points, zero specifics. I don't understand the 37signals love sometimes.
I think people are up voting this one based off just the message, rather than the content. The message is important, I guess. Plus a lot of 37signals staffer's and friends use HN - they will likely be up voting this based off a Facebook post or similar. ~10 of the 21 points being users affiliated with 37signals is very likely.
Re: Why we don't hire programmers based on puzzles and tricks
#8I think in addition to the measures he says, if you're hiring for a web position, it's good to make sure they understand how the stuff they're using functions. If they don't have a good grasp of how http works / url parameters / that kind of thing, then they can have some nice looking code which seems to work, but has faulty assumptions that can be security and bug nightmares down the road. Of course, you could alway…
> Of course, you could always take smart people and train them - but seriously, who does that anymore?
Great, now I am depressed...
Re: Why we don't hire programmers based on puzzles and tricks
#9The best questions to ask are the ones that pertain to actual work.
Think of a problem you had before and solved or are attempting to solve. Ask the person being interviewed how they'd handle the problem. Do they have good process, intuition, and problem solving skills? Are they clear about communicating their intentions and explaining their decisions?
This isn't a trick - it's what the person is going to be doing there, in and out, every day.
Re: Why we don't hire programmers based on puzzles and tricks
#10Basically, most of the questions I see asked in interviews are contained in Levitin's algorithms book. The greatest potential for someone to excel at those trick interviews is to be fresh out of college.
I walked out of my first interviews, because 'I do not like programming games.' The first was a 4d matrix puzzle with more mathematical/theory roots than programming/logic.
My third interview started with the above quote and I was hired on the spot -- I believe they took it as a rebellion of every fresh out of college kid wanting to program video games.