I saw this gem of advice: ask for a candidate to explain his/her most significant accomplishment when sending a resume. (Found on Recruiting.com.) This is a great screening device (better than technical tests, in my opinion).
Candidates, this means you need to be thinking about your significant accomplishments (work-related please, unless you can make a real case for a non-work related accomplishment) and be able to write about them.
Hiring managers, you can use this as a screening device. If a candidate doesn’t include a paragraph, you don’t have to read the resume. Make sure your resume intake system allows you to grab the paragraph as well as the resume.
Last week, at the AYE Conference, I led a workshop called “Conversations with Candidates.” One of the participants wanted to know, “How do I build off a behavior-description question?” I’ve always led the conversations intuitively, so I had to think for a minute to describe what I do. If the next questions doesn’t just come to mind, I use the ORID technique from Art of Focused Conversations
Here’s what ORID means:
O: Objective. Ask a question that deals with sensory input: What did you notice? What stood out for you?
R: Reflective. Ask for interpretations based on reflections: What was challenging for you? What was easy? Where were you surprised?
I: Insights. What insights do you have? What did you learn from that experience?
D: Decisions. What might you do differently the next time?
Here’s how this might play out in an interview. Let’s assume you’re asking about a person’s ability to solve problems. You might ask these questions:
Have you been on a project with problems before? (closed question to establish a context)
Tell me about it. (Behavior description question.)
What did you notice most about that project (or the problem)? (The O question.)
Did anything surprise you? or What was particulrly challenging? What was particularly easy? or What was fun? What was drudgery? (the R question.)
What did you learn from that project? (The I question.)
Have you taken those learnings and applied them to another project? (D question, with a behavior-description slant) or What will you do differently on your next project? (D question, hypothetical.)
There are tons of ways to use these questions in an interview. Put them in your toolbox and see where they lead.
Recently, a manager asked how he could detect critical thinking skills in candidates. I had to ask him more questions, so I could answer. Here’s what he meant by critical thinking skills:
The ability to think through a problem in a certain architectural domain
The ability to deal with people across the organization in planning the next set of features and projects
The ability to mentor others, choosing paths that would fit less-seasoned staff
The ability to discuss product strategy with people across the organization.
Those answers weren’t what I expected when said “critical thinking skills.” But they are. (I walked him through a partial job analysis until he could explain what he wanted.) And now, we were ready to develop some questions.
Here are some of the questions I suggested he consider and adapt:
For the architectural problem thinking: “When was the last time you worked on this kind of architecture? … How did you decide what to change? How did you change it?”
For the cross-functional planning: “What was your role the most recent time your organization planned what to do when? … How did that work?”
For mentoring: “When did you last take on a mentoring role? … What did you do?”
Product strategy: “Has there been a time when you didn’t agree with the product strategy? … What did you do? … Has there been a time when others had to be persuaded to your strategy? … What did you do?”
These questions all start with closed questions to establish the candidate has done something like this, and then move onto behavior description questions to hear the story of the candidate has worked.When the manager asked me about critical thinking skills, I thought he was going to talk about test creativity or debugging/development creativity. Without a quick job analysis, we would never have been speaking the same language. And, without analyzing what he really wanted, he would never have asked or adapted these questions for his candidates.
It’s ok to say “critical thinking skills” as a shortcut when you’re initially thinking about a job. But the context of those skills will help you define questions that will elicit what a candidate has done and how relevant that work is to you.
I taught a bunch of classes this week at the Software Development conference. At one interviewing class, a participant wanted to know, “How do I hear the other half of the conversation?” I asked for clarification, and he said, “Sometimes I feel as if the candidate has only said part of the answer, and if I knew how to ask other questions, I would gather more information about candidates.”
Meta questions, such as “What else should I be asking you?” or “What else should I know about?” or “What haven’t I asked you yet?” are a great technique to elicit the other half of the conversation. You may hear surprising information.
I was a contract VP in an organization, interviewing for my replacement. I interviewed one candidate, asking “What else should I know about?” He said, “I don’t like to work with women.” I picked my jaw up and said, “Oh? Tell me more.” He went on and on about how women were so emotional and couldn’t make good decisions, and more nonsense. I thanked him for his time and walked him to the door.
Meta questions might not show such egregious behavior, but they will show you another side of a candidate. Which is almost always a Very Good Thing.
I had a discussion with a hiring manager at the Better Software conference this week. He claimed he could tell what candidates were thinking from their facial expressions.I asked him what I was thinking. He said, “You look pleasant, smiling, as if you’re agreeing with me.” I laughed out loud and said, “Nothing could be further from the truth.” We talked about how some people have control over their expressions and that body language or facial expressions are not good indications of what’s going on inside.
If my husband of over 20 years can’t tell what I’m thinking (and poor guy–he can’t :-), how can anyone else tell? Let’s leave the clairvoyance to the so-called psychics. In interviews, let’s ask great behavior-description questions and ask candidates to perform auditions, and evaluate people based on data, not what we think the candidate is thinking or saying.
Here’s the message I’m seeing loud and clear: It’s worth a few minutes to perform a little research on the name of the person you’ve just discovered via the web. If you’re a hiring manager and you’re hiring a contract recruiter, interview the recruiter. Ask questions such as, “Give me an example of someone you found via the web. How did you find that person? How did you make contact? What intrigued you about the candidate?” Try using questions like these to discriminate among recruiters who say they know how to use the web to uncover candidates and those who actually do know.
Software development is difficult in the best of conditions. You should always be failing some of the time, and learning from those failures in an honest way. Otherwise, you’re cheating yourself out of the best professional development opportunities.
I don’t want to hire people who don’t know how to learn from their mistakes — they’re doomed to repeat them. And if I’m willing to coach a potential hire, I don’t want to restrict my search to only people who already know how to learn. They probably don’t know all the ways they don’t learn
But I do want people who are willing to take feedback in a variety of forms. So, what mistakes have you made? What have you learned from them?
State, Strategy, Bridge, and Adapter are all similar patterns. How are they similar, and how are they different?
But I suspect I was surprised because I’m no longer a developer and am not familiar with the patterns. I suspect I would keep a paper copy of the patterns and ask a candidate to read them first if the candidate was unfamiliar with the patterns. I don’t want to make a test out of attempting to remember the pattern; I want to hear the candidate’s perspective on the patterns.I loved the second question:
What makes good, maintainable code?
What an opportunity to ask followup questions such as “When have you not written maintainable code? Why?”I like meta questions, such as the third one:
What questions should we be asking you?
I’m not sure I would ask every candidate how to improve the interview, but meta questions are more illuminating (for me) than hypothetical questions if I want to understand how the candidate thinks.
Please think about your most significant accomplishment. Now, could you tell me all about it?
That’s a great stepping off question. And, I really like the second question, in one of the comments on Anthony’s post, by Jim Durbin
Tell me about the last big mistake you made and what you did to correct it.
Candidates, be prepared for these questions. Hiring managers and teams: consider these next two questions for your next interview. These questions are illuminating.
Here’s what ORID means: