Shameless plug: I've been working on this : http://initialround.com to allow applicants to complete an interview at home and in a browser, to eliminate the pressure of the "quizzing cage". I'd be interested to hear people's take on this approach.
Why we don't hire programmers based on puzzles and tricks
11–20 of 460 posts
Re: Why we don't hire programmers based on puzzles and tricks
#12Damn 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.
Re: Why we don't hire programmers based on puzzles and tricks
#13I remember when I was prepping for my Microsoft interview. There was so much lore online as to the types of questions they'd ask and how to prepare. I even found 'How Would You Move Mount Fuji?' in the library and started reading through it. It was an absolute waste of time as I, fortunately, learned weeks before the interview. As an example, one of the questions I was asked was 'how would you write the C function strcmp() without using any libraries?'
My gripe these days is that places I've interviewed with now that I have a few years of experience are still concerned about big-O notation and a lot of the more academic questions. I feel like I shouldn't have to go back to my college notes to prep for an interview for a job that I'd really be using my current experience for. I think it comes down to other developers not spending time really thinking about the quality of their interview questions. They just do a search for 'programming interview questions' and call it a day.
My most recent interview was with Amazon. I was asked the dumb big-O runtime stuff as well as how I'd count all of the stars in the universe. It pissed me off, but I did like the question I was asked about how I'd design an elevator system and then asked how my solution would scale. That's not too far off from what I'd be doing, albeit in an abstract form.
Re: Why we don't hire programmers based on puzzles and tricks
#14Damn 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).
Re: Why we don't hire programmers based on puzzles and tricks
#15Damn 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).
Re: Why we don't hire programmers based on puzzles and tricks
#16I'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 style interview can provide some kind of insight in to the thought process behind someones work. One company in particular really stood out by having a great white boarding exercise that not only was entertaining, but offered a decent amount of a challenge that it really made them a frontrunner in my final decision making process. A good coding interview can be beneficial not only to the hiring company, but can also give decent insight in to how the company works for the interviewee - and that is something that should be equally important if you are trying to attract talent.
Re: Why we don't hire programmers based on puzzles and tricks
#17is there any well known data/studies on selection methods for programmers?
I can understand the reasons why not to use algo problems as a filter, but I would have thought simpler forms of intelligence testing would still be quite useful.
Re: Why we don't hire programmers based on puzzles and tricks
#18I 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?
The companies who get tired of whining that there is no tech talent to hire.
Re: Why we don't hire programmers based on puzzles and tricks
#19Employer told me "We do hardcore stuff!"
come on really hardcore?! I would really love to post their apps here but I'm not that kind of person.
Re: Why we don't hire programmers based on puzzles and tricks
#20I 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…
Hiring smart people and training them is definitely more of an Ops route than it is a development route. That's how I got my job as a Linux admin, I worked in tech support and learned a bunch then got promoted. I was already ahead of the curve anyway, but I was definitely not qualified to be an admin before my stint in tech support.