Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

37signals.com

Post reply on HN
Print view View original

161–170 of 460 posts

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

#161

Post by viscanti »

Graham24 wrote: post #81
cletus wrote: post #44

Sigh. This is the issue that will just never die. Let's just summarize the points: - Not everyone can produce real-world code. Most of what we do for a living belongs to our employer. Side projects, particularly in the US, can be an issue for IP reasons (California is somewhat of an exception here); - Side projects, even open source projects, can be of questionable "real world" value; - I've personally encountered ma…

I've worked to two programmers who could not code. I mean literally not code. You cannot imagine how frustrating this became before the managers finally got rid of them.

While terrifying, I think the real danger is hiring someone who can code, but can't do it in a maintainable way. I'd much rather have someone not write a single line of code, rather than have them write 6 months of unmaintainable spaghetti code. Zero contribution is bad, but it's much worse if they have a negative multiplier on the future of the team (if what should take a day to do takes a week to do because of unmaintainable code).

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

#162

Post by antoko »

bearmf wrote: post #124
potatolicious wrote: post #12

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 really don't understand why manhole covers or stars in the universe puzzles are considered "logic puzzles". Logic questions are not of the form "why?" and "how?". Their structure boils down to "is this statement true or not?"

It is a poor choice of word. I'd suggest the reason for calling them "logic" is that the process by which you explain what you're thinking and why to the interview gives them an insight into your ability to use logic. The puzzles themselves are categorically NOT logic puzzles.

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

#163

Post by freework »

I've been interviewing pretty much non-stop since last April. I feel like I've become somewhat of an expert when it comes to interviewing processes.

First off, as I've become a better programmer, I feel this fact is best shown in my opinions. When I first started out, if you had asked me my opinion of PHP vs Python, I would not have been able to say anything coherent. Now that I've worked with both technologies, my opinion is much more coherent.

Instead of asking puzzle questions, ask candidates their opinion. "What is your opinion of Mongodb?" I've spent enough time in the trenches with Mongo to have quite an opinion of that technology. Same with Postgres, Django, Javascript, Coffeescript, etc.

I think hands down, the worse type of interview questions are the ones where you're told to solve a problem, but you can only solve the problem in a certain way.

Its become a interview idiom for me. One recently was to reverse the words in a string. In comes "This is a string", out comes "string a is This". No problem. In python this can be done with one line:

the_string.split()[::-1]

It takes me 5 seconds to write that out. The interviewer telle me "good job", then he asks me to do it again, but this time to do it without using any standard library functions such as split or reverse.

At this point, I can almost with 100% certainty that this company will be a terrible place to work. It wouldn't piss me off it it wasn't for the fact that like 90% of all interviews I do end up like this.

I've through about this a lot, and what I've come up with for an explanation as to why I can;t do these types of questions is because my algorithm writing process is very subconscious. When I'm writing code and I come to a problem that requires a lot of thinking, I usually stop, do something else and let the problem float around for a bit in my subconscious. I got my best ideas when I'm in the shower, on my bike riding around time, even while reading a news article. When people are watching me (especially strange people I don't even know) I don't do my best thinking. At this point I'd do anything to be able to think in front of people. Because its keeping me from being able to get jobs.

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

#165

Post by papsosouid »

grey-area wrote: post #91
cletus wrote: post #44

Sigh. This is the issue that will just never die. Let's just summarize the points: - Not everyone can produce real-world code. Most of what we do for a living belongs to our employer. Side projects, particularly in the US, can be an issue for IP reasons (California is somewhat of an exception here); - Side projects, even open source projects, can be of questionable "real world" value; - I've personally encountered ma…

I think the point of the article is this: Trivial puzzlers like:write a fizzbuzz program, swap two variable contents without using a temp variable, how do you count the stars in the universe Just encourage people to game the system. It's impossible to get real insight from them, because you can't differentiate between those who worked it out, and those who have read about it. If you're in an interview by now and some…

>Trivial puzzlers like:write a fizzbuzz program

That isn't a "puzzler", in any way, shape or form. It is quite literally "write the most basic, simple, trivial program possible". There is no trick to it, no gotcha, no special information that makes it suddenly go from hard to easy. It is always easy, and is a practical test of actual programming knowledge.

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

#167

Post by pseut »

pc86 wrote: post #114
donw wrote: post #80

Earlier quoted context omitted.

I'm not sure if I'm that guy or not... but anyhow, here's the hiring process that's given me some good results. Note that this requires that your team does pairing. Interviewing answers three questions: Can they do the job? Do they get along with the team? And, can they adapt when the game changes? Before your phone interview, let them know that you want to do a short screen-sharing and pair-programming exercise via…

I don't know if this is a Silicon Valley thing or what, but the idea that someone would basically do a day's unpaid work on projects they know nothing about with three different people is just about the most foreign thing I can think of. That being said, I've never done any pairing so maybe it would work better in that type of environment.

A job interview is going to take at least a day of your time anyway. What does it matter if that time is spent programming, talking over coffee, sketching on a whiteboard, or whatever?

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

#168

Post by benjaminwootton »

danielweber wrote: post #131
hackinthebochs wrote: post #118

Earlier quoted context omitted.

All this teeth-gnashing regarding programming and logic puzzles are simply to cover up the simple fact that most people (even around here) are insecure about their programming skill, and more-so their intelligence. The fact is that these types of questions are indeed backed up by the very research you cite, namely that a work-sample test and general mental ability are the only reliable predictors of job performance.…

most people (even around here) are insecure about their programming skill, This has a lot of truth. I think also most people say "the best interview technique is the one I do best at."

I don't think it's anything to with insecurity.

I would consider myself a very good programmer compared to the hundreds I've worked directly with - think good quality, clean, well tested code delivered on time that delivers outsized value in production.

I am however useless at these mental gymnastic and logic puzzle things.

Having a high degree of programming skill is weakly correlated with these kind of interview questions, if that.

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

#169

Post by feliperibeiro »

This is a complicated issue, but in my opinion the google/facebook style of interview is the one that gives you less false positives, even though it gives tons of false negatives. In other words, very few people who can do it are bad coders (false positives), but many good coders can't do it (false negatives).

So, as companies like Google and Facebook have so many applications, they're much more concerned about false positives than false negatives.

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

#170

Post by reinhardt »

Graham24 wrote: post #81
cletus wrote: post #44

Sigh. This is the issue that will just never die. Let's just summarize the points: - Not everyone can produce real-world code. Most of what we do for a living belongs to our employer. Side projects, particularly in the US, can be an issue for IP reasons (California is somewhat of an exception here); - Side projects, even open source projects, can be of questionable "real world" value; - I've personally encountered ma…

I've worked to two programmers who could not code. I mean literally not code. You cannot imagine how frustrating this became before the managers finally got rid of them.

How can this even happen? I mean, isn't it obvious in the first week or two, month tops? If not how can they hide their cluelessness for months until they are laid off?
Post reply on HN