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

101–110 of 460 posts

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

#101

Post by pwny »

LockeWatts wrote: post #82
pwny wrote: post #68

Earlier quoted context omitted.

On the other hand, if I'm hiring someone for a high pressure job I don't want them to fail when under pressure. I understand your point but I don't really buy it. I train lifeguards as a hobby/side-job (I'm in uni right now) and pressure is the number 1 reason they give us for failing their final pratical test. I can't give a kid a permit to work as a lifeguard if the pressure of an exam makes him screw up because th…

"On the other hand, if I'm hiring someone for a high pressure job I don't want them to fail when under pressure." But those are in no way the same kinds of pressure. The pressure of being able to meet a release date, design incredibly safety sensitive algorithms, etc, are completely different from the social pressure of having someone evaluate work you normally do by yourself, in real time. This kind of interviewing…

I completely agree and that's why that part of the interview shouldn't be the only one. As someone said earlier, it should be a negative filter of incredibly unsuitable candidates.

In a perfect setting the interviewer wouldn't evaluate the candidate's ability to solve the problem, but his/her ability to approach it, explore it, ask questions and take steps in the appropriate direction.

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

#103

Post by kamaal »

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 far as I was concerned I was only going to test him on practical everyday problems.

It was almost like I had committed a sin. He was like, every company has those standard one's so why was I doing like a practical test. These days all candidates do is go through most common puzzles/algorithms/data structure stuff. Its actually quite easy to get access to those. Just spend some time on interview forums and you can practically game any interview, in any company any where around the world today.

My approach is straight simple. Throw a manual/documentation at the person. Give him a problem common enough to test a practical everyday situation. Check if he can pass the the test of reading the documentation and figuring out the solution to the problem. Or give him/her their favorite IDE/text editor + documentation + problem and let them solve it.

If they can do it, or even get the approach right they pass the test.

Else if all they are going to do is vomit some mathematical theory from college text books, which isn't even remotely relevant to our everyday work- I'm hardly interested in hiring such candidates.

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

#104

Post by nonamegiven »

dhimes wrote: post #84
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…

A great programmer doesn't "fizzle" in front of a difficult interview question How do you know this?

A great employee is more than a great programmer.

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

#106

Post by Osiris »

I'm a self-taught programmer. These stories about programming puzzles in interviews always make me nervous to look for a job.

My first job wasn't a programming job, but I did a lot of programming because the need arose and I was the only one capable of doing it.

I always felt too inexperienced to look for a real programming job. A friend pushed me to interview for the position I'm in right now (full time web developer). They didn't make me do any whiteboarding or puzzles. What I did do is give them a code sample and we discussed how what I could have done better and why.

I got the job and I'm doing quite well, despite my lack of a CS background.

Since I don't have a formal CS background, and most of my development experience is web development, I have basically no experience dealing with complex algorithms, but I've found I can solve a hard problem with enough effort (Google, co-workers, etc).

For web developers, wouldn't more appropriate questions relate to "please design a database for a website that needs to track the following", or "What would your process be for designing and implementing a REST API that would...". These would allow the developer to show you their thought process of working through a large problem without there being a necessarily right or wrong answer.

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

#107

Post by benjaminwootton »

pwny wrote: post #68
gizzlon wrote: post #60

Earlier quoted context omitted.

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

On the other hand, if I'm hiring someone for a high pressure job I don't want them to fail when under pressure. I understand your point but I don't really buy it. I train lifeguards as a hobby/side-job (I'm in uni right now) and pressure is the number 1 reason they give us for failing their final pratical test. I can't give a kid a permit to work as a lifeguard if the pressure of an exam makes him screw up because th…

But in how many coding jobs is pressure a real and common occurrence?

Even working in front office banking roles, there's only 1 or 2 times per year where you really have to keep your nerve and perform under genuine pressure on timescales of seconds or minutes.

The kind of pressure where 'we need to get this feature out of the door by the end of the week' is a completely different thing altogether.

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

#108

Post by to3m »

kamaal wrote: post #78
randomdata wrote: post #57

Earlier quoted context omitted.

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

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 given value) you have a good chance at being able to make quick calculations about time and space requirements for things. Which, since we don't have infinitely fast computers with infinite amounts of memory, often comes in handy.

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

#109

Post by hnriot »

Proleps wrote: post #95
pwny wrote: post #68

Earlier quoted context omitted.

On the other hand, if I'm hiring someone for a high pressure job I don't want them to fail when under pressure. I understand your point but I don't really buy it. I train lifeguards as a hobby/side-job (I'm in uni right now) and pressure is the number 1 reason they give us for failing their final pratical test. I can't give a kid a permit to work as a lifeguard if the pressure of an exam makes him screw up because th…

> On the other hand, if I'm hiring someone for a high pressure job I don't want them to fail when under pressure. Programming is not like in those hacker movies, we don't have to solve problems in 60 seconds while getting a blow job[1]. [1] https://www.youtube.com/watch?v=rUY8HysBzsE

Sadly that's true.

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

#110

Post by bingobangobongo »

tokenadult wrote: post #89

As Cletus wrote in his detailed comment, "this is the issue that will just never die." We discuss company hiring procedures here on Hacker News over and over and over, because most of us have applied for a job at least once in our life, and those of us who are building up a start-up have to think about whom we would hire. The point in the submitted blog post by 37 Signals, "The only reliable gauge I’ve found for futu…

Reading the summary you've linked to, isn't the implication for this thread that certain puzzle type questions, if they do a reasonable job of measuring general intelligence, are useful predictors of job performance? (With the big caveat that in the US they are potentially illegal.)

The popular response here of "I'm never going to solve these puzzles in my day to day" seems to wholly miss the point.

Post reply on HN