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

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

#101

Post by eli_gottlieb » Mon, May 07, 2012, 3:19 AM UTC

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…

The version I got in an interview was, "What's your favorite algorithm?"

I stalled 30 seconds, pulled Lottery Scheduling out of my ass, and proceeded to do pretty well on the interview, then be told that they wouldn't hire me because they could tell I'd go to graduate school.

If you're ok with someone pulling an interesting story from memory rather than actually computing a total ordering on bugs or algorithms for "best", these questions work very well.

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

#102

Post by eli_gottlieb » Mon, May 07, 2012, 3:25 AM UTC

rpwilcox wrote: post #33

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…

What I always wonder is why they want "people that crank out Lisp transpilers in their spare time" (I'm reasonably close enough to that...) to come write CRUD apps in Rails.

My current day job is to write CRUD apps in Rails, but my long-term plan has me back in academia (for a PhD and a research career), where the ability to crank out a Lisp transpiler in one's spare time actually gets used.

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

#103

Post by EternalFury » Mon, May 07, 2012, 3:53 AM UTC

Ah, I am not alone!

Sure, simple tests to filter out people who clearly know nothing about programming are useful, but puzzlers and other ego-trip tests are useless.

I can hire better programmers by asking them to write an essay about any current piece of news.

The English language is the first programming language one should master. It's the one most useful to handle interactions with other human beings, and that's what makes the most important difference in any job.

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

#104

Post by exim » Mon, May 07, 2012, 7:40 AM UTC

elemeno wrote: post #89

exim wrote: post #63

Earlier quoted context omitted.

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...

Frankly, your comment bewilders me. Sure, you might not be able to replicate KMP in the middle of an interview if you didn't already know it, but I'd certainly expect any competent programmer to be able to come up with some form of solution (and I'd probably expect them to get reasonably close to KMP) reasonably quickly and then to be able to discuss their solution and identify it's flaws. A moderately intelligent ve…

I have several points/cases regarding inability to come up with a KMP like algorithm:

1. Fresh CS graduate from the top university (MIT, ETH, Stanford, etc..) - I agree, it is a bad sign.

2. Mid/late career professional - I disagree.

3. Self-taught professional - I disagree.

In latter two cases, some might just never needed/seen similar reasoning/algorithm implementation in their life, but that doesn't make them bad programmers.

Another point - many interviewers have beforehand written down exact fixed algorithm, and if your solution diverges at some point with that single variant (although your solution might be correct as well) - this is the red flag for them - and they interrupt you in the middle. I've experienced this even with an open ended design questions - this is really frustrating.

And my last point - remember that when KMP were coming up with this algorithm, no one were breathing in their back/neck.

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

#105

Post by kstenerud » Mon, May 07, 2012, 3:17 PM UTC

23david wrote: post #94

kstenerud wrote: post #85

Earlier quoted context omitted.

Want to know why there's such a disparity? Because some companies are good at hiring, and others suck and don't realize it. Want to know how to separate the good advice from the bad? Look for good companies and learn what their practices are. Find out how their organization works. If they're a lean mean innovation machine that values quality work and ships amazing products at a maintainable scale, chances are better…

Some companies succeed in spite of their engineering teams, and some companies succeed because of their engineering teams. What exactly is a good company? Is a great engineering team backed by incompetent management a good company? Or what about a company that has the full package but is unable to mail out paychecks on time and has a HR department that runs off anybody who exhibits an iota of independent thinking. It…

That's why I said "innovative, ships products, ahead of their competition, AND people like to work there". You can't get all of that without a quality, cohesive team covering many disciplines. And a bad hire into such a company increases the danger of derailing things. Thus, it's in any good company's best interests to carefully iterate and improve on their hiring practices, and any company that survives a long time with all of that intact is probably doing a lot of things right, including hiring.

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

#106

Post by lrobb » Mon, May 07, 2012, 4:35 PM UTC

exim wrote: post #104

elemeno wrote: post #89

Earlier quoted context omitted.

Frankly, your comment bewilders me. Sure, you might not be able to replicate KMP in the middle of an interview if you didn't already know it, but I'd certainly expect any competent programmer to be able to come up with some form of solution (and I'd probably expect them to get reasonably close to KMP) reasonably quickly and then to be able to discuss their solution and identify it's flaws. A moderately intelligent ve…

I have several points/cases regarding inability to come up with a KMP like algorithm: 1. Fresh CS graduate from the top university (MIT, ETH, Stanford, etc..) - I agree, it is a bad sign. 2. Mid/late career professional - I disagree. 3. Self-taught professional - I disagree. In latter two cases, some might just never needed/seen similar reasoning/algorithm implementation in their life, but that doesn't make them bad…

Agree on the 2 & 3... I've probably been out of school (CS) for longer than most on here have been programming.

Not being able to come up with KMP on a whiteboard in an interview hasn't kept me from playing no small part in producing millions in revenue for companies.

Especially outrageous is all of the companies that think they need to ask these questions, when the day to day work is essentially mundane CRUD type stuff.

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

#107

Post by lrobb » Mon, May 07, 2012, 4:44 PM UTC

ap22213 wrote: post #51

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…

Interviewing is a perennial topic because it doesn't make much sense. Case in point - over the past week I've interviewed for four positions. Three gave me offers within a day, with very little effort on my part. On the other hand, one told me that I had little idea of what I was doing and told me to study up and apply again next year. And, that was after wasting my time with 3.5 hours of interviews. Of the offers I…

The opportunity cost is the most frustrating aspect. I've solved several "sample" problems from companies, and been involved in full day interviews writing code on the whiteboard. The worse was spending a day writing some sample code, then doing a panel interview where I was asked to make a change to the code to cover a non-sensical edge case. I was rejected because I "hesitated".

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

#108

Post by brigade » Mon, May 07, 2012, 10:34 PM UTC

JoeAltmaier wrote: post #88

astrange wrote: post #84

Earlier quoted context omitted.

You can't express memcpy in hardware any more efficiently than you can in C because of the way memory controllers work. It'd end up being microcoded, and ARM can't afford that for the same reason it can't afford unaligned access. I think x86 does have a microcoded memcpy (rep stos) but efficiency varies.

You mention the memory controller; that's probably where the logic belongs, not on the processor. So the microcode would come down to "ask mc to move; wait for completion"

That's not actually any better speed-wise. And the CPU would still have to microcode the copy because of caches (think of what involvement the memory controller has in doing a cache to cache copy)

The real gain in being able to have the memory controller do a memcpy() independent of the CPU would be to let the CPU operate on data out of its caches in parallel to the memcpy() being executed. But that only helps for a very specific class of memcpy() and is highly system dependent (you have to worry about the expense of keeping caches coherent among other things.) Anyway, an integrated GPU or other additional block of hardware behind the memory controller is a better candidate for this sort of thing than a user-level CPU instruction.

Also, use a better libc.