Interviews Can Be a Terrible Way to Identify Good Programmers

Best bug I helped find was a flaw in some FPGA code for a special DAQ board for a muon detector I was building. When the board was in a temperature above about 74F, the FPGA would often (but not always) fail to initiate some ADCs correctly because some delays would cause part of the circuit to go out of sync, and when it was below, it always worked fine. So, testing in the office worked fine, but running the board outside wit a slightly different setup in the summer would mean a failure, but not always.

The horrible part was after all this, I had to wire up a bunch of NIM modules instead with all the special logic (coincidence/anti-coincidence triggers + a bunch of other stuff so I could have separate binned energy counters) and then calibration manually because the engineer for that board was busy with other things to fix the bug.

I would have loved to tell this story at an interview for a job, except I could almost never get past HR drones, probably because my degree said physics and not CS or EE.

Yes. Several people use it.

I don't remember specific bugs in general. I think I try to block out the memories...

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 company's culture is entirely sufficient.

Most of the startups we talk about depend on good execution of a simple idea, not advanced technical skills[1]. I believe that a good leader with the right vision and the ability to articulate that to his or her employees can take smart people who fit well with the company and form them into people who will execute consistently well. Not only that, but this creates a belief system around engineering and product that is compounding and self-reinforcing.

Identifying technically competent people is not that difficult. If you were to read a few of the last 200 articles where we've talked about this, there are some common threads.

First this, always this: a) Have them write at least a little bit of code to see that they actually know how.

Then pick a few of these. If at all possible spread the interviews out amongst a group of people so you can get different viewpoints. a) Ask them some relevant programming questions and observe their answers. Focus on things related to the kinds of work they'll be doing in their job. Maybe work on a whiteboard, or even in a text editor. Maybe even a little bit of both. b) Ask them a broader set of questions relevant to things like algorithms and data structures. Even for simple web apps, it helps to be at least conversant in the basics of these topics. c) Ask them to see open source work, or if they have a profile, or maybe some code they wrote that they're comfortable sharing with you.

I really think that if you put someone in a room with a competent engineer for an hour, that engineer will be able to tell if the person they've been speaking to is a good engineer or not.

Agreed. Memory tends to be trigger-based for most of us mortals.

Even short-term, here's what I've noticed: I could verbally list seven terms and their definitions. If I then proceeded to ask you the definition of any one of those terms, you could probably tell me. But if I asked you to recite back to me all seven terms, you'd probably forget at least one or two.