It seems like the rather more difficult problem is getting competent programmers to want to work at your company and apply.
Interviews Can Be a Terrible Way to Identify Good Programmers
21–30 of 108 posts
Re: Interviews Can Be a Terrible Way to Identify Good Programmers
#221. 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
#23No 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…
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/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…
Re: Interviews Can Be a Terrible Way to Identify Good Programmers
#25To 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.
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
#26It 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.
It's also extremely depressing.
Re: Interviews Can Be a Terrible Way to Identify Good Programmers
#27It 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
#28One 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…
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
#29It 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.
...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
#30No 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.
Why?