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

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

#81

Post by Jach » Sun, May 06, 2012, 2:16 PM UTC

yason wrote: post #66

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…

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 apparentl…

What's even more astonishing to me than the fact that programming applicants mess it up is the fact that when the problem is introduced to a programming forum or blog there will inevitably be commenters commenting with a solution, and that solution will be wrong. The only car analogy I came up with was a person hearing about someone putting on their spare tire, so they go out to do it on their own car from memory of the account, and they do it wrong, when the instructions were right in the glovebox.

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

#82

Post by msluyter » Sun, May 06, 2012, 2:40 PM UTC

cletus wrote: post #59

ap22213 wrote: post #51

Earlier quoted context omitted.

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…

People make several mistakes when analyzing interview techniques: 1. The interviewer and interviewee are after similar and complementary things. Wrong. The interviewee is trying to find out if the work is interesting, whether or not this would be a good place to work, whether or not he or she could work in that environment with that team and so on. The interviewer (or rather the employer) is trying to fill a position…

The cost of a false negative is essentially zero as long as the employer can otherwise adequately fill the position.

I couldn't quantify them exactly, but I don't think the costs are zero. For one, any candidate that you bring in and reject consumes (in the case of my company) about 4 man hours of developer time. And that's mostly senior/lead developer time. And that's not counting the time we spend discussing the candidate and the general cost of a distraction/context-switch. And then there's the opportunity cost of not having a position filled and work being started. Sometimes the short run matters.

That said, I'd definitely agree that the scale should be tipped in favor of false negatives.

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

#83

Post by T-hawk » Sun, May 06, 2012, 3:00 PM UTC

JoeAltmaier wrote: post #80

parbo wrote: post #64

Earlier quoted context omitted.

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…

Funny - I remember when one of our new Engineers needed a memory-copy method for our ARM embedded solution - he went to Linux source and got some library routine. It faulted when I used it the 1st time. Fixed the bug (alignment of source), ran again and it faulted again. So I spent 10 minutes writing a test - move 0-128 bytes from source buffer offset 0-128 to destination buffer offset 0-128. Simple, overkill right?…

> why oh why don't CPU designers put a damned memory-copy instruction into the machine?

x86 has had REP MOVSB since forever, complete with a directional flag so you can handle the cases where the source and destination regions overlap. But it went out of favor since for a while from 80386 to early Pentium processors (when Linux was written), REP MOVSx was slower than writing an explicit memcopy loop.

That said, such an instruction would seem to go against RISC philosophies, where you want your operations to be small and atomic and predictable in terms of time and resource consumption.

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

#84

Post by astrange » Sun, May 06, 2012, 3:09 PM UTC

JoeAltmaier wrote: post #80

parbo wrote: post #64

Earlier quoted context omitted.

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…

Funny - I remember when one of our new Engineers needed a memory-copy method for our ARM embedded solution - he went to Linux source and got some library routine. It faulted when I used it the 1st time. Fixed the bug (alignment of source), ran again and it faulted again. So I spent 10 minutes writing a test - move 0-128 bytes from source buffer offset 0-128 to destination buffer offset 0-128. Simple, overkill right?…

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.

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

#85

Post by kstenerud » Sun, May 06, 2012, 3:29 PM UTC

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…

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 that their hiring practices are also good (so long as you evaluate them before hubris poisons the hiring process, which may or may not happen). After you collect enough data points you'll probably notice a number of similarities.

In the end, the proof is in the pudding. People can opine till they're blue in the face, but if they're not killing it in their chosen market, if people don't really like working there, if someone is about to eat their lunch, then they're doing things wrong, and it would be risky to take advice from them.

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

#86

Post by JoeAltmaier » Sun, May 06, 2012, 3:59 PM UTC

T-hawk wrote: post #83

JoeAltmaier wrote: post #80

Earlier quoted context omitted.

Funny - I remember when one of our new Engineers needed a memory-copy method for our ARM embedded solution - he went to Linux source and got some library routine. It faulted when I used it the 1st time. Fixed the bug (alignment of source), ran again and it faulted again. So I spent 10 minutes writing a test - move 0-128 bytes from source buffer offset 0-128 to destination buffer offset 0-128. Simple, overkill right?…

> why oh why don't CPU designers put a damned memory-copy instruction into the machine? x86 has had REP MOVSB since forever, complete with a directional flag so you can handle the cases where the source and destination regions overlap. But it went out of favor since for a while from 80386 to early Pentium processors (when Linux was written), REP MOVSx was slower than writing an explicit memcopy loop. That said, such…

Right! Foolish programmer! Using REP MOVSB has been broken since about the 2nd issuance of the processor. Dumb folks (read: DOS) used it as a timing loop to calibrate interrupt timers, complained when it got faster and broke their code so Intel 'dumbed it down' til its about the worst way to move memory you could try.

So you say it works again. Cool!

Maybe what we really need is some sort of 'architecture library' that compilers resort to for things like this. Maybe an instruction, maybe a routine, but guaranteed to work for every wrinkle in the architecture.

Because if its not in the compiler, folks will continue to cobble together buggy code of their own, with only a vague idea of the vast architecture landscape they are navigating blindly.

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

#87

Post by velshin » Sun, May 06, 2012, 4:06 PM 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.

Anecdotal, but a few of the best software engineers I've known did not have CS degrees. You certainly do not need one to write a CRUD app in Rails/Django.

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

#88

Post by JoeAltmaier » Sun, May 06, 2012, 4:07 PM UTC

astrange wrote: post #84

JoeAltmaier wrote: post #80

Earlier quoted context omitted.

Funny - I remember when one of our new Engineers needed a memory-copy method for our ARM embedded solution - he went to Linux source and got some library routine. It faulted when I used it the 1st time. Fixed the bug (alignment of source), ran again and it faulted again. So I spent 10 minutes writing a test - move 0-128 bytes from source buffer offset 0-128 to destination buffer offset 0-128. Simple, overkill right?…

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"

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

#89

Post by elemeno » Sun, May 06, 2012, 4:38 PM UTC

exim wrote: post #63

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

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 version ought to be fairly trivial for someone with a solid comp-sci grounding.

Even then, it's not the coded solution that I'm particularly interested in - it's the explanation that follows about how you got to that solution and the discussion about the pros and cons of your particular implementation. I'm looking for signs that you can solve problems and that you can look at your solutions with a critical eye and understand their weaknesses as well.

For what it's worth, the nastiest interview question I've ever had involved building and searching interval trees with up to a billion intervals stored in it where they were looking for solutions which provided the fastest posible search times. It was less than fun.

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

#90

Post by brazzy » Sun, May 06, 2012, 5:49 PM 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…

I'd love to answer that question, so I will:

It was a production bug where a customer's birthday was rejected as invalid. This was in Germany, which is relevant because it turned out to depend on the machine's timezone. You see, when Java parses a date, it computes all fields of a Calendar object and then does a sanity check on them. Some smartass had decided in Java 1.4 to have that reject daylight savings time offsets greater than 1 hour. Unfortunately, Berlin and the Soviet-occupied part of Germany had a 2 hour daylight savings time offset in the summer of 1945, because that corresponded to Moscow time.