Live data from Hacker News

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

37signals.com

281–290 of 460 posts

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

#281

Earlier quoted context omitted.

Also, it depends on which language you're using... $ irb irb(main):001:0> a = 1 => 1 irb(main):002:0> b = 2 => 2 irb(main):003:0> b, a = a, b => [1, 2] irb(main):004:0> puts "#{a} #{b}" 2 1 => nil (obviously this has the same flaw you mention, the interpreter is doing stuff for you. It follows the letter of the 'no intermediate variables' only.)

You can also follow the letter in C, Java, etc.: a ^= b b ^= a a ^= b

[deleted]

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

#282
post #167
post #114

Earlier quoted context omitted.

I don't know if this is a Silicon Valley thing or what, but the idea that someone would basically do a day's unpaid work on projects they know nothing about with three different people is just about the most foreign thing I can think of. That being said, I've never done any pairing so maybe it would work better in that type of environment.

A job interview is going to take at least a day of your time anyway. What does it matter if that time is spent programming, talking over coffee, sketching on a whiteboard, or whatever?

Many interviews I've had are 2 hour affairs, including jobs I've received where interviews were 45 minutes.

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

#283
The last interview I gave for a senior dev I tried making up some custom discussion questions to give after the basic tell me about yourself stuff. The questions boiled down to:

1. Junior developer code review where a save method included a call to a list method "because it's more efficient" than making a separate ajax call. Explain to the junior developer why that's not necessarily a good idea.

2. UI wants a tree view of categories where each category has a name and a parent category. The number of categories can be arbitrarily large. Discuss problems you might run into using a database agnositic approach (e.g. Hibernate) and what solutions you'd propose.

3. Prototyping a new app, two potential clients in the same domain have widely different ideas of how those domains should be represented (i.e. obviously similar domain class names, very different properties). Discuss ways of modeling domain classes such that each client sees the data in their preferred format.

All in all, I think the interview went pretty well because the discussion questions led to discussing all sorts of related topics that gave me a good feel for the types of problems the candidate had run into and if he had success in dealing with them.

It was great giving an interview without arcane things like explain the yield keyword in C# and how it might be used.

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

#285

Earlier quoted context omitted.

One thing you're testing for is how well their brain works with an excess of adrenaline floating around in their body. All of the best interviewers I've known take great pains to make the interviewer feel comfortable and chatty - after all, they aren't going to be filled with interview anxiety when they're actually working there. A minority of your applicants are going to perform badly in that situation because the a…

"A minority of your applicants are going to perform badly in that situation because the adrenal glands will effectively reduce the output prefrontal cortex below an acceptable level" I have an off topic question. I don't see what the problem being discussed has to do with how glands reduce activity in certain parts of the brain. Sounds to me like a fancy way of saying 'people don't perform well under stress'. You cou…

Add major jet lag to that and you'd have one of my previous interviews.

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

#286
post #179

Earlier quoted context omitted.

Anyone who's studied information theory would destroy that puzzle though. In the same way that someone with a physics degree would perform way above average on a "count the stars" question. Or someone whose dissertation was on computational biology would excel at a string-matching algorithm question. It is an example of the interviewer (or company/process) mistaking a specific problem as representative of all problem…

You can interpret the response more broadly, though. In this case, it was probably pretty apparent that the person hadn't worked through the problem before, so it is indicative of problem-solving and attitude. If he'd recited the answer from memory that usually comes across and then you have to pick something from a different area. If, as an interviewer, you literally can't find a problem that the interviewee hasn't…

It's easy to game your answer as an interviewee though. HN actually had a post a while back about someone who "interviewed" for a living while on unemployment; by the time he was done, he had mastered pretending to think deeply about the answer to any interviewing question.

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

#287
post #167

Earlier quoted context omitted.

A job interview is going to take at least a day of your time anyway. What does it matter if that time is spent programming, talking over coffee, sketching on a whiteboard, or whatever?

Many interviews I've had are 2 hour affairs, including jobs I've received where interviews were 45 minutes.

I guess it depends on the position, but the point still stands. Given that you spend x amount of time interviewing, what does it matter how it's spent? (with the obvious caveats that if they spend, say, 3 hours screaming at you as a stress test, you probably don't want to work there, etc etc).

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

#288
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 basic question is whether it is a good idea to ask questions which humiliate a sizeable portion of interviewee simply because this maximizes your personal utility?

I don't even know for certain if such an approach does maximize your time versus finding-good-programmers ratio but let's assume it does.

The thing is you are willing to maximize this ratio by doing things that treat some portion people who have ability as if they don't (even it's also treating people without ability fairly)?

I'd claim that doing that sets you for up an adversarial relationship with everyone in the workplace - the people hire you can feel they're under-the-gun. I strongly suspect that the "almost no one can code" crowd are the people who live in these adversarial environments, which produce bad code through all the emotional and organizational games this implies.

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

#289

Earlier quoted context omitted.

Usually the candidate pays all of it.

Really? Of the three job interviews I've traveled for in the last year, all were paid by the company 100%.

Seconding this; even for internships I've not once paid for travel costs. Everyone from small, YC startups up to MS/Google paid for cab fare, flights, and hotels.

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

#290
post #278

Earlier quoted context omitted.

"A minority of your applicants are going to perform badly in that situation because the adrenal glands will effectively reduce the output prefrontal cortex below an acceptable level" I have an off topic question. I don't see what the problem being discussed has to do with how glands reduce activity in certain parts of the brain. Sounds to me like a fancy way of saying 'people don't perform well under stress'. You cou…

My thought is that it's a real phenomenon that occurs in a certain subset of people during a job interview, therefore, its obviously relevant

I feel the problem is that, few of us actually being neuro-scientists; While saying something like "people don't perform well under stress" is something that is close enough to common knowledge, instead saying "adrenal glands will effectively reduce the output prefrontal cortex" leaves the reader with a whole bunch of unanswered questions:

* Does a stressful interview necessarily actually increase adrenaline? * Is there actually a link between incresed adrenaline and reduced prefrontal cortex output? * What role does the prefrontal cortex play in answering interview questions?

And while these may all have good answers, it just throws up a whole bunch of mental '[citation needed]' annotations all over the whole argument, that can just be skipped entirely if we aren't talking about neuro-science. And if we insist on talking about the bio-chemestry, we should probably go into the details.

Post reply on HN