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

#451

Post by qu4z-2 » Mon, Feb 25, 2013, 5:27 AM UTC

hkmurakami wrote: post #49

potatolicious wrote: post #12

Damn right. Even worse than whiteboarding random algorithms are logic puzzles. I can sort of see how implementing my own hash table fits into a dev job, but I why manhole covers are round, or light bulbs in a room has absolutely nothing to do with anything relevant in our field. People who use logic puzzles as proxies for anything in an interview have my everlasting scorn.

Logic puzzles test how much the candidate prepared for logic puzzles. It implicitly tests how much the candidate "wants the job", but it also has the effect of turning away the stars who have options. As the best continue to have more and more options available to them where the team members understand that this kind of interviewing is counterproductive, companies that continue to use puzzles will end up with candida…

I dunno. I enjoy solving puzzles.

Maybe I'm not a star :)

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

#452

Post by qu4z-2 » Mon, Feb 25, 2013, 5:32 AM UTC

mmorett wrote: post #430

mseebach wrote: post #423

Earlier quoted context omitted.

Your solution is fine, you've passed, flying colours. I might poke a bit around the edges to see if I can get you to say the word "array", but mostly out of interest. The important bit is that this is not an assessment of your ability as a programmer, it's a negative filter: Are you one of these people who simply can't program, because if you can't, let's not waste any more of each others time.

Arrays. (Uhhg...I said it but I feel dirty.) ;-~ I've never liked arrays due to the brackets. But in a twist of irony, I now spend all day in Groovy and I use maps, thus brackets all the time. Yet I don't even notice. So after carefully thinking about it, I now realize its not the brackets. I can't explain it. There's something about arrays I just despise despite having no similar ill will towards ArrayLists. They ju…

Personally I much prefer a[i - 1] syntax over a.charAt(i - 1). The extra "charAt" seems noisy to me. But that's probably just my C background showing.

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

#453

Post by papsosouid » Mon, Feb 25, 2013, 2:46 PM UTC

maigret wrote: post #424

papsosouid wrote: post #178

Earlier quoted context omitted.

Why should programming contest problems be tests of practical sysadmin skills? That makes no sense at all.

Because this is much more than sysadmin skills involved. You've got to get a scalable application written first. It doesn't need to be complicated, but it needs to be robust and keep data consistent... etc. Also, this type of skills is badly missing to fresh grads.

No you don't, it says setup a django app. That involves writing no code, and is entirely a standard sysadmin task.

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

#454

Post by papsosouid » Mon, Feb 25, 2013, 2:47 PM UTC

buro9 wrote: post #405

papsosouid wrote: post #175

Earlier quoted context omitted.

>What non-technical hobby or interest do you have? That seems like a poor choice. Are you trying to eliminate people who don't have non-technical hobbies for some reason?

It's fairly irrelevant, the last part is the important part... very rarely I do find someone who stubbornly declare that they have no other interests at all, but then I just propose for them some pastime or other that may fascinate them.

>very rarely I do find someone who stubbornly declare that they have no other interests at all

Of course, but your wording rules out a large number of likely interests as they are technical.

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

#455

Post by papsosouid » Mon, Feb 25, 2013, 9:20 PM UTC

Ziomislaw wrote: post #386

papsosouid wrote: post #184

>I remember the first time I interviewed for a front-end programming position and got asked how to do something in JavaScript on a white board >how little it had to do with the actual job. That doesn't make any sense. How is solving a problem with javascript irrelevant to the job of a front end developer? That's what they do.

oh! you write your code on a whiteboard? do you have to type it into a computer by yourself or do you have people doing this for you? ;)

Writing it on a whiteboard instead of in a text editor takes it from 100% completely relevant to 100% completely irrelevant?

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

#456

Post by dragonwriter » Tue, Feb 26, 2013, 5:08 PM UTC

Jabbles wrote: post #149

AdamTReineke wrote: post #130

Earlier quoted context omitted.

My all-time favorite interview was one when I was interviewing for an SDET intern position at Microsoft. That interview (one in a day of four interviews) featured a great progression: logic puzzle, code the fixed input solution, code the n input solution, test your solution. The puzzle was (apologies to the interviewer, but it IS a common puzzle) the eight ball and balance problem, where one ball is heavier than the…

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…

> 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.

And...all of this is information the interview panel typically has available when evaluating candidates, as well as the result of any exercises done as part of the interview.

