Programming Interviews

This is a popular subject at the moment. Hacker News covers this in multiple links and comments, of which these are just a few:

• "Interview Programming Problems Done Right" http://news.ycombinator.com/item?id=3431107 
• "Why 37signals Doesn't Hire Programmers Based on Brainteasers" http://news.ycombinator.com/item?id=3428984
• "Interview Programming Problems Done Right" http://news.ycombinator.com/item?id=3431107

I'll shy away from exact examples as it would reveal my interview technique (on the extreme off-chance that a potential candidate knew I was going to interview them).

Anyway, there's a lot of crap being said, for example:

• Whiteboard programming is going to favor people good on a whiteboard.
• You should be looking at sample work and not programming under pressure.
• Programming puzzles are a poor signal for good engineering.

All fair points, but things aren't so black and white. My stance is this:

• Whiteboards suck, but be honest: writing a 3-10 line program on one isn't that difficult.
• Sample work does not show the working. The thought process is important to see.
• Ask problems. Don't ask puzzles. Every day programming is problem solving, not code golf.

I never ask puzzles. Every question I ask is something I've actually had to use at some point in my career. I don't ask questions from a book on algorithms, or that would require a book on algorithms. I don't ask questions that require anything more than basic mathematics - if any. I certainly don't ask questions that are Computer Science. You're not being interviewed for a CS course. This is real world stuff.

In fact, by Google standards (see bio), they would have been shockingly trivial - even banned - questions. Even if you're Google (which I'm not any more), 99.97% of your employees are not writing the core search algorithm. Why the hell would you ask questions as if you were? (Aside - I believe this leaning towards CS-style code puzzles directly results in a heavy leaning towards selecting CS-style employees, and explains a lot of Google's issues with shipping real world quality products at the moment)

The heart of the matter is this: don't ask questions you never expect a candidate to ever encounter in their work. Interview them for the job they're being offered.

And then - because a whiteboard exercise can never tell you everything - I ask about everything of interest on your resume. It better be accurate, and I will find out if you're taking personal credit for what are group achievements.

So there's nothing I've said above which would help you prepare for an interview with me, other than a) learning to code, and b) ensuring your resume is accurate :) That's the idea - if the only preparation you can do is essentially to be a better programmer, then I'm fairly confident I'm asking the right questions.

Estimation

One of the most important skills for an engineer is the ability to estimate. This is the realization that a lot of calculations don't require an exact answer. They only require you to have a feel for scale. For example, if asked "How fast can we calculate this answer?", it's not uncommon for the answer to be any of: "a few microseconds", "a couple of hours", "months", "longer than our lifetime", or even "longer than the heat death of the universe". Such is life in computing.

It's a common complaint that people rely on calculators too much to perform arithmetic for them. I don't think this is actually a problem - calculators enable people to focus on the underlying questions without bogging down in the numbers themselves. I think it's only a problem when people turn to a calculator first instead of estimating.

In computer science, there is a formal way of talking about estimates, called "big O notation". This is something I end up asking in interviews, even though I hate to do it. Why do I hate it? Because it's something you're either taught formally (you did a CS degree) or you've never heard of before. Because it's one of those stupid Google interview style questions that employers love to ask but will never actually turn up in your actual job role. In any case, I expect every proficient programmer to have an intuition about it, regardless of what you call it or how you write it. It demonstrates that you have a feel for how the code you write actually gets executed.

So I'm sadly commonly surprised when candidates can't tell me how fast they expect this to be:

for (int i = 0; i < N; ++i)

  for (int j = 0; j < N; ++j)

    total *= array[j][i];

I suspect even many non-engineers reading that can tell me the answer, if I tell them it's multiplying together every number in a two dimensional grid of size NxN. Surprisingly, many will answer "Oh it's just O(N)". This is often from the mouths of engineers with over a decade of experience. How do you manage to get by so long without knowing this? Actually, it's usually obvious - they're the people who have been churning out all that slow, memory hogging software you've been cursing for the last decade.

So next time you're reaching for your calculator to work out how many basket balls will fit in a gymnasium, instead just try to work out how many zeroes are involved. It's not like you're ever going to actually order an exact number of them to do it.