Interviews Can Be a Terrible Way to Identify Good Programmers • Hacker News Board

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

#31

Post by kenrikm » Sun, May 06, 2012, 1:51 AM UTC

rfrey wrote: post #25

jemfinch wrote: post #15

Earlier quoted context omitted.

"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?

Good designers buy stock photos for generic things and fill in with custom bits to produce a finished piece.

Good programmers copy/pase boilerplate code and focus on the stuff that really makes it different. (iOS example) you don't write out all of the methods for a UITableView.. That would be a waste of time you copy/paste the methods you need and change the important bits.

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

#32

Post by fendale » Sun, May 06, 2012, 1:55 AM UTC

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.

What is a full join? I've been working with Oracle for 10 years and I've never used that term. I know what a left join is and an outer join, but not a full join.

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

#33

Post by rpwilcox » Sun, May 06, 2012, 2:07 AM UTC

notJim wrote: post #18

Good to see that we're making good efforts at meeting our "articles about hiring" quota on HN. I have this theory that hiring people is nowhere near as hard as this particular echo-chamber likes to think it is. Everyone thinks they need "rockstars" or "A Players" and is looking for the magical recipe for finding them, but I think for most positions, someone who is smart and technically competent and fits with your co…

Yes thank you. The OP does briefly mention the "looking for rock star" thing, but I get mad that every single job posting I see seems to be "OMG MUST HAVE ROCKSTAR". Or gawds, lately "OMG MUST HAVE DAN SHIPPER".

First, probably if you got an actual rock star programmer (Zed Shaw comes to mind), you probably wouldn't be able to handle/keep him.

Secondly, really? You want people that crank out Lisp transpilers in their spare time... But what about people that maybe are good with taking some oddball client spec and going back and forth to understand the desired behavior and distill something that is actually possible to implement? What about the guy who takes that extra 10% of time to implement a feature, but they end up giving you some new common code you can apply in your app?

Maybe these people don't dream Ruby DSLs, or have Github Infinity number of issues in their inbox, but they can still be valuable to a team. Because the best code in the world is useless if the programmer has misunderstood what the client is really saying.

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

#34

Post by rsbrown » Sun, May 06, 2012, 2:07 AM UTC

Yes, yes, 1000 times yes. Particularly the basketball team analogy at the end of the article really resonates with me.

To anyone wondering, "How could this possibly be true? How could so many companies be getting the hiring process so wrong?" I say: it's because they aren't focused on the goal. That doens't mean companies never achieve their goals, they are simply optimizing the wrong aspects of the process.

For anyone interested, the book The Goal by Eli Goldratt (http://en.wikipedia.org/wiki/The_Goal_(novel)) illustrates this phenomenon very well.

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

#35

Post by davvid » Sun, May 06, 2012, 2:17 AM UTC

I'm happy where I work.

I interviewed for google once; their recruiter found me through an open source project in which google has a stake.

Anyways, I was tired when I did my phone interview, having just returned home from work. I bombed a couple of those interview puzzles. I felt pretty stupid because the answers are really obvious to me in hindsight. No biggie.

So this week they interviewed a junior programmer I mentored in the past. It looks like they might hire him! :-) good one. If they asked him he'd easily send them my way (guess who he comes to whenever he has questions?) Oh well.

If their recruiter contacts me again I might still do another interview. Their "write some code in a google document" interview style was novel, but possibly sub-optimal. YMMV

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

#36

Post by nodemaker » Sun, May 06, 2012, 2:24 AM UTC

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.All the work you have done is irrelevant if that pet problem is not solved optimally on the whiteboard.But then of course I am probably a little incompetent too.

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

#37

Post by tveita » Sun, May 06, 2012, 2:30 AM UTC

kevinpet wrote: post #7

angdis wrote: post #2

He makes a brings up an interesting point about the idea checking the effectiveness of interview methods. It seems that lots of people have intricate hacks for divining the talented programmers in an interview, but NO ONE can back their methods up with hard data based on performance and non-performance of candidates over project time-spans.

This a good point. It seems somewhat unavoidable, since no one will ever be in a position to evaluate the effectiveness of both those who did well on their metric and those who did poorly (since they will only hire those who do well). Perhaps there are companies out there with a large enough sample size that are recording metrics on a "programming concepts verbal interview", "analytical thinking verbal interview", "p…

If you wanted to go about it scientifically, you could hire some fraction of the people that wouldn't have passed based on the current practices.

That's a pretty scary thing to do, but it could be worth it for a large company which needs to improve its hiring. Think exploration/exploitation.

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

#38

Post by mistercow » Sun, May 06, 2012, 2:34 AM UTC

decadentcactus wrote: post #23

jasonlotito wrote: post #3

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.

Why would you need to have a CS degree?

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

#39

Post by jcrites » Sun, May 06, 2012, 2:50 AM UTC

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…

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 based on their answers.

If you asked a different question to every candidate you interviewed, it would be very difficult to get a sense of how they compare to other candidates, or to employees.

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

#40

Post by mkramlich » Sun, May 06, 2012, 2:52 AM UTC

davvid wrote: post #35

I'm happy where I work. I interviewed for google once; their recruiter found me through an open source project in which google has a stake. Anyways, I was tired when I did my phone interview, having just returned home from work. I bombed a couple of those interview puzzles. I felt pretty stupid because the answers are really obvious to me in hindsight. No biggie. So this week they interviewed a junior programmer I me…

If they come crawling after you again, tell them you'd need double the salary you might have accepted last time. If they accept, you win. If they decline, you still have the pleasure of making that stand.