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

#321

Post by dpcan » Fri, Feb 22, 2013, 9:50 PM UTC

spiralpolitik wrote: post #247

Programming is about problem solving. What you want in a programmer is someone who knows how to approach solving a problem in a structured repeatable manner. What getting someone to solve small problems like FizzBuzz in the interview gives you an idea of how then approach the problem. Can they decompose the problem into smaller chunks ? Can they then refine their solution into a better solution ? Do they know when to…

I totally agree, but only in the FizzBuzz case.

It's the perfect, super-simple puzzle that can be solved quickly, but let's you see how a programmer might approach a problem, how they like to code, and their go-to language, etc.

It's not like you are trying to stump the programmer. Any programmer with a lick of skill should be able to knock out the FizzBuzz problem in their language of choice.

It's actually kind-of fun the first time you do it.

Personally, I'd watch the programmer's face. If they smiled after realizing the problem is not as clear-cut as it seems, they probably enjoy programming.

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

#322

Post by bearmf » Fri, Feb 22, 2013, 9:53 PM UTC

grey-area wrote: post #304

bearmf wrote: post #272

Earlier quoted context omitted.

'select the second highest number in this list' is actually O(n) and does not require sorting.

Does that mean I fail the test :) A sort then select for the second highest seemed the simplest solution off the cuff (perhaps not the quickest), and if the code is fast enough, there's no point in optimising. Of course you could write a loop and check each value against a stored memo - your O(n) right?, but why bother when the library sort is fast enough for the purpose? If you're dealing with genuinely huge data se…

It depends entirely on the person asking the question. Some people probably don't care, but there are some fans of the most efficient possible solution.

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

#323

Post by SomeCallMeTim » Fri, Feb 22, 2013, 9:53 PM UTC

derefr wrote: post #237

hackinthebochs wrote: post #219

Earlier quoted context omitted.

> a programming puzzle is the intersection of a work-sample test with one question from an IQ test In the worst case this is true. But ideally the question will have various components, and various levels of difficulty. I'm reminded of a blog posted here some time ago that had the candidate split a string based on a provided dictionary of words (or something to that effect). The best candidates produced maximally eff…

That still doesn't help the candidates who just don't see the trick. What if you know memoization and dynamic programming, but it just doesn't occur to you that day, that to correctly split on spaces (not adding empty tokens at the beginning and end of the string, etc.) you need to use a state machine? You could give the candidate that "step" of the solution and continue on to see if they know the rest, but the candi…

>That still doesn't help the candidates who just don't see the trick.

This may be true, but at the same time candidates who DO see the trick get positive points. Because a lot of these puzzle questions simply require you to think outside the box, if you're forgive the use of that phrase, and honestly if you have hard programming problems to solve that is a killer skill.

I have (once) had the problem where my mind locked up on a puzzle question in an interview. (Disclaimer: Usually I'm really good at them, but then I usually get most of the IQ questions right too...) But I got the job anyway.

The point is that HOW you use these questions is at least as important as the content of the questions. If you ARE willing to work with the candidate on finding the answer, and you make it clear that it's not a make-or-break question, then I think it CAN be (at least) a positive filter for awesomeness.

Yes, sometimes you could let someone fall through the cracks that way. Nothing about the interview process is perfect, though, and if what you really need is someone who is awesome, then letting someone get away who IS awesome is much better than serially hiring people who AREN'T awesome hoping that you find one eventually.

That said, and as others have pointed out in comments: 99% of the projects I hear about on HN would NOT require awesome. They just require competence. And solving IQ puzzles isn't how you detect competence.

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

#324

Post by wahnfrieden » Fri, Feb 22, 2013, 9:56 PM UTC

benjaminwootton wrote: post #107

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…

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.

Dealing with outages is one time where I have to think on my feet in a tense and urgent situation, and occasionally write code.

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

#325

Post by pseut » Fri, Feb 22, 2013, 10:00 PM UTC

ry0ohki wrote: post #308

pseut wrote: 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?

Pretend it's not tech, and Starbucks interview consisted of you working as a barista for a day, or Goldman Sachs wanted you to trade stocks for a day, etc...

I'm not sure that I have a constructive way of replying to this. Can you spell out your objections, instead of trying to jostle my imagination?

You act like no one's been fired after their first day at Starbucks.

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

#326

Post by danielweber » Fri, Feb 22, 2013, 10:00 PM UTC

grey-area wrote: post #304

bearmf wrote: post #272

Earlier quoted context omitted.

'select the second highest number in this list' is actually O(n) and does not require sorting.

Does that mean I fail the test :) A sort then select for the second highest seemed the simplest solution off the cuff (perhaps not the quickest), and if the code is fast enough, there's no point in optimising. Of course you could write a loop and check each value against a stored memo - your O(n) right?, but why bother when the library sort is fast enough for the purpose? If you're dealing with genuinely huge data se…

