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

131–140 of 460 posts

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

#131

Post by danielweber »

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

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

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

#132

Post by ajross »

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

I think this is basically true. But a point worth making is that a "puzzle" problem is a much heavier thing than lightweight tests like FizzBuzz. If you hand someone a puzzle you're pretty much guaranteed (absent the rare, truly gifted candidate) to watch them struggle at a whiteboard for half an hour. FizzBuzz (or "reverse words in a sentence", or whatever) will tell you the same thing in a minute or two.

Basically, the Venn diagram regions for "can code fluently" and "can solve puzzles" have a ton of overlap. So test the first one, not the second.

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

#133

Post by potatolicious »

AdamTReineke wrote: post #120
ghurlman wrote: post #100

Earlier quoted context omitted.

I was asked that question during an interview for a technical role at Microsoft. Granted, it was 13 years ago at this point, but they did really ask stuff like that, and probably still do.

I haven't heard of those silly questions in the intern interview circuit. (2 at-school, 4 on campus)

My impression is that they are no longer in vogue - for a few years when I was in college (2004-ish) they were all over the place. Our industry is extremely faddish, even when it comes to interviewing...

You can still see them in some places I believe. I've heard anecdotally that Microsoft is still a fan of them.

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

#134

Post by fiblye »

I was invited to a company for a game development position. One part of the interview consisted of a fairly challenging mathematical/algorithmic problem. It wasn't impossible, but it's certainly not something I can do in ten minutes at a white board with some people taking notes about my every movement.

The other part was being shown intentionally messy and broken code. Not code that'd fail to compile (although it sure looked like it would), but something thrown together in a completely insane manner that I couldn't possibly make sense of in 15 minutes. Much of it boiled down to, "What would happen if you call this function and use this variable before you actually define them and then do x, y and z?", and the way this language did it was quite different from other languages. I mean, yes, I did learn a lot about the language from that interview, but I'd really hope that's not the kind of code they'd be throwing at me or expecting me to write at their company.

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

#135

Post by danielweber »

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…

The point of any question isn't whether they get it right or wrong. The point is how they work through it.

I've been perfectly happy with people who didn't get the "right" answer to some question.

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

#136

Post by 127001brewer »

codeonfire wrote: post #129
127001brewer wrote: post #73

Earlier quoted context omitted.

The problem with hiring (anyone) is that it's really like "speed dating" - even having multiple interview sessions really doesn't give a greater insight into the candidate. The idea of " umbrella of cultural fit " is what mostly happens with hires. 37Signal's approach of trying them out for size is a good approach, but not practical for everyone else. ... someone being paid to be a programmer who can't code. But I as…

What is shocking is the fact that in companies where devs have no say in hiring, managers hire those people and then ignore the fact that they do nothing (or try to promote them out of development) to try and cover up their mistake. It is incredibly demoralizing working ten hour days trying to deliver working code while someone else is producing nothing, getting ahead, and going home at 4 pm. This shit is by far the…

How do you "keep it real" in interviews?

Concerning the viability of firing under-performing individuals, how likely is that? Are there any implications with indirect costs such as unemployment benefits? (I ask because I do not know - any insight on this would be greatly appreciated.)

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

#137

Post by ben1040 »

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.

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

Yep. That basically amounts to an application fee.

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

#138

Post by danielweber »

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…

That's why the interviewer should ask if they are familiar with those games first.

Even Connect Four or tic-tac-toe can be a useful exercise to go over with someone.

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

#140

Post by elliottcarlson »

LockeWatts wrote: post #98
elliottcarlson wrote: post #28

Earlier quoted context omitted.

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.

The problem with this though is the meta-strategy of interviewing. Unless your interviewer tells you up front whether or not it's okay for you to ask an unlimited number of questions, you're basically guessing at it. I know several companies that interview with a "hint" system, where every time you ask a question, they just give you a hint to the problem, generally regardless of the question asked, and then mark it d…

Interesting - while I never said it was OK to ask unlimited questions I have generally gauged how someone is doing and then let them know it's OK to ask questions or need hints. Some people have accepted the offer, and some people have simply given up - which just astonishes me.
Post reply on HN