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

61–70 of 460 posts

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

#61

Post by ironchef »

pdeuchler wrote: post #52

Interviewers ask puzzles and give you tricks because they want to see your problem solving process. Obviously, anyone who hires simply off a litmus test of such questions is not doing their job, but that doesn't preclude the use of such brain teasers/problems at all. Asking a candidate a difficult brainteaser that may be even close to impossible can be extremely revealing. There isn't a canned response, you get to se…

"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 modeling state, how are you deciding what is best, etc. This way most people will get something that works, you can see their thought processes (where are they optimizing first, why are they doing that), and maybe learn something new.

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

#62

Post by nonamegiven »

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.

My current job, they asked me one of those. I pretended to think about it for about 15 seconds, then asked for the answer (it had an answer).

The guy said "You want me to tell you?" I said "yeah."

I've been here a year.

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

#63

Post by blktiger »

thesis wrote: post #4

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

I think using a whiteboard to test someone's design knowledge is probably a good idea. I like to draw diagrams on a whiteboard when I'm designing a solution to something. However, using a whiteboard for a CODING exercise is stupid. When was the last time you wrote any significant amount of code on a whiteboard? Give someone a laptop if you want to see their coding skills. Even better, have them pair-program with one of your developers.

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

#64

Post by misiti3780 »

nonamegiven wrote: post #62
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.

My current job, they asked me one of those. I pretended to think about it for about 15 seconds, then asked for the answer (it had an answer). The guy said "You want me to tell you?" I said "yeah." I've been here a year.

haha

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

#66

Post by larrik »

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…

Well, he said "real code" not "real world code". I would imagine you can just write something simple for them.

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

#67

Post by ctdonath »

[I] got asked how to do something in JavaScript on a white board. The specifics are vague, but it’s crystal clear how stupid it made me feel and how little it had to do with the actual job.

So did I. (Well, it was C then, but same idea.) The prospect of scrawling code on an inapplicable medium while people stared at every move is, of course, irritating.

Instead of going to the whiteboard, I pulled out my notebook computer, fired up a code editor, and told the several guys present to continue the interview _while_ I worked on the challenge. Time was saved by multitasking, I did the work in a sensible normal manner, everyone was comfortable with the situation, and they were happy with the resulting code.

I got the job. And turned it down.

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

#68

Post by pwny »

gizzlon wrote: post #60
pdeuchler wrote: post #52

Interviewers ask puzzles and give you tricks because they want to see your problem solving process. Obviously, anyone who hires simply off a litmus test of such questions is not doing their job, but that doesn't preclude the use of such brain teasers/problems at all. Asking a candidate a difficult brainteaser that may be even close to impossible can be extremely revealing. There isn't a canned response, you get to se…

People can be nervous on job interview and therefore "shut down" and fail simple tests. This does not reveal a persons real problem solving skills. I don't consider myself especially nervous in job interviews and when taking tests and exams. But I still had a much harder time solving simple programming tasks than I would "back at my desk" with no-one watching. YMMW. It would suck to want a job so bad you completely f…

On the other hand, if I'm hiring someone for a high pressure job I don't want them to fail when under pressure.

I understand your point but I don't really buy it. I train lifeguards as a hobby/side-job (I'm in uni right now) and pressure is the number 1 reason they give us for failing their final pratical test. I can't give a kid a permit to work as a lifeguard if the pressure of an exam makes him screw up because the real life pressure of saving somebody's life is even greater.

The exact same applies here for all jobs where you expect the engineer to work in stressful situations.

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

#69

Post by modoc »

pdeuchler wrote: post #43
jebblue wrote: post #30

Earlier quoted context omitted.

They maintain a fresh, honest, pragmatic view of software development and engineering. Those are qualities people can aspire to and identify with.

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.

I seriously doubt that 37Signals authors blog posts for the purpose of getting karma on HN.

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

#70

Post by paf31 »

wavefunction wrote: post #58
paf31 wrote: post #11

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.

My current position did something similar with an existing FiddleJS they had. When it was time for the initial screening, we spoke on the phone while I forked the Fiddle and "whiteboarded" in real-time. I thought it was great and I urge you to pursue your project further.

Thanks! I've done similar things with online text editors, and wanted the ability to compare applicants side-by-side. I was also thinking this might be useful for recruiters who don't necessarily know the code, but just want to pick questions from a preset list to get started.
Post reply on HN