I spoke at Boston SPIN last night, and facilitated the hiring initiative roundtable before the main presentation. One of the roundtable participants explained that he was looking for entry-level testers. And, since no one (okay, not quite no one, but almost no one) teaches testing in college, he wanted to develop an audition to see if people would like testing. He doesn’t want to hire people as testers who don’t want to be testers.
I suggested he ask candidates to sit down with the product and test. Give the candidates a pencil and paper and blank defect reports. Let the candidate test for 20-30 minutes. At the end, debrief the candidate.Some debriefing questions:
What did you notice about the testing?
Some (or all) of these questions:
What did you find challenging about the testing?
What was easy?
What did you enjoy the most?
What did you enjoy the least?
What issues did your testing raise?
Can you see yourself testing each day? In what circumstances?
These questions follow the The Art of Focused Conversation: objective questions, reflective questions, interpretive questions, and decisional questions.In this case, it’s not the audition that’s tricky to develop, but debriefing the audition. But, especially if you’re considering hiring entry-level people for roles they haven’t considered, debriefing could be a critical part of the audition.
I’ve also applied the Blog Housekeeping changes to this blog. Let me know if you have trouble.
Last week, while driving to/from parents and funerals (my folks are fine), I had several long talks with my sister, who’s looking for a job. She’s the best salesperson I’ve ever met. She’s great at selling, and stays friendly with her clients over the years. She stopped selling in high tech about 16 years ago (sold Tupperware for a long time), and is now looking again for a job selling in high tech.
She’s having a little trouble moving past the gatekeepers. “You don’t have a Business degree.” True, she has a degree in a particular type of business. “You don’t have recent experience selling products just like ours.” Well, of course not. If she’d been working for a competitor, she would have trouble with a non-compete agreement. “You have too much/too little experience.” Can’t win with that one.
My sister’s run into what I’ve called the laundry list job description, although I’m wondering if a better description is a recipe. She’s good at selling, so she’ll determine a way to move past the gatekeepers :-), but I have to wonder about these hiring managers who have such rigid requirements that only people with precisely those requirements will fit.
It is important to be clear on what your requirements are for a given role, and what you can compromise on and what you can’t. But degrees are not something to be rigid about. And depending on the environment, neither is exact product domain expertise. (You need to expect to teach domain expertise to new hires.)People rarely have linear career growth. Instead, they take opportunities as they arise. It’s more important to see that people learn from their opportunities (and deliver what they are supposed to deliver) than it is to see that they meet some number of years of experience.
So think of what you really want to see in a candidate’s experience — what you want and what you need. And remember that candidates are unique individuals. You might have thought about the job one way, but a great candidate might be stellar in another way. Leave the recipes for baking. You’re looking to hire people. You don’t have to compromise on the candidate, but you may well have to compromise on the candidate’s background. Instead of a recipe, look for experience producing or delivering. Then you’ll know you have a good candidate.
I was speaking with a colleague the other day, and he told me about an audition he’s been using for developers for years: asking them to implement a String-Copy function in the language in which they’ll be developing. Some of their reactions are telling:
Some have said, “Why? The language has it?”
Some have worked for 20 minutes, and figured it out.
Some have worked for over one hour and not figure it out.
My colleague’s reply to the “Why?” people is to explain he’s looking for an example of their language skills. Only one person walked out of the interview.
For the people who finish in under an hour, they discuss how this version works. In fact, some candidates realize they have performance problems with their code during the walkthrough, and then want to change it.
Some people freeze, or just can’t figure it out, so for the people who work for an hour but can’t get it — and want to keep working — he says, “Go home, figure it out, and email it to me.”
What my colleague is looking for is simple: does the person know the language well enough to write something that he or she is willing to discuss with something else. It doesn’t have to be perfect and it doesn’t even have to be right. My colleague has to see just a little evidence that the candidate has thought through the problem, has tried to implement something, and has checked his or her work. Brilliant!
Over the years, my colleague has kept the implementations on these pieces of paper, and he was surprised by how many techniques a person could use to implement a String-Copy. (I’m not
For whatever jobs you’re hiring, think about how you’ve asked the candidates to show that they have thought through the problem, tried to implement something, and has checked their work. That’s an audition, and it’s especially good if most people can solve the problem enough to discuss their implementation in about 20-30 minutes. That’s because many people become nervous or resigned if the problem seems overwhelming or impossible.