> It is an example of the interviewer (or company/process) mistaking a specific problem as representative of all problems. Presumably they're looking for someone with "general problem solving skills", rather than "knowledge of astrophysics".

If the process uses just one and not a set of exercises spread across problem domains, and gives it a fixed weight in the evaluation process and considers it independently of the candidates resume, the rest of the interview, etc., treating each component orthogonally rather than evaluating them together holistically, that might be true.

But that's not a problem with the puzzle as a tool, that's a problem with how the tool is used.

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

#457

Post by jdmichal » Tue, Feb 26, 2013, 7:52 PM UTC

boomzilla wrote: post #155

jdmichal wrote: post #85

Earlier quoted context omitted.

I have a similar story with Microsoft when I interviewed with them my senior year also. I feel like I nailed everything except for the puzzles, and also got denied. My favorite one I "failed" on was: Given a node of a linked list, delete that node. The expected answer: Copy the next node's contents into the given node. Then delete the next node. Just simply never occurred to me to use a memory copy in a linked list.…

but that is not a puzzle, it's real code if you don't access to a collection library

No, it's a puzzle for two reasons:

1. It's not a normal operation for a linked list. A normal linked list will expose operations to deal with items, not nodes.

2. There was an expected answer, and that answer was something other than the normal linked list delete operation of "traverse the list to find the node containing the item, while also keeping a trailing pointer to the previous item so that you can remove that item's node."

Even if you are exposing nodes, and you do implement the given operation, then TheCoelacanth is absolutely correct that that operation just invalidated all references to the node after the one you thought you had just deleted, but not any references to the node you thought you had deleted. (Though those references are now pointing to a different data instance.)

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

#458

Post by jdmichal » Tue, Feb 26, 2013, 7:55 PM UTC

TheCoelacanth wrote: post #203

jdmichal wrote: post #85

Earlier quoted context omitted.

I have a similar story with Microsoft when I interviewed with them my senior year also. I feel like I nailed everything except for the puzzles, and also got denied. My favorite one I "failed" on was: Given a node of a linked list, delete that node. The expected answer: Copy the next node's contents into the given node. Then delete the next node. Just simply never occurred to me to use a memory copy in a linked list.…

In addition to not being able to delete the last node, it also invalidates any pointers to the node after the one you're deleting.

Great point, and not something I had thought of. Just makes the "expected" solution even more odd... If you're exposing nodes enough to get an operation to delete a particular node with no context, then the given solution just invalidated a completely different node, but not the one you asked it to delete. No, the one you asked it to delete is still valid, just with different data associated.

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

#459

Post by buro9 » Wed, Feb 27, 2013, 3:19 PM UTC

papsosouid wrote: post #454

buro9 wrote: post #405

Earlier quoted context omitted.

It's fairly irrelevant, the last part is the important part... very rarely I do find someone who stubbornly declare that they have no other interests at all, but then I just propose for them some pastime or other that may fascinate them.

>very rarely I do find someone who stubbornly declare that they have no other interests at all Of course, but your wording rules out a large number of likely interests as they are technical.

Not at all.

One interview was someone into rally driving and who was dreaming up HUD units in his car, to allow him to see his progress in real-time compared to those who had already raced, and to report tons of sensor based info back to the press hut.

Then there was the rock climber who wondered whether rope tension could reveal the likelihood of the tether point giving way.

Good hires raise interesting questions and then set to figuring out the many ways to answer them.

The majority of hires I've made are technical, but their pastimes are not generally "When I go home I code".

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

#460

Post by maigret » Fri, Mar 01, 2013, 9:40 PM UTC

papsosouid wrote: post #453

maigret wrote: post #424

Earlier quoted context omitted.

Because this is much more than sysadmin skills involved. You've got to get a scalable application written first. It doesn't need to be complicated, but it needs to be robust and keep data consistent... etc. Also, this type of skills is badly missing to fresh grads.

No you don't, it says setup a django app. That involves writing no code, and is entirely a standard sysadmin task.

Script is code too. But I don't think you get there with plain sysadmin skills. How do you sync up the data between the regions? I have worked on a similar case not long ago, and there were definitely more than just "sysadmin" skills involved. I suppose Kent Beck also went through the same exercise. Pointing to the deficiency of usual contests is a good thing. In any case, if all sysadmins can do continuous deployment, cloud management and worldwide distributed apps, then I've definitely met the wrong ones before.