See Three Tips to Streamline Your Hiring, Part 1, Three Tips to Streamline Your Recruiting, Part 2, and Three Tips to Streamline Your Phone Screens, Part 3 to see our story to here.
When my client talked about his interviews for developers, he said, “I interview people on the phone and then ask the candidate to talk to one person. We ask them to write some code that we think is representative of our problem. We don’t care what language they use. They could use psuedo code. But we want them to talk us through what they did.”
Okay, the audition part made sense to me. But talk to just one person? How do you understand what the candidate can do? Remember, this client is having problems finding people who are technically capable. Talking to just one person is not enough. Even their pre-interview test (which I don’t like) is not helping.
We discussed alternatives. I asked him if he was using an interview matrix. Uh oh, no, he was not. But, he didn’t want to waste anyone’s time. I agreed with him.
He could put the audition first. But, if the audition wasn’t working, he had to change the audition. Or, he had to change the questions he was asking. What kinds of questions was he asking?
He looked at me quizzically. “What do you mean? What kinds of questions do I ask?”
“Sure. Tell me a typical question you ask.”
“Uh, I don’t have them memorized.”
I smiled. “Okay, I suspect they are not behavior-description questions. I suspect they are hypothetical questions or leading questions. Those questions allow candidates to wiggle in their answers. Behavior-description questions ground a candidate in reality. They provide you a real answer about a real project or a real situation.”
You should have seen his face. Priceless. I gave him some examples:
- Tell me about a time you had to refactor code in your most recent project. What did you do? (Not everyone thinks of refactoring as something that takes a few hours. Some people think of refactoring as an excuse to rearchitect entire sections of the code base. Some people don’t write tests first, or at all.
- Tell me about a time you encountered a problem on your most recent project. What was it? (Notice how this is very open. I’m not asking about a technical problem or a people problem. Let the candidate tell you what kind of a problem he or she encountered and what happened. Remember, software is a team sport.)
- Tell me about a recent problem you solved that you are proud of.
I have more examples of behavior-description questions in Hiring Geeks That Fit.
Then we spoke about his audition. It was not working for him. The audition was not assessing the behaviors he needed to assess and it was too long. Candidates were spending a long time (an hour) for not enough return.
I pointed him to the resources here in this blog, and in Hiring Geeks That Fit. Do a search of the tag audition here. Look for articles on my main site with the audition tag, too.
- Don’t think you can assess a candidate with just one person. Use at least three people. I like four people for a first-round. Organize these people with an interview matrix.
- Think about the behaviors you want in an audition. Then, design your audition. I have articles about auditions. You can also search on the audition tag for this blog.
- Think about the behavior-description questions you want to use in advance of an interview. Unless you are a practiced interviewer, you might not be able to think of questions on the spur of the moment. You want a number of questions on the tip of your tongue.
By this time, he was full of ideas. We called it a day.
I had transformed his idea of what hiring could be. Stay tuned for Part 5, where I’ll summarize everything and provide you a few more tips.