NSLog();

Eric-with-a-C has some commentary on my previous article on interviewing programmers. I also had a conversation with Jeff after I posted my article. I want to refine my point of view.

I'm not going to re-read my previous post - I don't want to taint what I have to say today - so if I've changed my mind, fine. If I'm clarifying a previous point, also fine. That's why I linked to it, and why it has a TrackBack to this article.

I still feel that programmers should not be asked to write code on paper. Give them something that allows them to move things around, even if it's just a text editor incapable of compiling anything. Cut, copy, paste are essential editing tools. They allow you to write pseudo-code, then replace it (or comment it) and fill in the "real" code.

Put another way: you're tampering with someone's ability to code by saying "on paper." That's not how a programmer - a creative scientist - has been trained to work. It's not how they are comfortable, and it certainly isn't how they're going to be working if you hire them. Yes, developing a project's general object map or whatnot can be done on paper, but not actual code.

Adding the "on paper" requirement changes the entire game. Programmers are then forced to worry about things like "how much space do I leave for this block of code?" and "I guess I should use a pencil so I can erase" (I don't like pencils myself). During my "on paper" exam I spent about 25-50% of my time trying to memorize pseudocode instead of writing it. I was too busy worrying about other things brought on by two simple words: "on paper." Give me SimpleText, at least! Programmers never have to worry about how much room to leave for a block of code. If I'm writing code, sometimes I'll write "return 1; // finish this later" and then fill in the rest of the code later. Requiring "on paper" changes how someone writes code.

To illustrate my point further, let me try to give an example. Imagine asking a football team to play on a hockey rink. Could they? Sure. Will they demonstrate their skills or will they spend half their time worrying about slipping? Or asking an artist to paint on a rock instead of on a canvas: true artists would spend a massive amount of time trying to figure out how the new texture would affect what they wanted to create. Perhaps a better example is asking a football team to play rubgy. They're similar, but the football team will be too concerned with the new rules and what they can and can't do to actually play at the level they could play if they were asked to do what they should be asked to do: play football.

Yes, asking someone to write code can quickly weed out the bad programmers. But asking someone to write code in SimpleText - any text editor on a computer (with a keyboard - I type much faster than I can write) - is going to give you the same results without flustering candidates, without leading to simple mistakes, and while giving you a truer indication of how someone programs. You can then observe "do they write pseudocode first?" without having to guess "are they not writing pseudocode because I've changed the entire process on them and they're worried about space, erasing, speed, etc.?"

Eric also points out that it's a bad idea to allow people to bring their own code to the interview. It may not be their code, after all, and they can study up on it to perfect their answers.

While that may be true, I don't recall saying that this should be the only time you look at or discuss code. Ideally, the "code" section of an interview - in my opinion - would consist of three parts:

• New Code
• Your Code
• Our Code

New Code would be written in SimpleText or some such text editor - not paper. Your Code would be code the interviewee has written in the past. Our Code would be code supplied by the interviewer. In each of the cases, the interviewer and the interviewee would discuss the code. What's good about it? What's bad about it? What would you have done differently? If they have perfect answers for "Your Code" but are completely flustered by "Our Code" and "New Code" then the interview is done. But if they show thought, and can enter into a discussion on code they're just now seeing, then you've found yourselves a candidate at least worthy of being at the interview.

It's very difficult to fire people. It's often better to have 10 adequate developers than 2 superstars, 6 adequate developers, and 2 horrible ones. I understand the need to weed out the bad ones. Unfortunately, two words can quickly drop a superstar to merely being adequate, and could actually elevate others. "On paper" changes the game, and quite simply, it's not the game you're hiring someone to play.

Comments RSS