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

71–80 of 460 posts

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

#71

Post by rdtsc »

saosebastiao wrote: post #46
rdtsc wrote: post #35

Earlier quoted context omitted.

> and a lot of the more academic questions It is on purpose. A recruiter confessed. He said they are specifically targeting recent grads. So plenty of questions are of that type. I guess they want to indoctrinate and take advantage of them while they are "fresh". > did like the question I was asked about how I'd design an elevator system and then asked how my solution would scale. That's not too far off from what I'd…

Actually, yes...they do. I work in a building with an elevator control system designed by an internal engineer. More importantly, the elevator control system uses mathematical expertise that is normally used solving variants of the multi-commodity flow problem, used extensively in the Supply Chain.

> Actually, yes...they do. I work in a building with an elevator control system designed by an internal engineer.

Well then that makes a good interview question then!

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

#72

Post by NateDad »

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…

I care about three things in a candidate:

Code Quality

Productivity

Communication

... pretty much in that order. Brain teasers test none of those things (maybe a some communication)

I've never met a coder that couldn't eventually figure out a way to hack the code to do what the PMs want. But I have met a lot of coders that take way too long and/or produce horrific code that is a buggy maintenance nightmare. Those people often do ok on brain teasers (or at least do well enough that the interviewer doesn't feel like he can give negative feedback).

A more important point is that brain teasers are a waste of time compared to a million other things you could be doing with the candidate to determine their aptitude, like actually writing code to solve a problem.

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

#73

Post by 127001brewer »

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 assure you this is the case. It's shocking but true.

This is a shockingly true statement - it's almost beyond comprehensive when witnessed first hand.

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

#74

Post by GhotiFish »

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 people take the perspective that if you go

    if(i % 15)     print "fizzbuzz";
    else if(i % 5) print "fizz"; //or was it buzz?
    else if(i % 3) print "buzz"; //or was it fizz?
    else           print i;
then you've found an optimal solution and you can wash your hands of it, until you think to yourself: "but an if tree would use less comparisons! Should I be readable? Or take the efficient route? But if I'm thinking about efficiency. wouldn't a lookup be faster and simpler?"

I suspect when presenting a problem like this, the interviewer filters out two kinds of people: the people who "can't code", and the people who are obsessive.

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

#75

Post by bluekite2000 »

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…

I have heard of interviewers asking candidates to solve various levels on mobile brainteaser apps. Something like this game https://itunes.apple.com/us/app/smart-kick-pro/id590049769?m... could work well as it involves problem solving skills and is a great fun little ice breaker.

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

#76

Post by xentronium »

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.

DHH strongly despises HN[1].

[1] https://twitter.com/dhh/status/289669574427820032

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

#77

Post by LockeWatts »

ironchef wrote: post #61
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 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 who has never played the game before.

Reapply the same paragraph to Go and Sudoku. You've created a filter for someone who plays games, not problem solving skills.

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

#78

Post by kamaal »

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.

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 you are looking at a very small pool of people to hire from and it should hardly be a problem to hire one.

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

#79

Post by dmbaggett »

mapleoin wrote: post #27
dmbaggett wrote: post #5

At ITA Software, we found in-person quizzing to be a lot less useful an indicator than looking at puzzle (or other) code someone had written "offline". We also found puzzles to be a useful talent magnet. If you're Google (or perhaps 37Signals) you don't need a talent magnet. If you're a small company nobody's heard of, one can be quite helpful.

I think it's the opposite. If the first thing you confront me with in your interview process is a puzzle and I don't know anything about your IT department, I'm going to assume that all your managers are pointy-haired bosses.

Empirical evidence from over 10 years suggests you're an outlier.

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

#80

Post by donw »

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'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 Skype, in their own personal development environment.

Start with a chat over Skype. Talk to them a bit about their preferences and experiences at other companies. Are they comfortable to talk to? Do they have opinions about the stuff they've worked with? This is important -- A Java developer that doesn't have a vocal preference on checked exceptions or static typing probably isn't very experienced.

Then give 'em the FizzBuzz.

At this point, do you want to hire them?

If so, it's time to invite them into the office.

When they come in, at the very least you should buy them lunch and pay for transportation. They're taking a day, not paid, to come and interview with you -- show some courtesy.

Have them sit down and pair with three of your more senior engineers for a few hours each, both as a pilot and a copilot.

At the end of the day, take your group of three, and see how your interviewee did:

1. Did the candidate demonstrate the expected level of knowledge and contribution?

2. Would they feel comfortable with the candidate as their direct boss?

3. Would they be upset if this candidate went to work for the competition?

If somebody can get through the phone screen and a day of pairing, they're probably competent, and likewise want to continue working with the people they paired with.

Post reply on HN