Sponsored Link •
Another way to foster an open-ended dialog is to ask the candidate to perform a task: to solve a problem or create a design. Although everyone at the meeting seemed to agree that this was important and useful technique, it also generated a lot of concern. People felt that asking the candidate to solve puzzles and problems needed to be done with care:
Josh Bloch: I like to ask a candidate to solve a small-scale
design problem, finger exercises, to see how they think and what their process is:
"How would you write a function that tells me if its argument is a power of 2?"
I'm not looking for the optimal bit-twiddling solution
((n & -n) ==
n). I'm looking to see if they get the method signature right, if they
think about boundary cases, if their algorithm is reasonable and they can explain
its workings, and if they can improve on their first attempt.
Bruce Eckel: I ask candidates to create an object model of a chicken. This eliminates any problems with uncertainties about the problem domain, because everyone knows what a chicken is. I think it also jars people away from the technical details of a computer. It tests to see if they are capable of thinking about the big picture.
Scott Meyers: I hate anything that asks me to design on the spot. That's asking to demonstrate a skill rarely required on the job in a high-stress environment, where it is difficult for a candidate to accurately prove their abilities. I think it's fundamentally an unfair thing to request of a candidate.
Matt Gerrans: I don't like when I'm asked to write a program that does X on a piece of paper. Don't ask the candidate to write a program on paper. That is a waste of time and sweat. People don't write software on paper, they do it with computers using auto-completion, macros, indexed API documentation, and context-sensitive help. They think about it, refactor it, and even rewrite it. If you want to see a person's work, ask them to write some small module or implement some interface before the interview and bring the code on a notebook PC or on hard copy. Then you can review it and discuss the design, coding style, and decisions that went into it. This will give you a much more realistic and useful assessment of a person's work and style.
Kevlin Henney: I like design dialog questions that don't have a single fixed answer. That way they have to ask me questions, and this sparks a discussion. It's good to have a whiteboard available in the room. A dialog lets the interviewer see how the interviewee works, whereas a question of fact is just that: it is great for TV quiz shows, but doesn't tell you how someone will work and approach things over time. A puzzle question requires knowing a trick, which is in essence something that is either known or unknown. I dislike puzzle questions, because they don't require dialog.
Josh Bloch: What constitutes a reasonable question depends a lot on the candidate's experience and maturity.
Dave Thomas: I look for people with curiosity. Present problems, not puzzles.
Josh Bloch suggested one technique we all seemed to like: Have the candidate bring a code portfolio to the interview. Look at the candidate's code and talk to them about it. Although we were concerned that some candidates may not have code they could legally bring to the interview, we figured most candidates could probably come up with something. It can't hurt at least to ask a candidate to bring to the interview a sample of code they had written in the past.
Josh Bloch: I want to see their code. You get to see what they pick. You learn what they value. You learn how they communicate.
Several people indicated that they ask candidates about the programming books they read to see if a programmer is self-motivated or concerned about improving their own programming skills:
Matt Gerrans: I ask candidates, "What books have you read about programming?" If the book is beyond syntax, that's important.
Randy Stafford: I find out what books they read because it's important to me that they educate themselves of their own volition.