Joel On Interviewing 11: Programming Questions

(Interesting to non-programmers too).

For programming questions, I ask candidates to write a small function in C. About 5 lines of code.

Question 1: Reverse a string in place. Every candidate I've ever interviewed in my life has done this wrong the first time. Most people who think that they know C really do not understand memory or pointers. It's amazing that these people are working as programmers, but they are.

Many "C programmers" just don't know how to make pointer arithmetic work. Now, ordinarily, I wouldn't reject a candidate just because he lacked a particular skill. However, I've discovered that understanding pointers in C is not a skill, it's an aptitude.

In Freshman year CompSci, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their Atari 800s when they were 4 years old. They are having a good ol' time learning Pascal in college, until one day their professor introduces pointers, and suddenly, they don't get it. They just don't understand anything any more.

Ninety per cent of the class goes off and becomes PoliSci majors, then they tell their friends that there weren't enough good looking members of the appropriate sex in their CompSci classes, that's why they switched.

For some reason most people seem to be born without the part of the brain that understands pointers. This is an aptitude thing, not a skill thing – it requires a complex form of doubly-indirected thinking that some people just can't do.
(Note: I am cutting out a very interesting discussion of how he interacts with candidates while they are writing test programs)

Inevitably, you will see a bug in their functions. So we come to question 5: Are you satisfied with that code? You may want to ask, "OK, so where's the bug?" The quintessential Open Ended Question From Hell. All programmers make mistakes, there's nothing wrong with that, they just have to be able to find them.

Very, very rarely, you will find a candidate that doesn't have any bugs the first time. In this case, this question is even more fun. When you say, "There's a bug in that code," he will review his code carefully, and then you get to see if he can be diplomatic yet firm in asserting that the code is perfect.

No comments: