Live data from Hacker News

Interviews Can Be a Terrible Way to Identify Good Programmers

thecodist.com

21–30 of 108 posts

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

#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 into the interview process. I'm sure for certain positions or certain companies who are solving difficult problems, things could be more complicated, but the vast majority of us just aren't in that situation.

It seems like the rather more difficult problem is getting competent programmers to want to work at your company and apply.

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

#22
These articles reinforce something that someone told me a long time ago about a study about interviewing.

1. In most cases, the person (or the person in charge, if it is a panel) makes a decision in the first five minutes of the interview.

2. The decision is based on how much the candidate resembles the interviewer (i.e. how similar they are to the interviewer in terms of personality and skill set).

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

#23

No offense, but the only advice I've learned from all these "how to hire programmers" article, as a programmer, is that it doesn't make a damn bit of difference, because every person hiring as their own idea of what works. The best thing I can do to get hired somewhere is be myself. For every person who says not to bother with a resume, there is another person who wants them. For every person who denounces certain te…

It seems to me that regardless, you need to still have a CS degree and understand (and be able to implement) algorithms of increasing complexity, even if you're making a CRUD app.

But I agree, these interview posts altogether don't seem to say anything consistent.

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

#24
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…

[deleted]

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

#25
post #6

To fix coding interviews in this country, you need to insist on having a great coder do the interviewing. In 90% of the interviews I go on, I get evaluated by an HR type who could not write any program more significant than Hello World. What's funny is that the Non programmer interviewers are starting to administer coding tests, and they don't know what a good response is! So here I am doing a coding tests on a white…

"That's not how the best coders code, we offload most things to google searches" If that's really what you think, you may want to reconsider who the "we" you're talking about are.

I think it's fair to say that if you're stretching yourself, or working on challenging problems, a reasonable amount of time is spent researching. If you don't know how to do something, you research it. Whether you find it in a textbook or on Stack Overflow, it's essentially the same thing.

Unless you think "good" coders reinvent algorithms they don't know from first principles?

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

#26

It depends I've hired great people without having them write code. (Or at least, not in a whiteboard) Trust me, you can know a lot about a candidate without him or her writing a line of code (ok, maybe a line) My favorite question: "Tell me about a bug you once solved". That will tell you loads about the candidate Or ask him/her about the difference bewteen foldl and foldr But, really, I won't use FizzBuzz again "bla…

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.

FizzBuzz is great. I can stop 50% of interviews after asking it. Amazing timesaver.

It's also extremely depressing.

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

#27
meta post

It would be better if people would evaluate ideas in articles rather than use the author's name as a leverage point to launch personal attacks. Several posts here attack the author as being incompetent in various ways and not having had serious experience. Yet a brief review of his resume shows he works at Travelocity, worked at Apple in the past, and personally invented a innovative spreadsheet using a different information organization paradigm that ended up influencing iNumbers. So he's not really the dumbass that some people are trying to make him out to be. It's obvious he's a talented, serious and experienced engineer. There is nothing wrong with disagreeing with his article, but snarky and contemptuous remarks about his supposed incompetency detract severely from points made, making them seem like the critic is an immature schoolyard bully.

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

#28
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…

...I was tempted to relay the story of the best bug I ever found, and realized that it literally boils down to exactly what you said-a missing comma in a vendor's library. Wow.

What made it fun was that it was a SAS program (which I knew) with extremely complex, 5-layer deep macros that called VBScript (which I did not know) all over the place. Debugging stuff in a language you don't know under a tight deadline-that's a thrill!

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

#29

It depends I've hired great people without having them write code. (Or at least, not in a whiteboard) Trust me, you can know a lot about a candidate without him or her writing a line of code (ok, maybe a line) My favorite question: "Tell me about a bug you once solved". That will tell you loads about the candidate Or ask him/her about the difference bewteen foldl and foldr But, really, I won't use FizzBuzz again "bla…

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.

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

#30

No offense, but the only advice I've learned from all these "how to hire programmers" article, as a programmer, is that it doesn't make a damn bit of difference, because every person hiring as their own idea of what works. The best thing I can do to get hired somewhere is be myself. For every person who says not to bother with a resume, there is another person who wants them. For every person who denounces certain te…

It seems to me that regardless, you need to still have a CS degree and understand (and be able to implement) algorithms of increasing complexity, even if you're making a CRUD app. But I agree, these interview posts altogether don't seem to say anything consistent.

"you need to still have a CS degree and understand (and be able to implement) algorithms of increasing complexity, even if you're making a CRUD app."

Why?

Post reply on HN