Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interviews Can Be a Terrible Way to Identify Good Programmers

thecodist.com

Post reply on HN
Print view View original

61–70 of 108 posts

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#61

Post by amcintyre »

kabdib wrote: post #5

One of my favorite questions is: "What's the best bug you've ever found?" Usually I get a "Huh?" The really stellar folks will tell you about the bug that took two weeks to find and boiled down to a single missing comma in a vendor's library routine. Or /something/. But "Huh" is a bad sign. "Huh?" is not a fail, but it usually correlates with people who can't write a function to find the length of a string, and I see…

One of my favorite questions is: "What's the best bug you've ever found?"

One of the problems I always have with questions like that is this: I don't keep mental lists of events or other things ordered by potential "interestingness" to myself or other people. I just don't think that way for some reason.

I might fumble to come up with an answer to that question, and then an hour after the interview is over, I'll remember a really good story the interviewer would have liked, but in the meantime I've looked like an inexperienced, bumbling fool.

Not that it really matters, of course--eventually I'll get through an interview without hitting a question that doesn't work for me, get hired, and then actually get to do some good work for somebody. Getting through that process feels fairly random to me.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#62

Post by captobvious »

There is a lot of focus on team work. I'm still not sure if programming is suited for team work. There's clearly some activities of creative problem solving which are better suited for individuals working mostly alone, but belonging to a community of peers.

For example: * math * research * art * visual design * writing * music

* programming?

People have been trying to apply Taylorism to programming making it approach an assembly line in organization. Now we're trying to organize programmers as sports teams instead with Agile.

I just don't understand why programming specifically is under this intense pressure of having to be measurable and quantifiable in every little detail.

It seems like being a good cog in an assembly line, or a good member of a sports team is just as important, if not more, as just creating good programs. Why aren't for example visual designers being hassled in this way? No they are beging left alone as long as they do good stuff. They can freelance or work from home if they want.

But programming is somehow different. There's this assumption that it needs to be done in a group at all times. Solving all problems by group discussion.

If I was hiring I would just ask to see previous project, and/or a portfolio (github for example). If they have nothing to show, or it's really bad and show no signs of progress, I would not hire. Simple as that.

I wouldn't hire a group of 15 clearly sub-standard visual designers who have nothing to show, try to organize them into a group, measure closely and try to make them create visual design.

In the same way I would not try to do this with programmers either.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#63

Post by exim »

cletus wrote: post #8

/sigh interview techniques really are a perennial topic on HN. > [a coding test] won't tell you squat about how good they are in a year long project with 10 other people, The author misses the point of a coding test. It's a negative rather than positive filter. Someone who does amazing on FizzBuzz is not by definition an amazing programmer. Someone who can't solve FizzBuzz however almost certainly is not a good progr…

FizzBuzz is OK for quick filtering, but asking to come up with an efficient substring search algorithm ([1] or similar) on the spot, assuming that one doesn't know this algorithm a priori (and many good programmers don't), for which, scientists like Knuth, Morris and Pratt spent months, is just ridiculous.

[1] http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pr...

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#64

Post by parbo »

kabdib wrote: post #5

One of my favorite questions is: "What's the best bug you've ever found?" Usually I get a "Huh?" The really stellar folks will tell you about the bug that took two weeks to find and boiled down to a single missing comma in a vendor's library routine. Or /something/. But "Huh" is a bad sign. "Huh?" is not a fail, but it usually correlates with people who can't write a function to find the length of a string, and I see…

Compiler bugs are always satisfying to find. "It's never the compiler", but sometimes it is: http://llvm.org/bugs/show_bug.cgi?id=12419

But I think my best one was when I found a bug in a third party communication library, that only manifested itself on ARM architecture. Our CPU was PPC, and our simulator was x86. On both of those, unaligned memory reads work fine. But the actual unit we'd talk to had an ARM CPU. On ARM it just reads from the closest(?) aligned address. I found that by looking at network logs and reading the source (which we thankfully had).

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#65

Post by AncientPC »

SatvikBeri wrote: post #29
sanderjd wrote: post #13

Earlier quoted context omitted.

Do people actually use FizzBuzz itself ? I always thought it was just one example illustrative of the type of simple and quick-to-answer question that makes a good initial negative filter.

SQL equivalent: "Explain the difference between a left join and a full join." ...seriously, this filters out a depressing number of people who put SQL on their resume and are applying for a SQL job.

I don't use SQL very often, but I've found Jeff Atwood's explanation using Venn diagrams sticks in my memory pretty well:

http://www.codinghorror.com/blog/2007/10/a-visual-explanatio...

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#66

Post by yason »

nodemaker wrote: post #36
cletus wrote: post #8

/sigh interview techniques really are a perennial topic on HN. > [a coding test] won't tell you squat about how good they are in a year long project with 10 other people, The author misses the point of a coding test. It's a negative rather than positive filter. Someone who does amazing on FizzBuzz is not by definition an amazing programmer. Someone who can't solve FizzBuzz however almost certainly is not a good progr…

