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

141–150 of 460 posts

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

#141

Post by danielweber »

csmatt wrote: 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…

There are jobs where algorithms matter. Where someone picking the wrong data structure or algorithm can completely fuck up the problem, or where the company's secret sauce is doing something much faster than their competitors are doing it.

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

#142

Post by mamcx »

kamaal wrote: post #103

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…

I do something like that. My first test is ask to reverse a string (not using the reverse function!) in any language and/or pseudocode. Is incredible how badly the test goes with the people! I interview for myself or others more than 100 people (of any background, including university, tech schols...) and I think only 10/12 people do it correctly - barely-

To make it more fair, I always let them alone. And give internet and a computer, and remember them they can use internet and search. Not even with that amount of help the thing work well (I truly have find someone smart enough to copy-paste something and return to me in 1 minute or less).

Then i do the puzzle question, but know I retire it some years ago and some more question about real stuff...

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

#143

Post by jes5199 »

fiblye wrote: post #134

I was invited to a company for a game development position. One part of the interview consisted of a fairly challenging mathematical/algorithmic problem. It wasn't impossible, but it's certainly not something I can do in ten minutes at a white board with some people taking notes about my every movement. The other part was being shown intentionally messy and broken code. Not code that'd fail to compile (although it su…

Plenty of the gigs I've had have been mostly trying to unscramble really confusing code that mostly-works. If my codebase has a bunch of strange crap in it that I need fixed, I certainly will bring examples of it to the interview.

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

#144

Post by danielweber »

buro9 wrote: post #39

The question I always like to ask and reserve a good chunk of time for is along the lines of "What non-technical hobby or interest do you have?" and then "If you had all the technical resources you could dream of, how would you now bring something new to your hobby?" and once we've gone through that the real question is: "Given that when you're duck hunting the key is to shoot ahead of where the duck is, and that a l…

And when asked about your hobby, don't say "shoot hoops."

(referring to http://news.ycombinator.com/item?id=5255227 )

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

#145

Post by ori_b »

grey-area wrote: post #91
cletus wrote: 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…

I think the point of the article is this: Trivial puzzlers like:write a fizzbuzz program, swap two variable contents without using a temp variable, how do you count the stars in the universe Just encourage people to game the system. It's impossible to get real insight from them, because you can't differentiate between those who worked it out, and those who have read about it. If you're in an interview by now and some…

It's impossible to get real insight from them, because you can't differentiate between those who worked it out, and those who have read about it.

The fact that they're involved enough in the industry to know about fizzbuzz is still a strong signal. It will only come up if participate in some sort of developer community, which, I suspect, is something that the completely incompetent don't do, as a rule.

Once again, it's not designed to find the top talent. It's merely a high pass filter that removes the hopeless from the set of people to consider.

But even if fizzbuzz is something that the hopeless start learning by rote, switching it out for any other trivial problem will still work. "Count the number of 'a's that come after 'g's in a string", "print the lyrics to 99 bottles of beer", or hundreds of other problems like that are just fine for the task.

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

#146

Post by mleach »

pc86 wrote: post #114
donw wrote: post #80

Earlier quoted context omitted.

I'm not sure if I'm that guy or not... but anyhow, here's the hiring process that's given me some good results. Note that this requires that your team does pairing. Interviewing answers three questions: Can they do the job? Do they get along with the team? And, can they adapt when the game changes? Before your phone interview, let them know that you want to do a short screen-sharing and pair-programming exercise via…

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.

There is more "soft skill" assessment going on with pair programming than "hard skills".

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

#147

Post by danielweber »

dmbaggett wrote: post #79
mapleoin wrote: post #27

Earlier quoted context omitted.

I think it's the opposite. If the first thing you confront me with in your interview process is a puzzle and I don't know anything about your IT department, I'm going to assume that all your managers are pointy-haired bosses.

Empirical evidence from over 10 years suggests you're an outlier.

This is just signalling. "Do X and I will think you are an idiot!" is his way of saying "please don't do X."

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

#148

Post by codeonfire »

127001brewer wrote: post #136
codeonfire wrote: post #129

Earlier quoted context omitted.

What is shocking is the fact that in companies where devs have no say in hiring, managers hire those people and then ignore the fact that they do nothing (or try to promote them out of development) to try and cover up their mistake. It is incredibly demoralizing working ten hour days trying to deliver working code while someone else is producing nothing, getting ahead, and going home at 4 pm. This shit is by far the…

How do you " keep it real " in interviews? Concerning the viability of firing under-performing individuals, how likely is that? Are there any implications with indirect costs such as unemployment benefits? (I ask because I do not know - any insight on this would be greatly appreciated.)

I ask difficult interview questions and require actual code to be written on the spot. If the questions can't be answered I let everyone know it. The viability of firing under-performing people is zero. Managers just want headcount and don't care about ability. They play the political game not the build-and-ship-software game.

Are there cost implications? I should think so since the fakers cost lots of money and are not producing any software.

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

#149

Post by Jabbles »

AdamTReineke wrote: post #130
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.

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 problems. Presumably they're looking for someone with "general problem solving skills", rather than "knowledge of astrophysics".

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

#150

Post by jwwest »

The best interview I ever had, I was given a problem to solve with a system, a whiteboard and 20 minutes.

I sketched out a quick ERD, and explained the high level architecture of the system. No code was written -- it was assumed that I could implement said system if I could design it.

The worst job interview grilled me on low level algorithms (I'm not a CS grad) and wanted me to sketch out a quick sort. Of course, I can describe a quick sort now as a result of said interview, but since it was all C# I doubt we were going to have to implement our own sort algorithms.

Another terrible interviewer asked me about projects I did in college. I finished grad school 3 years ago, and have 8 years professional experience...

Post reply on HN