Why we don't hire programmers based on puzzles and tricks • Hacker News Board

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

#221

Post by biscarch » Fri, Feb 22, 2013, 6:19 PM UTC

jnbiche wrote: post #159

kamaal wrote: post #103

This is something to think about. The interview process is so badly gamed that these days its kind of a ceremony. In a recent interview, I gave a candidate a practical problem. He was allowed to use the sed man page, and then I gave him a file and search/replace problem. Nothing much! The candidate fails! Instead he asks me if there is going to be a algorithm/data structure interview. I told him, I don't know but as…

May I ask where you work? I'd love to interview at a company like yours. I'm in the process of changing careers to programming in my late 30s. I dabbled in coding on and off for most of my life, but two years ago I started taking it seriously, read K&R, etc, and completely fell in love with programming. And so I start thinking about working full-time as a developer, and schedule an interview for a programming positio…

Seconded.

I'll even spend the extra time on it if we can do something similar to "Here is the problem and the docs. Email me back within the hour with some working code and we'll get on a call to talk through your thought process".

It's like trying to run a competitive 100m without shoes at some interviews I've been through lately.

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

#222

Post by soseng » Fri, Feb 22, 2013, 6:20 PM UTC

To change it up a little bit, has anyone here been asked simple debugging questions? I've interviewed at numerous places and I've never been asked the question why a certain piece of code is breaking or how to fix it. The questions could be designed to be self-contained and just complex enough to get a feel for how the candidate thinks. My consulting job usually takes me to places where a project is in trouble or failing. It would seem that quickly understanding broken foreign code would be a huge asset. The closest question I've been asked is: "Here's a Singleton implementation in Java. What can go wrong?"

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

#223

Post by GhotiFish » Fri, Feb 22, 2013, 6:22 PM UTC

papsosouid wrote: post #218

GhotiFish wrote: post #215

Earlier quoted context omitted.

I think FizzBuzz does filter obsessive people. Someone who is obsessive wouldn't like their off the cuff solutions to FizzBuzz. They would think of a solution and stop themselves from writing anything at all. How would you tell the difference between someone who doesn't want to write their first three solutions, to someone who can't think of even one? Microsoft's "implement strcmp without the use of libraries" doesn'…

>I think FizzBuzz does filter obsessive people. FizzBuzz doesn't filter anyone, the people using it do. It is not difficult to explain the purpose of the exercise, and that easily resolves the problem for people looking for "clean" solutions.

Is this your experience? I've seen good programmers, people I know who are good programers, get stammered by FizzBuzz for lack of "clean" solutions.

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

#224

Post by zenbowman » Fri, Feb 22, 2013, 6:22 PM UTC

It's one thing to ask people to right syntactically correct code. It's another thing to ask them to write pseudocode in whatever language they please and understanding their process.

At the end of the day, as Hal Abelson said, computer science is not about computers, or science. It's about being able to formalize process.

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

#225

Post by GhotiFish » Fri, Feb 22, 2013, 6:24 PM UTC

run4yourlives wrote: post #195

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.

I agree, I think FizzBuzz has this property, but I think it also has the property of filtering obsessive people as well.

You might not want obsessive people either, in which case fizzbuzz is clearly a good choice.

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

#226

Post by [deleted] » Fri, Feb 22, 2013, 6:27 PM UTC

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…

[deleted]

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

#227

Post by megaframe » Fri, Feb 22, 2013, 6:30 PM UTC

I wish this were the case more. I graduated with and electrical engineering degree, but over the years I've spent the bulk of my time coding up DB, big data stats, ML, etc. to help me do my job. Trying to explain I'm more than capable while I falter with simple puzzle based question is an impossible gauntlet that has kept me from even considering a career shift. (Granted I'm a much better analog designer than I am a java code.)

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

#228

Post by papsosouid » Fri, Feb 22, 2013, 6:32 PM UTC

GhotiFish wrote: post #223

papsosouid wrote: post #218

Earlier quoted context omitted.

>I think FizzBuzz does filter obsessive people. FizzBuzz doesn't filter anyone, the people using it do. It is not difficult to explain the purpose of the exercise, and that easily resolves the problem for people looking for "clean" solutions.

Is this your experience? I've seen good programmers, people I know who are good programers, get stammered by FizzBuzz for lack of "clean" solutions.

Yes. I think you are seriously underestimating the intellectual capacity of those people. Telling them "it doesn't matter how nice it is, or clean it is, or generic, or reusable, or maintainable, it is just to see if you can do basic introductory level code" solves the problem. Anyone who still stands there like a moron writing nothing is useless as a developer, regardless of the reason they stand there.

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

#229

Post by grey-area » Fri, Feb 22, 2013, 6:34 PM UTC

papsosouid wrote: post #165

grey-area wrote: post #91

Earlier quoted context omitted.

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…

>Trivial puzzlers like:write a fizzbuzz program That isn't a "puzzler", in any way, shape or form. It is quite literally "write the most basic, simple, trivial program possible". There is no trick to it, no gotcha, no special information that makes it suddenly go from hard to easy. It is always easy, and is a practical test of actual programming knowledge.

I didn't mean to imply it was hard. As to a test of programming knowledge, I'm glad I'm not in a position where I'm exposed to people who would fail such a test :)

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

#230

Post by krutulis » Fri, Feb 22, 2013, 6:35 PM UTC

derefr wrote: post #194

krutulis wrote: post #125

Earlier quoted context omitted.

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

Answering "In the context of an interview, [I get] frustrated because my default response to not knowing the answer to a question ... is to go out and research the problem [and I cannot do that in an interview]" is a nice response to not knowing an answer and would get bonus points for honesty and self-awareness.

The best candidates will recognize and comment on the ways in which frustration can be either constructive or destructive.

"This contrived situation is not one that applies to the average day in the workplace," is a serious over-generalization. Enormous amounts of code are written based on contrived beliefs about the way business does or should operate. The world would be much better off if programmers were better at recognizing and constructively commenting on these artificialities.