Communications of the ACM
Is It Time to Change How Software Developers Are Hired?
I was recently reading an online blip from Computerworld, based on a Q&A with Chad Lilly, the Director of Recruiting at Lextech Global Services. Lilly's comments covered how to best evaluate candidates for software development positions, how to choose between multiple candidates. In some ways the article makes total sense. You have to determine how a developer will work in your particular environment. What's the best way to do this? As is probably the hiring norm, Lilly says that you should have each candidate meet with the team. Suggested methods are taking a candidate out to lunch with "key members of the software group." Have candidates talk about their hobbies so that you can "understand more about the candidates as people" and so that you can see if they "explain things clearly and succinctly."
Certainly you do want to get a sense during the hiring process if a candidate will work well with the current members of the development group. At the same time, I feel compelled to ask whether the typical approach to evaluating job candidates reinforces the current gender make-up of much of the computing industry. While I was reading the Computerworld piece I began to think about an issue we face in the classroom, while at the same time wondering if it isn't time that we overhaul standard hiring practices.
Many of us teaching CS grapple with the issue of how to recruit and retain women. We often end up with classes or labs which have a very small number of women. In those situations there is always the question of what to do during group activities. Should we let students self-select their groups? Should we form the groups for them? Is it better to disperse the women, one at a time, across a number of groups? Or should we form women-only groups? There are arguments to be made for and against each of these practices. For example, there is the argument that women's voices are more likely to be heard and they have a greater chance to contribute if they are in women-only groups. But there is also the argument that diversity should be "spread around" because students benefit by being exposed to diverse problem solving approaches and styles.
So, let's consider the software development group hiring new people. You bring in candidates one at a time. There is lunch with the candidate, questions about hobbies. Imagine you are the woman candidate interviewing with an all male group. Or you are in some other way the "other" to the group's dominant characteristics. The conversation about hobbies could be completely stilted. And why do hobbies matter anyway? Such a discussion could bias the hiring against anyone who has hobbies that are outside the norm for people already in the group (thanks to Amber Settle for this insight). Surely there are better ways to determine whether someone can "explain things clearly and succinctly."
We can make lots of arguments why it would be good to diversify software development groups. Research shows (Phillips, Liljenquist, and Neale, Personality and Social Psychology Bulletin, March, 2009) that diverse groups have benefits: better decision making, reduction in "group think," and increased group effectiveness. Research also shows (Woolley and Malone, Harvard Business Review, June, 2011) that adding women to a group increases the "collective intelligence" of the group. But how do we do it, how do we get homogeneous developer groups to diversify?
Perhaps it is time to consider alternatives to the standard structure of interviews. One possibility is that for some part of the interview day candidates are considered in groups, not singly. Re-imagine the candidate lunch, except that instead of 6 developers and 1 candidate there are 6 developers and 6 candidates. The candidates are a mixed group and nobody is completely a singleton. The group has to be diverse enough that any characteristic that is "other" when compared to the development group (gender, race, ethnicity) is shared among a number of the candidates. This kind of situation could be an equalizer in that everyone in the room is faced with a significant number of people he or she does not yet know, reducing the ability of the existing employees to completely control the conversation and social interaction. It could make it considerably easier to learn a lot about how the candidates could potentially contribute to the group dynamics. On the other hand, this kind of setting could create a weird air of competition among the candidates, and could work to the disadvantage of anyone who tends not to speak up in groups, who is uncomfortable drawing attention to himself or herself. We are faced with a quintessential chicken and egg problem — it is hard to fairly interview people who differ from the norm until we have so many employees like that already that the candidate no longer seems different. Surely there are enough smart minds in software development (and in HR) that we can come up with a new approach to interviewing that we can solve this problem!
No entries found