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

191–200 of 460 posts

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

#191

Post by pnathan »

kamaal wrote: post #126
to3m wrote: post #108

Earlier quoted context omitted.

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

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

Either your team does horrifically easy work, or no one has told you about their abstract work. I am sorry, but even writing CRUD apps I have to think about the informatics of the system to make it work reasonably well.

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

#192

Post by pbiggar »

ricardoz17 wrote: post #160
danielweber wrote: post #128

Earlier quoted context omitted.

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…

I think the swapping two variables has a bit more going for it if they do not know the trick. Explain the concept of invertible functions. Hopefully they would be able to come up with plus and minus - even if you have to walk them through the a=f(a,b) b=g(a,b) a=g(a,b) From there you can say that works fine with pen and paper but why might it go wrong in a program? So how do you avoid integer overflow? If the signs a…

You're missing the point, and this is how people end up at these "puzzlers". The point of fizzbuzz or the simple questions is to weed out people who can't code at all. If you transform it like you do above, then you're testing something else: how well people know low-level tricks like swapping variables using xor.

Those tricks might be valuable in your workplace, and may make excellent interview questions for you, but they are a very very different type of question than fizzbuzz, at least in purpose, even though they may look superficially similar. In a fizzbuzz type question, you are not looking for brilliance, you are looking to just weed out the people who can't.

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

#193

Post by jchung »

tiziano88 wrote: post #15
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 think that question about why manhole covers are round is more of a urban legend than anything else. Or it might be a question asked to someone applying for a non-technical role, to see how they reason about the issue (though it is most definitely not the best question to achieve so).

Whenever I drill manholes, I always drill them square.

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

#194

Post by derefr »

krutulis wrote: post #125
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 bothe…

> As an interviewer it is important to ask questions that a candidate cannot answer to see how they react.

In the context of an interview, that would just make me horribly frustrated--because my default response to not knowing the answer to a question, nor even being able to perceive a method to resolving my ignorance, is to go out and research the problem.

Whether on the Internet, or by asking my coworkers, or finding an expert, or just running actual experiments and seeing a pattern in the large pile of data generated, this is usually "the" way to get a problem solved, and what I spend nearly 80% of each working day doing.

I don't rely on "sudden gusts of inspiration blowing through me" to solve problems, because the time that could take to happen is unbounded, and it can't be made to scale, unlike research, which can be delegated as you please.

But obviously, research is a tool entirely taken away from you in an interview. The only thing you can do to find out more about the problem is to ask the interviewer themselves--at which point you're basically playing a game of 20 questions, where instead of getting all the data you'd realistically expect in response to each query, you get dealt out precise quantities of informational entropy to string you along.

This contrived situation is not one that applies to the average day in the workplace, and being made annoyed by it is no useful measure of how one reacts to real non-obvious problems.

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

#195

Post by run4yourlives »

GhotiFish wrote: post #74

If I can have a word on FizzBuzz? There are a few programmers that have a proclivity towards "clean, perfect" solutions, but FizzBuzz is ugly. Making FizzBuzz work at all is just stupidly simple; but the moment you ask yourself about the little details, you notice that you either have to make an if tree, a bunch of if-elseif's, or some other hinky thing that ruins the "purity" of this simple little program. Alot of p…

The entire point of FizzBuzz is to filter out the people that say they can code but clearly cannot. This is a surprisingly high number of applicants, unfortunately.

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

#197

Post by andrewvc »

randomdata wrote: post #57
andrewvc wrote: post #37

Earlier quoted context omitted.

I generally agree, most logic questions are useless, but Big-O notation I use every day. Programmers who don't understand the performance difference between Array#include? and Set#include? in ruby are dangerous!

I'm curious to know where you use the notation in daily programming. In code comments? Discussions with other developers? Other documentation? I use the spirt of Big-O almost daily, but do the actual calculations rarely, and basically never use the notation. With some experience, you quickly get an intuitive feel for execution time, which is good enough in most cases.

If I'm reading up on a new technology it's useful to understand what they mean when they say 'operations are O(1)'.

Additionally, when writing an API for use by other developers its useful to say, this operation runs in constant time, that one in logarithmic time.

Redis, for example, mentions the computational complexity of all operations in its docs. Additionally, everyone should know that most decent sorting algorithms are O(n log n), and understand the implications of that.

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

#198

Post by stcredzero »

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…

> 37Signal's approach of trying them out for size is a good approach, but not practical for everyone else.

If you figure in the possible downside, it is the only practical way.

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

#199

Post by [deleted] »

potatolicious wrote: post #133
AdamTReineke wrote: post #120

Earlier quoted context omitted.

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.

[deleted]

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

#200

Post by stcredzero »

jchung wrote: post #193
tiziano88 wrote: post #15

Earlier quoted context omitted.

I think that question about why manhole covers are round is more of a urban legend than anything else. Or it might be a question asked to someone applying for a non-technical role, to see how they reason about the issue (though it is most definitely not the best question to achieve so).

Whenever I drill manholes, I always drill them square.

It is possible, but probably too expensive for you to buy.

www.youtube.com/watch?v=ALiqAXiTQBg

Post reply on HN