Live data from Hacker News

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

37signals.com

51–60 of 460 posts

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

#51

Because no one will hire a writer based on his knowledge of long words.) Excellence in the grammar is also irrelevant.

Reminds me of this supposed exchange between William Faulkner and Ernest Hemingway.

“He has never been known to use a word that might send a reader to the dictionary.” –William Faulkner (about Ernest Hemingway)

"Poor Faulkner. Does he really think big emotions come from big words?" —Ernest Hemingway (about William Faulkner)

>>Excellence in the grammar is also irrelevant.

It took me a long time to grasp the fact that there are very many intelligent and skilled people who have dismal grammar and spelling skills. It still troubles my mind when I encounter examples of it.

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

#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 see them work under pressure, you experience live problem solving and you can understand how they move through their work better. All of these factors are just as important as competency when hiring.

A great programmer doesn't "fizzle" in front of a difficult interview question. He/she may or may not get the correct answer, but as long as they have the requisite problem solving skills and communicate with their interviewer well they will come out fine. I'd say that showing how you fail can be quite beneficial when trying to get a job, especially if you happen to fail gracefully :)

It seems like 37signals is just echoing platitudes to gain karma/publicity at the expense of cheapening the discussion.

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

#53

Because no one will hire a writer based on his knowledge of long words.) Excellence in the grammar is also irrelevant.

And a doctor doesn't necessarily have to be fit and healthy.

That's different.))

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

#54
I won't present a résumé, a github link, a linked in profile, or do nonsense tests. I always send a full web-application I built for code review, do a technical demonstration and provide sample work on their codebase. Any other route is a waste of time.

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

#55
post #13

I remember when I was prepping for my Microsoft interview. There was so much lore online as to the types of questions they'd ask and how to prepare. I even found 'How Would You Move Mount Fuji?' in the library and started reading through it. It was an absolute waste of time as I, fortunately, learned weeks before the interview. As an example, one of the questions I was asked was 'how would you write the C function st…

> are still concerned about big-O notation

Time complexity is important, and hiring someone who doesn't think so is dangerous. That said, it's important to ask about an algorithm you've already discussed. Asking "what's the big-O of " also tests for whether you remember the specifics of that algorithm, which isn't terribly useful.

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

#56

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…

All good, but the success of this method also depends on how well the interviewer interprets/evaluates the interview. Unfortunately, the danger here is that inexperienced/immature interviewers can easily discard good candidates this way. This is similar to the skill required to grade a written test for partially correct answers vs. right/wrong ones. Hence the criticism on wide-spread usage.

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

#57
post #13

I remember when I was prepping for my Microsoft interview. There was so much lore online as to the types of questions they'd ask and how to prepare. I even found 'How Would You Move Mount Fuji?' in the library and started reading through it. It was an absolute waste of time as I, fortunately, learned weeks before the interview. As an example, one of the questions I was asked was 'how would you write the C function st…

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.

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

#58
post #11

Shameless plug: I've been working on this : http://initialround.com to allow applicants to complete an interview at home and in a browser, to eliminate the pressure of the "quizzing cage". I'd be interested to hear people's take on this approach.

My current position did something similar with an existing FiddleJS they had. When it was time for the initial screening, we spoke on the phone while I forked the Fiddle and "whiteboarded" in real-time. I thought it was great and I urge you to pursue your project further.

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

#60

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…

People can be nervous on job interview and therefore "shut down" and fail simple tests. This does not reveal a persons real problem solving skills.

I don't consider myself especially nervous in job interviews and when taking tests and exams. But I still had a much harder time solving simple programming tasks than I would "back at my desk" with no-one watching. YMMW.

It would suck to want a job so bad you completely freeze up on simple interviewing tests :(

Post reply on HN