As the person who posted that question, if you gave me that answer right away, I'd say "good, but can you do better?"

"Sort and take the second highest" is a fine first answer. I'd expect most good candidates to start with that. I'd also expect them to say "but I think I can do better" on their own.

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

#327

Post by danielweber » Fri, Feb 22, 2013, 10:07 PM UTC

grey-area wrote: post #244

hackinthebochs wrote: post #210

Earlier quoted context omitted.

> It's that they are irritated by tests which don't measure what they're supposed to I disagree that programming puzzles don't measure what they're supposed to. Programming puzzles are a microcosm of what programming entails day-to-day. They test the same exact mental faculties. Sure, no one needs to write strcmp using primitives anymore, but the task of doing so exercises the same mental processes that are involved…

Comparing strings and reversing linked lists do absolutely measure this capability. This depends entirely on the quality if the test. I suspect for many of these ad-hoc tests thrown together for an interview, the quality will be low and the overlap with other tests high, meaning they can easily be passed by someone who googled 'top 100 programming interview questions' and read through them. Comparing strings or rever…

I suspect for many of these ad-hoc tests thrown together for an interview

If you assume the process is going to be done in a stupid manner, it doesn't matter what process you use.

"Oh, I looked through your open source code on github, but there only 10% of it was Ruby. We are an all-Ruby shop, not a 10% Ruby shop."

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

#328

Post by jdavis703 » Fri, Feb 22, 2013, 10:08 PM UTC

At my old company we'd tell interviewees to bring a laptop loaded with there usual dev tools. After a couple of typical interview questions they were then instructed to create a small program using whatever language/tools they'd like. They had "unlimited" time and sat at an empty cubicle. Candidates also has had full access to the Internet. It was amazing how several people could not even complete the simplest program without needing extensive assistance.

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

#329

Post by Tekker » Fri, Feb 22, 2013, 10:20 PM UTC

When I interview others, I use a couple of basic whiteboard show-me pseudocode questions (how would you reverse a string, how does a linked list work, give me an example of a callback). It seems to me that if they know their stuff, they can answer those. If someone can't get through any of them, or at least have a valient stab at it, chances are they don't have the background I want.

By the same token, I've been interviewed myself where I've been given weird shit questions like others have mentioned; not the blender one, but shit along that line. That's nothing I personally do without some serious contemplation, not to be achieved in 5 minutes in an interview. Anyone who does so likely knew the answer ahead of time or is extremely puzzle-oriented. I think the real test is to examine the puzzle-solving processes of the candidate, but as a rule I don't think much of those kinds of questions.

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

#330

Post by grey-area » Fri, Feb 22, 2013, 10:26 PM UTC

danielweber wrote: post #326

grey-area wrote: post #304

Earlier quoted context omitted.

Does that mean I fail the test :) A sort then select for the second highest seemed the simplest solution off the cuff (perhaps not the quickest), and if the code is fast enough, there's no point in optimising. Of course you could write a loop and check each value against a stored memo - your O(n) right?, but why bother when the library sort is fast enough for the purpose? If you're dealing with genuinely huge data se…

As the person who posted that question, if you gave me that answer right away, I'd say "good, but can you do better?" "Sort and take the second highest" is a fine first answer. I'd expect most good candidates to start with that. I'd also expect them to say "but I think I can do better" on their own.

This is where I find questions like this a little confusing. To define better (at least in real world situations) the question requires more context. How many records? How are they stored? What are the characteristics of the storage? Which libraries are we using to store it and how do they behave (and in the real world there might be a few)? What are the other constraints? If we request a sort (say in a remote db) will that be quicker than the latency of requesting data in batches and iterating?

Presumably you mean better given infinite memory to store all the records and a very large number of records? Because for most small collections of say a few thousand, a sort then select would be better than an iteration IMHO as it is simpler and the intent is clear if performance is acceptable. Perhaps I have misunderstood the intent of the question though, I'd be interested to hear what you feel is the ideal answer.