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

171–180 of 460 posts

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

#171

Post by autarch »

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…

At my current job, we used FizzBuzz when we were interviewing potential senior devs. One of the candidates who looked good enough on paper to talk to could not complete FizzBuzz, and in fact spent 20 minutes struggling with it before I decided to end the screening.

It's certainly possible that some of the people who completed FizzBuzz are not good programmers, but it seems pretty clear that the one person who failed it cannot possibly be a good programmer.

Having people go through FizzBuzz (which generally took 5-10 minutes per person) saved us the trouble of a longer interview with more people for at least one clearly unacceptable candidate.

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

#172

Post by pseut »

skrebbel wrote: post #123
tokenadult wrote: post #89

As Cletus wrote in his detailed comment, "this is the issue that will just never die." We discuss company hiring procedures here on Hacker News over and over and over, because most of us have applied for a job at least once in our life, and those of us who are building up a start-up have to think about whom we would hire. The point in the submitted blog post by 37 Signals, "The only reliable gauge I’ve found for futu…

> EDIT TO RESPOND TO FIRST REPLY ABOUT PUZZLE QUESTIONS: I'm nitpicking, but isn't that what the reply button is for?

Yes, but putting it in the parent preempts a lot of similar sibling replies from people who don't read all of the comments.

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

#173

Post by papsosouid »

xentronium wrote: post #76
pdeuchler wrote: post #43

Earlier quoted context omitted.

It seems more like they make a risk-free blog post parroting general HN sentiment every couple of weeks for the karma/publicity. Not that fresh or honest if you ask me, and hardly pragmatic.

DHH strongly despises HN[1]. [1] https://twitter.com/dhh/status/289669574427820032

He says on twitter. To gain more publicity from HN. Just because he hates that there's some people here who call him on his bullshit, or even if he hated HN for real, that wouldn't mean he doesn't use it for marketing.

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

#174

Post by pekk »

hackinthebochs wrote: post #118
tokenadult wrote: post #89

As Cletus wrote in his detailed comment, "this is the issue that will just never die." We discuss company hiring procedures here on Hacker News over and over and over, because most of us have applied for a job at least once in our life, and those of us who are building up a start-up have to think about whom we would hire. The point in the submitted blog post by 37 Signals, "The only reliable gauge I’ve found for futu…

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.…

It isn't that people are insecure about their programming skill and intelligence. It's that they are irritated by tests which don't measure what they're supposed to. If any insecurity is involved, it's about ability to ace unrepresentative tests ranging from trivial nonsense to outright hazing.

You advise readers to "just get better at [the tests]". That's practical. But it goes right back to the problem, that many of the tests mostly index whether you prepared for that test.

Everyone talks about how many applicants are terrible at programming, or how many employees are mediocre. But at least offline, we rarely mention the complementary problem, that many companies are terrible at interviewing and hiring.

We talk as if being on the other side of that desk, in a position of power, means you are automatically good at interviewing. It isn't so. When a company treats candidates abusively - or takes bad hires who are extra slick, cheap, submissive, or similar to themselves - that isn't because of bad applicants. It's a failure of that company.

We can recognize that a defensive and condescending attitude is toxic in a programmer. But the same attitude in an interviewer is completely accepted. They're on top, applicants are on bottom.

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

#175

Post by papsosouid »

buro9 wrote: post #39

The question I always like to ask and reserve a good chunk of time for is along the lines of "What non-technical hobby or interest do you have?" and then "If you had all the technical resources you could dream of, how would you now bring something new to your hobby?" and once we've gone through that the real question is: "Given that when you're duck hunting the key is to shoot ahead of where the duck is, and that a l…

>What non-technical hobby or interest do you have?

That seems like a poor choice. Are you trying to eliminate people who don't have non-technical hobbies for some reason?

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

#176

Post by jmelloy »

LockeWatts wrote: post #77
ironchef wrote: post #61

Earlier quoted context omitted.

"Asking a candidate a difficult brainteaser that may be even close to impossible can be extremely revealing." I prefer problems that are ridiculously simple on the outside; however, allow for lots of optimization. Choose the next best move in chess or go for example (or design a simple sudoku solver). A completely simplistic solver just chooses a valid move. It becomes more interesting as one looks at how are you mod…

"Choose the next best move in chess or go for example (or design a simple sudoku solver). " You make the assumption that your candidate knows anything about those games. If you placed me in front of a chess board, said "these are what the pieces do" and then asked me to tell you the next best move, that move will either be A) blindingly obvious to anyone who has played chess for years, or B) too difficult to someone…

Sudoku's kind of a fun one, because brute force works just fine. More elegant solutions use the same strategies humans use, but recursive brute force gets the job done just fine.

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

#177

Post by smackfu »

msluyter wrote: post #127
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.

Re: hash table. I've been asking candidates to basically implement HashMap (for java positions) (without simply using Hashtable). It's an ongoing experiment. Although I've been told that this is a common question, I've actually never seen anyone do very well at it, and I have mixed feelings about it. On the one hand, it gets at some important java concepts: hashCode() and equals() and the relationship between them. D…

I would be surprised if many people knew hashing algorithms at all.

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

#178

Post by papsosouid »

maigret wrote: post #164

Kent Beck tweeted a very fitting comment: 'Programming contest problems shouldn't be algorithms, they should be like "set up continuous deployment of a multi-region Django app on AWS"' https://twitter.com/KentBeck/status/299528659746840576

Why should programming contest problems be tests of practical sysadmin skills? That makes no sense at all.

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

#179

Post by pseut »

Jabbles wrote: post #149
AdamTReineke wrote: post #130

Earlier quoted context omitted.

My all-time favorite interview was one when I was interviewing for an SDET intern position at Microsoft. That interview (one in a day of four interviews) featured a great progression: logic puzzle, code the fixed input solution, code the n input solution, test your solution. The puzzle was (apologies to the interviewer, but it IS a common puzzle) the eight ball and balance problem, where one ball is heavier than the…

Anyone who's studied information theory would destroy that puzzle though. In the same way that someone with a physics degree would perform way above average on a "count the stars" question. Or someone whose dissertation was on computational biology would excel at a string-matching algorithm question. It is an example of the interviewer (or company/process) mistaking a specific problem as representative of all problem…

You can interpret the response more broadly, though. In this case, it was probably pretty apparent that the person hadn't worked through the problem before, so it is indicative of problem-solving and attitude. If he'd recited the answer from memory that usually comes across and then you have to pick something from a different area. If, as an interviewer, you literally can't find a problem that the interviewee hasn't already thought about, (i.e., he or she knows about computational biology, astrophysics, information theory, etc and none of this was obvious from their resume and previous positions) that can also be a good sign.

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

#180

Post by rohamg »

Jabbles wrote: post #149
AdamTReineke wrote: post #130

Earlier quoted context omitted.

My all-time favorite interview was one when I was interviewing for an SDET intern position at Microsoft. That interview (one in a day of four interviews) featured a great progression: logic puzzle, code the fixed input solution, code the n input solution, test your solution. The puzzle was (apologies to the interviewer, but it IS a common puzzle) the eight ball and balance problem, where one ball is heavier than the…

Anyone who's studied information theory would destroy that puzzle though. In the same way that someone with a physics degree would perform way above average on a "count the stars" question. Or someone whose dissertation was on computational biology would excel at a string-matching algorithm question. It is an example of the interviewer (or company/process) mistaking a specific problem as representative of all problem…

Everyone from McKinsey to Accenture makes the same mistake.
Post reply on HN