Hacker News Reader

Comment by Ugarte | Hacker News Reader

I'd love to talk more about how we can improve on the typical fare of programming and algorithm questions.

I've had to write my own sorting algorithm perhaps twice in the last some-odd years. If you're writing sorting algorithms from scratch, you probably should sit back and consult your standard libraries.

So if I ask a candidate some basic coding question and he can't write a for loop, I know it's a no-hire. But past that basic bar, sifting apart the good candidates from the great ones is actually very hard. Do we continue to ask these questions because we can't do better?

(That's why I ask algorithm questions. I realize they suck, but I just don't have any better ideas. I'm an engineer, not an HR flack.)

So what's a better way to test a programmer candidate?

View on HN

If I'm ever in the position to interview, I'd ask the candidate to teach me something of their choice. (Preferably something in the realm of technology rather than how Magic: The Gathering works, but I'd accept either.) Teaching me things I don't know is better since I'd rather have someone who has a different knowledge base, though teaching me things I do know might help me judge their ability to explain things. (e.g. making reference to an efficient subway system (New York's) when explaining skip lists as done in the MIT video: http://www.youtube.com/watch?v=kBwUoWpeH_Q )

A lot of my interaction between coders is explaining to each other what we've done, I'd prefer someone who might be a worse coder than me but can explain things well (and write good commit messages, etc.) than a guy who writes epic code but can't explain it to me.

A long time ago I TA'd at the CS department at my uni, and this was part of the interview. You needed to choose one topic among several (beforehand, of course), and give a lesson on it. It's a pretty good technique, indeed.

I usually chat with a candidate about past experience or coursework. Sometimes I do a high level problem (no coding on the whiteboard, just chatting), to gauge his skills of looking at a problem.

We also have a programming test. Everybody is subjected to it. In the beginning (when I had to do it :) ), thought it was stupid, but now I find this a valuable tool to aid with the decision (we frequently hire people who did not finish the test). The problems are relatively simple. You get 2 hours alone in a room, a programming language of your choice, and internet connection (so you can search for stuff).

Re: past experience, I agree, but this is harder for college hires. It's not unreasonable for a student to have only taken the standard courses and done nothing especially interesting. I could ask about his job writing PHP or what he thinks of Compilers, but really, there's not a huge amount of depth there.

As for programming tests, I think you're playing into my bias about how everyone thinks the questions are stupid until they pass, at which point the questions become the arbiter of all intelligence and merit. ;) It's that sort of hazing ritual sociology that enshrines questions about moving Mt. Fuji or printing n to the power of 100 in decimal form.

I don't think the algorithmic questions are half as valuable as the questions about which algorithms to actually use use in a given situation.

Even just a simple a question as: "We're doing XYZ. To handle this situation what would you do?" is incredibly telling.

To my mind, being able to apply knowledge is the valuable skill, otherwise it is just trivia that a person knows.

If the candidate is on github, ask them to show you something they're proud of and to explain their technical decisions. I've only experienced this from the perspective of a candidate, but it was almost fun to go over the code with my interviewer. Based on the type of questions he asked, I also realized he someone I wanted to work with.

Reply on news.ycombinator.com