Interviewing With Code

I'm in the process of recruiting a junior to medium level programmer. We don't have the time or resources for pair programming on a first interview, so part of my process is to show them some of the reasonably unpleasant code we've inherited and ask them how they might improve it. The example method contains a large switch statement in which each case contains near-identical code. We saw about 7 candidates (many with good degrees from fine institutions) of whom some had absolutely nothing to say, some fiddled with peripheral issues, and some only noticed the duplication after a certain amount of prompting. I was beginning to wonder if there is something wrong with me. Am I just too picky? Do you have to spend more time with the code to pick this sort of thing up? etc.

Until today! We finally had a candidate who looked at the 4 pages of method, thought for about 10 seconds and said, oh, you could move all this stuff into another method and call it. I don't know if we'll get to hire him, but maybe there is a coding God after all.

Is this measurable evidence of the reputed order of magnitude difference in the quality of programmers?

You're looking for someone with experience doing maintenance. Most recent college graduates have written new programs in a "green field" environment, but don't understand maintenance. -- JeffGrigg

Not in our case, we've interviewed people aged from 25 to 41 who've done all sorts of jobs. This one was one of the most junior. I've always done this kind of refactoring, just perverted I guess. The only other differentiator was that his course included a lot of formal methods. Maybe the experience had taught him to be parsimonious with functionality?

There may be a sort of HawthorneEffect going on here. Most people aren't at their best under the pressure and stress of a formal interview. Maybe the candidates didn't want to insult your code? Did you create an environment conducive to criticism? -- MichaelLeach

That is certainly a risk and, given the trouble we were having, I was beginning to wonder. The point of the exercise, however, was that we told them that we didn't like this code and wanted to improve it. We told them that any improvement would do, we weren't looking for one right answer. We gave hints to everyone who was stuck and the main problem with the method should be pretty obvious. I think the whole exercise reflects more on the state of our industry than anything. (n.b. people did better under the HawthorneEffect, but I know what you mean).

"We finally had a candidate who looked at the 4 pages of method, thought about 10 seconds and said, oh, you could move all this stuff into another method and call it."

Perhaps you chanced upon someone who read MartinFowler's RefactoringImprovingTheDesignOfExistingCode.

Then that made him a better candidate...

Just today, I interviewed a programmer for a small job (migrating a database to Access, and designing reports) and he claimed that he wrote BASIC when he was 10. He started to brag how 'efficient his code was' . I suggested that now that computer processing power is cheap, it's more important that code be readable. He readily agreed and then regaled me with a story about how his father still writes SpaghettiCode because it's job security. I quipped: "Fortunately, we're not hiring your father".

Since the job is so small, we're going to base further employment on this pilot project. If I can't understand his code at the end of the project, we won't use him again.

-- SeanOleary

See InterviewingWithCodeSamples (refactored 9/8/01 SteveHowell)

Diversity of Experience

I believe that if you are looking for a good programmer, you should look for talent and new ideas. If you are specifically looking for a subordinate to whom you will dictate the rhyme and rhetoric of writing software, then what they consider to be good code is fairly irrelevant. If, however, you want them to write good code, perhaps you should be looking for someone that makes you think "wow, that's a good idea" or "I didn't think of that" instead of "ok here's someone that thinks closely enough to me to make a good programmer". I've seen a lot of software development teams whose efforts are mired solely because they all bring the same experience and similar ideas to the drawing board. --JacobCohen

There is clearly a risk of generating a monoculture but, again, if you believe a fraction of what's been written on this site, the test code was blatantly in need of improvement. I want to work with people who can make abstractions and who care about the quality of their code. I also want someone who's going to make intellegent challenges to what they see in front of them. And don't forget, this was only the first round -- just to see if they were competent enough to continue with.

See ImageRotationCodeInterview for a good example of the back-and-forth that can go in with a code interview. Basically, a good interview questions starts a good dialog, where you see not only how clever a coder is, but you see humor and pragmatism. Remember, too, that the candidate can learn a lot about an interviewer during a code interview.

See WhatsWrongWithThisCode for another example interview question. [refactored 9/8/01]

See: HiringPatterns, InterviewingStrategy