When reviewing somebody else’s code, what is it that you usually find most disturbing?
This is a good question. If someone doesn’t review code, you’ll hear that. Jurgen goes on to discuss the syntax answers vs. the design/architecture answers.
He has a point. I would add some more questions, such as:
When was the last time you reviewed someone else’s code? I want to know how recent this experience is
When have you been prohibited from reviewing code? … What were the circumstances?
When did you fight to review code?
Have you ever reviewed unit tests and code? (a closed question to understand the context) What did you do? (a behavior-description question to understand what actions the candidate took or didn’t)
There may be even more questions to learn more about how a candidate is accustomed to working, and how well that experience might fit for you.
I don’t think this is the one and only perfect interview question, even for developers. But it’s a good start.
I have a lot of recruiter contacts, especially through recruitingblogs.com. I’m planning a Q&A series with recruiters, and would like to know from you: what do you want to learn from recruiters? Email me or leave your questions in the comments here.
I ran a workshop recently about hiring for an agile team, and one of the people learning to interview said, “I want a candidate who can take criticism.” I replied, “Don’t you mean feedback?” He asked, “What’s the difference?”
Oh, boy. Plenty. Criticism is when you you’re looking at a piece of code and you say, “This seems brain dead.” But if you say, “I’m confused by this piece of code,” you’ve provided me some feedback. I guarantee you, you want candidates who can take feedback.
So, if you want to know if a candidate can take feedback, here are some possible interview questions:
“Have you recently been in a position where someone reviewed your work?” (wait for a yes answer.) “What happened?”
Offer to work with the candidate in an audition (possibly pairing) and review as you go.
Ask for feedback on some of you work as part of an audition and see how the candidate provides feedback.
“How do you know your work is good?” Wait and see where the question goes. You might be able to follow up with a question such as, “Is there a way you prefer feedback on your work?”
Asking candidates about their ability to take feedback is useful. Asking about criticism is not.
* What specific results are you expecting in the first three months? Six? One year? How will you measure those results?
* To whom can I go for questions as I’m learning my responsibilities? How much time will you have to devote to getting me up to speed?
* Who are the strongest performers on the staff and would they be willing resources to help me with day-to-day questions and processes?
* What are the biggest problems that need resolution within the first six months? What has been done thus far? Who would I have to work with to settle these issues?
* Why have you gone to the outside to fill this position?
* May I meet some of the staff before making my final decision? That way we can make sure it’s a good fit from all perspectives.
If you’re a hiring manager, you need to answer these questions before you start interviewing, so you can answer a candidate. Yes, you need to answer them.
I spoke with a couple of recruiters this week. They’ve been specializing in finding test people for the last 10-15 years. (I used one of them 15 years ago, the last time I was hiring testers.) They both asked a question like this, “With all this Agile stuff, where am I going to find the testers I need?”
Agile breaks the some of the barriers between developers and testers. Both developers and testers need to write code (or scripts). The developers write small internally-facing tests. The testers write small and sometimes larger externally-facing tests. The difference is that the developers write some code that ships. All the testers’ code stays on-site.
If you’re a hiring manager, make sure you train the testers who are interested in writing code and scripts. If you’re a tester, learn to write some scripts, in some programming language, not a test tool’s proprietary scripting language. If you’re a recruiter, have a talk-to-talk with your hiring managers and tell them the testers they want to hire are worth what developers are worth–because they are developers.
You’re interviewing someone for a position at your company. You remember working with that person years ago, and you were unimpressed. Maybe it was the jerk factor, maybe it was the way he didn’t quite finish work, or maybe it was her perfume. Whatever it was, you were not excited about the candidate then, and you would like to avoid working with the candidate in the future. What do you do?
Tell the hiring manager. Explain with examples. “Back 10 years ago, when the candidate and I worked at SmallerCo, I was unimpressed by these things.” (Explain the things. If it’s not finishing, explain what you thought done meant and what the candidate did.) “When you check references, can you please check on this?”
The hiring manager should then ask the references, “Can you give me an example of a time the candidate did a great job finishing something?” and “Can you give me an example of a time the candidate had trouble finishing work?” and “How often do you think the candidate was great at finishing and how often did the candidate have trouble?” (Change this question to be the issue concerning you.)
You should let your manager know about your reservations–that’s the unintentional reference part. But you should make allowances for people having changed over time.
You are allocated a training budget, what is the first course, conference or workshop you would attend?
This is an excellent question to see if people are keeping up with thinking about what they want to learn. I would follow up with “Why?” The one concern I have is that there are some great candidate who’ve been beaten unto thinking they don’t “deserve” training. They might not have an idea. (Even when my management refused me training, I always knew about some course I wanted to take.)