Software developers often take part in the recruiting process. Determining whether a candidate is suitable for a company's dev team is a challenge, to say the least. This is especially true for us - software developers with no HR training and, in most cases, well-constructed sets of rules on which we base our decisions. However, this is not the case with the recruiting process. This process requires us to use general guidelines, our experience and intuition.
At my company, the recruiting process begins with a professional interview where the candidate is asked to code something, design something, and show proficiency regarding the running environment.
Who passes the professional interview stage?
We do not have golden rules, though. After each interview we conduct a short meeting to decide whether or not the candidate is suitable. In all of our interviews, we ask similar questions that help us more closely compare candidates. We interview in pairs and each interviewer can veto. We believe our general impression has the most weight on our decision.
How hard it is to make a decision?
Well, as Joel Spolsky once wrote, there are three kind of candidates. The ones you know you want, the ones you know you don't want, and the "maybes." Most of the effort is invested in the latter.
Lately, we realized the Maybes that we eventually hire have a certain characteristi: The ability of the candidate to evaluate his own answers. When asked a question, he knows what information is missing in order to answer it well. He will then state both what he knows and what is missing. If he has been asked to solve a problem, he will be able to state the aspects of the problem helped by his solution, and then he'll ask for more information to provide a complete solution.
Candidates who do not have said characteristics behave differently. They write code that doesn't work and algorithms that do not do what they should. The problem with these candidates is that we had to tell them their solution doesn't work. They supply shallow, inaccurate, incomplete answers while they think they're right.
So the ability of a candidate to evaluate his or her own answers is extremely important for software developers. As developers, almost every task requires finding missing information in order to complete a task successfully. Developers without this ability evaluate missing information by coding too early and producing inaccurate work.
Given this discovery, we've began implementing these methods in interviews:
- Ask the candidate the information he or she is missing to answer the question. This is good for knowledge questions.
- Ask a very hard question that the candidate cannot answer easily, if at all. We then see if he shows us his way of thinking instead of making up a bad answer off the top of his head.
- Guesstimate questions.
- Ask the candidate to design something with little information. It's good if he asks for the pieces he needs to complete the design.
Perhaps you will, too.