The boom of the 90’s attracted many moderately talented gold diggers to becoming software engineers. Consequently, after the bust, the IT labor market today is flooded with people who have no concept of engineering techniques and quality of design. At the same time in corporate-land, the software-development-as-a-commodity mindset has created a similar situation at a global scale, and the practices of staffing firms have severely aggravated the situation. In short, good software engineers, and even people with the potential of becoming good software engineers, are difficult to spot among the masses. A hiring manager who wants to find a reasonably intelligent person with the ability to think and code at the same time has to go through a lot of effort in order to find suitable interview candidates. Working with recruiting firms is particularily straining, because the hit rate is low, interviewing is very time consuming, and communication with the staffing firm requires a lot of effort explaining to the recruiter that a good software engineer needs more than just a list of hot skills and a few projects on the résumé. In my experience, this communication most of the time yields no results, because …
… a recruiter maximizes his profit when you hire the least talented person in his portfolio. The recruiter’s margin is better at the lower end of the spectrum. There is clearly a conflict of interest that works against everybody else: employment-seeking talent who, directly or indirectly, has to compete against hoardes of inept off-shore developers, hiring managers who need to do the screening and end up hiring underperformers out of desperation, just to get out of this vicious circle, and IT organizations around the country who have to deal with unusable code produced by the recent hires.
This situation requires new interview strategies. Managers need to determine quickly in a phone conversation whether a candidate deserves any attention at all. Behavioral Interviews are passé, because broad, open-ended questions don’t work well on the phone, and because they give the candidate too many opportunities to change the subject and to drag the conversation out without giving the interviewer enough insight to make a decision.
The answer to this challenge is what I call “Problem-Centered Interviewing”. The objective of this technique is to draw the candidate into a guided conversation about a particular technical problem that he or she can be expected to have knowledge about, based on claims made in the résumé.
[In social research] the problem-centered interview (PZI) is a theory-generating method that tries to neutralize the alleged contradiction between being directed by theory or being open-minded so that the interplay of inductive and deductive thinking contributes to increasing the user’s knowledge. The appropriate communication strategies aim firstly at the representation of the subjective approach to the problem, secondly the stimulated narratives are enriched by dialogues employing imaginative and semi-structured prompts. Theoretical knowledge develops by using elastic concepts that are further developed during the analysis by employing empirical analysis and which will be refined by “testing” empirically grounded “hypotheses” with the data. (Witzel, Forum Qualitative Social Research)
By exposing the candidate to a problem situation that allows for a wide range of solution approaches, the candidate can have a relaxed conversation and does not realize that he or she is in fact being tested. For instance, if the résumé claimes HTML and DHTML knowledge, I like to talk about the design choice of tables vs. style sheets to achieve a certain page layout. If the candidate has an opinion and can have a meaningful discussion, the interview will continue. If he or she does not know what I am talking about, the interview is over.
Other problem questions evolve around web services, SQL query performance, Java exception handling, the HTTP protocol, etc. Any topic works, as long as the interviewer has subject matter expertise and can keep the conversation flowing by asking controversial questions. This technique is so effective, because it requires little preparation while quickly unveiling any weaknesses in areas such as the abilities to listen, understanding key technical issues, and applying correct solutions to standard design problems.