What exactly do you (or for that matter Google hiring in general) consider fizzbuzz?....Is Pascals's triangle fizzbuzz?...how about an algorithm for calculating the Levenshtein Distance? It seems like everyone has a pet favorite interview problem that they like to throw at the candidate and in my experience some of them were definitely not fizzbuzz .And then if one interviewer doesn't like you then you dont get hired…

I've understood that FizzBuzz is the lowest possible requirement for any programming job. It's a trivial programming exercise that doesn't require experience in algorithmic theory or mathematics. It's like going to the driving test and being asked to start the car: anyone who wouldn't know how to do that is likely highly incapable of passing the actual test.

Now, the astonishing issue, for me, is that there apparently are huge loads of people applying for programming positions who actually fail FizzBuzz. In effect, it's akin to applying for the position of a bus driver "coz I once travelled on a bus". I don't get that but apparently it does happen often enough to warrant FizzBuzz.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#67

Post by yason »

notJim wrote: post #21

I'm curious, is it really that hard to identify competent programmers? Surely asking a few technical questions that include some element of programming should be enough. I feel like there's about 5-10 articles on this subject every week, all of which say or or less the same thing. In very nearly every case that I've interviewed someone, I've been able to easily decide if they were a hire or a no hire about 20 minutes…

Identifying competent programmers is hard as long as you try to quantify it. You don't make decisions based on rational facts that come from a rational process, as nobody does. In the end, the decision comes from a feeling that we so hard try to belittle.

The rational mind can make a "decision", like "this candidate passed all our interviews and qualifies on paper: that means we can hire him". But the true decision of hiring someone is more like a "to engage or not to engage ourselves with this guy, in a joint (work) life together and into the future". Conversely, you can just decide to nominally hire people but never back it up on a personal, human level.

The process of hiring is golden as a negative filter: you want to weed out people who factually aren't up to it. But there's no positive filter that you can unilaterally apply. In the end, you just have to let yourself "know" who to hire because there's nothing else you can do.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#68

Post by nightski »

jcrites wrote: post #39
nodemaker wrote: post #36

Earlier quoted context omitted.

What exactly do you (or for that matter Google hiring in general) consider fizzbuzz?....Is Pascals's triangle fizzbuzz?...how about an algorithm for calculating the Levenshtein Distance? It seems like everyone has a pet favorite interview problem that they like to throw at the candidate and in my experience some of them were definitely not fizzbuzz .And then if one interviewer doesn't like you then you dont get hired…

One reason that interviewers ask the same question to many candidates (i.e., seem to have a "pet" problem) is because they have calibrated the question. A strong interviewer has asked that question to respected colleagues at various levels, and many tens or even hundreds of candidates. He knows all the ins-and-outs of the question, and more importantly, knows how to judge someone's effectiveness in that topic area ba…

Congratulations on marrying the interview process to a single question. I hope that question is very close to the core competency you are hiring for.

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#69

Post by jchughes »

Being a recent graduate of computer science and now job hunting I have come across several different types of interviews in the last few months. I have sat a coding test where they just asked me to write a very basic CRUD application in code igniter, also had the here is a scenario you have 15 minutes to write a presentation and then present us with your result, plus an interview where I was asked to do some UML on a whiteboard.

But the best method I have come across was where I was just asked 20 or so questions of basic computer science knowledge from OOP to networking to basic CS theory.

I say this was my favourite method because I know some recent graduates who could and can write a very simple application but are terrible programmers and would not last the probationary period (actually happened to someone I know) but I know that if you asked them a series of basic questions they would stumble and fall because in general they where just terrible computer scientists and once outside of the very basic elements of programming they knew nothing so what good does asking someone to write fizzbuzz actually do? apart from weed out the idiots (then again I know someone else who failed fizzbuzz, largely because he managed to get through 3 years of CS and not know about using %).

Re: Interviews Can Be a Terrible Way to Identify Good Programmers

#70

Post by calibraxis »

amcintyre wrote: post #61
kabdib wrote: post #5

One of my favorite questions is: "What's the best bug you've ever found?" Usually I get a "Huh?" The really stellar folks will tell you about the bug that took two weeks to find and boiled down to a single missing comma in a vendor's library routine. Or /something/. But "Huh" is a bad sign. "Huh?" is not a fail, but it usually correlates with people who can't write a function to find the length of a string, and I see…

One of my favorite questions is: "What's the best bug you've ever found?" One of the problems I always have with questions like that is this: I don't keep mental lists of events or other things ordered by potential "interestingness" to myself or other people. I just don't think that way for some reason. I might fumble to come up with an answer to that question, and then an hour after the interview is over, I'll remem…

Same here. To compensate, I load my memory up with "interesting" anecdotes for interviews. Including my most embarrassing moment, which luckily happens to center around a bug. (Failing that, I'd probably grab a recent bug and dress it up to be interesting. I guess you can always riff about techniques which prevent that particular class of bugs.)

But now of course, if I ever go on an interview again, I'd dredge up some funny bug. Just in case. :)

Post reply on HN