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

121–130 of 460 posts

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

#121

Post by ig1 »

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.

Logic puzzle as the name implies are puzzles that can be solved using logic; typically deduction which neither of your given problems are.

It's important to make this distinction because skills like deduction are actually critical to developers, i.e. identifying the source of buggy behaviour.

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

#122

Post by some_googler »

When I came to Google for my onsite interview, in the group of people scheduled for that day there was this guy with an alpha-nerd attitude including a Rubik cube that he kept playing effortlessly -- he could completely scramble the thing and then solve it in seconds almost without looking at it. I was never able to solve more than two faces of Rubik in my life :) fortunately no stupid puzzles at all in the interviews (at least not in mine), I got in. The Rubik guy, never saw again. FWIW.

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

#123

Post by skrebbel »

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?

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

#124

Post by bearmf »

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

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

#125

Post by krutulis »

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.

If the motive is laziness or the objective is to trick or intimidate a candidate, then I agree that the method deserves scorn. But I disagree with your position the technique is never reasonable. I like to hire people who know more than I do, and in this circumstance puzzles occasionally help learn about a person.

As a candidate I'm not particularly good at solving puzzles in this kind of situation, but I'm not bothered when people present them because the discussion and interaction about the puzzle matters more to me than getting the answer.

As an interviewer it is important to ask questions that a candidate cannot answer to see how they react. Since I'm a slow thinker myself, I must sometimes resort to "unfair" questions. I don't expect an answer, I expect a reaction.

After establishing a friendly rapport, finding common technical background, presenting an "unfair" puzzle, and discussing the puzzle a bit, then a discussion like this is golden:

Candidate: "Do you believe my ability to solve this puzzle indicates how well I could do this job?" Me: "No. Though I often enjoy puzzles, I'm not particularly quick with them myself." Candidate: "Then why ask a question like this?" Me: "Because I want to see how you react when you don't know an answer right away. In your case, I had to resort to tricks."

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

#126

Post by kamaal »

to3m wrote: post #108
kamaal wrote: post #78

Earlier quoted context omitted.

Actually using something like a math notation to solve a programming problem is asking for too much. What are those general problems which can't be solved by standard libraries, frameworks and IDE's these days? And even if you are facing problems that mandate you to roll out your stuff how much of that requires these math tricks. Given all this, if you truly want to hire a math geek to get some magic done. I guess yo…

Big-O notation is hardly "math geek" stuff. I'd not call this comment ridiculous, because I might have misunderstood it, but catch me in my cups and ask me for my true opinion and maybe I'd say that. Big-O notation is pretty basic, and very useful. Combined with a memorized table of powers of two (you don't need all of them - I know up to 2^20, and this has proven sufficient - just enough so you can guess log N for a…

I'm not talking about Big-O. I'm talking about the general theme of these interviews.

Besides that I still don't understand this. I don't even know the last time anybody around me ever had a problem or a show stopper problem anything to do with Big-O or an algorithm.

Its always how the programmer can take pressure, how he can contribute to making the project happen, getting things done, how he can collaborate with fellow team mates, how he responds under times of crisis, how good he is with tools, what are his everyday practices, does he write unit tests, does he do code reviews, does he document the API's he writes, how does he package his code, how update he is with software world(tools, framework and techniques) etc etc.

Lets be frank, Its always these things that are relevant today in practical everyday software projects today. Unfortunately people hardly ask questions on these and then complain of bad software practices among people these days.

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

#127

Post by msluyter »

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. Depending on how they go about it, you can also get into issues of runtime complexity, memory/speed tradeoffs, etc... It's a deep question that offers a lot of room for exploration.

On the other hand, as mentioned, people usually do fairly poorly at it, and so my fear is that it's simply too difficult. I mean, I'd even be satisfied with solutions storing key/value pairs in a list -- inefficient, but workable -- but it's fairly rare that folks even get that close.

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

#128

Post by danielweber »

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…

As much as people say "well, everyone knows about Fizzbuzz by now," lots of people still can't do it.

"Swapping two variables without a temp" is a bad question, because it depends on knowing the trick.

"Find the 2nd-highest element of this list" is a basic question, and I can change it up it a zillion ways such that anyone trying to just learn all possible permutations will end up doing way more work than someone who can just figure it out on the fly.

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

#129

Post by codeonfire »

127001brewer wrote: post #73
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…

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 single most enraging thing in all of software development. That's why I 'keep it real' in interviews.

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

#130

Post by AdamTReineke »

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 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 other seven and you need to use a balance scale to find the lightest of the balls in the minimum number of weighs. I'd heard of the puzzle but never worked it out. I initially jumped to the 3 weigh solution, but the interviewer challenged me to keep looking, so I kept thinking and I found the 2 weigh solution. He then asked me to write code that could solve the 8 ball problem. Pretty straightforward. Once I finished that, he had me adopt it to be able to handle [edit: any number of] balls. This tested my ability to abstract my code. Finally, he asked how I would go about testing the program and we talked through that.

I cannot wait to steal that progression when I end up doing technical interviews someday.

Post reply on HN