In Michael's comment to When Candidates and Interviewers Disagree About “The Answer” he raised a critically important point: how much does the the candidate know about this issue and how hard will the candidate push to make sure that the interviewer hears his or her side of the issue?
First, let's separate the two issues (I'll bring them back later). Part of the technical interview is asking technical questions. Some of them have one right answer, “What's a linked list?” But most technical answers have a variety of answers, best discussed in the context of the work the candidate has completed. “Give me an example of a time you used a linked list. Where did you have issues in design? In coding? In debugging? After the product was in the field for a few months? A few years?”
That's the easy part of asking technical questions. Now comes the hard part, the second part of the issue. Part of working in a technical group is being able to succeed in the culture of the group. If you work in a group that's constantly challenging each other, you want to know if a candidate can succeed in that culture. So, you can ask questions that see how well a candidate deals with that environment. Part of the way you can determine whether the candidate can fit in the culture is to see how well the candidate answers questions that reflect the way the environment works.
When I'm interviewing for a group that likes a lot of give and take, I make sure that the first couple of people on the interview team ask questions in a way that doesn't require that back and forth — unless I've already explained the group's culture to the candidate. I want to make sure the candidate is comfortable. Then, I'll schedule the technical audition. Assuming the candidate has done well on the technical audition, I'll then ask the next interviewer or two to ask more technical questions, looking for how well the candidate stands up to the interviewer. Here are some examples, especially post audition:
- For a tester: “That's not really a defect.” I'm waiting for the tester to say, “Yes it is and here's why.”
- For a developer: “That design doesn't work.” I want to hear the developer say, “Sure it will, and here's why.”
- For a project manager: “You can't schedule a project that way.” I want to hear “Here's why that schedule will work.”
You see the pattern. Take a piece of the work the candidate has just completed, disagree with it, and see what happens. As the interviewer, you especially want to hear why the candidate believes in that work.
Consider when to ask these questions. If you need testers who can stand up to developers (a common problem), make sure to integrate these kinds of questions into the audition. Don't ask, “How do you advocate for defects?” without also checking the answer to that question with an audition.
Your interview style should reflect your culture, especially if you have an abrasive, challenging culture. Either explain the group's culture to the candidate, or first help the candidate over his or expected nervousness with a couple of “easy” interviews. But certainly, don't scrimp on interviews that test the candidate's mettle, if he or she will deal with that every day. And, don't forget to ask references about how well a candidate advocates for what he or she believes.
For many organizations, whether they are challenging or not, consider using these kinds of questions after an audition. You'll hear more about what the candidate was thinking.
No matter what your culture, make sure you treat the candidate with respect. Even if you have a bunch of arrogant know-it-alls, there's no reason to be rude to candidates.
Michael, thank you for making me think harder about your comment 🙂