Hey everyone! I’m back to talk more about building a diverse development team. Today we’re going to talk about job descriptions. As mentioned in the disclaimer in part 1, I’m generally speaking from a woman’s perspective because that’s the group I belong to. You should totally talk to people from other groups to find out what they think and feel about this topic. Also, I’m not speaking for all women – a lot of this is anecdata based on personal experiences and conversations with other women programmers I know. I’m going to write in some sweeping generalizations about things that stick out to me, but I recognize I don’t speak for everyone and I’m not covering everything. Now that we’ve got that all out of the way, let’s talk about job postings.
A job posting might be the first thing a potential job candidate sees about your company. A lot of the job descriptions we see don’t seem to be written for us, so we question if we should even apply – if your company will be a good fit for us. If you really wanted us to come work for you, you’d write a job description that appealed to us, right?
Most of us don’t want to be ninjas, rockstars, or some other random profession unrelated to coding. <aside>My one exception is that I would totally apply somewhere that says they are looking for scientists. I would rock my lab coat every day, and some studies indicate it might even make me better at my job.</aside> We want to work hard at being awesome software developers, not on our egos. We also aren’t generally fond of working with people more concerned with their egos than their code quality – using this type of language could indicate that your team is full of these people. Try focusing on listing actual traits that you think make an awesome/ninja/rockstar/pirate/robot programmer. It will come off as more professional and let us know what you actually care about.
Stop trying to offer us beer during work hours – if you’re paying us right we can buy our own beer when we go home to spend time with our friends and family. Indicate you want to give us that time to spend with our friends and family. One of the things that matters most to us is respect for work-life balance. We will work hard and smart for you. We get shit done. Don’t try to burn us out. Give us time to go home and relax, so that we can keep getting shit done for you. Indicate that you want to do this in your job description instead of offering us alcoholic beverages hoping we’re going to keep riding the Ballmer Peak until we burn out and go work elsewhere.
Consider telecommuting and remote employees. A lot of us aren’t interested in moving or have life situations that are better served by telecommuting. Having trouble finding people with the skills you need in your area? You significantly increase the pool of people available to you by making these features of working with your company. If you’re willing to do this, make sure it’s included in the job description.
Don’t make Github and OSS contribution sound like a critical part of the hiring process. Statistics show women are less involved in open source and a lot of us don’t have time to code in great amounts outside of work (remember that work-life balance thing I mentioned earlier). Try focusing on more general expectations around proving our skills and talking about past projects.
If you currently have a homogenous team, it’s not a great idea to push the “cultural fit” thing a lot in your job description. This can read as “We’re very happy with the status quo, thank you! No diversity needed here.” Instead, focus on specific parts of your culture that you think are appealing to a variety of candidates.
In general, avoid language that’s going to focus too much on a specific group (be it gender, age, or something else). If you’re not sure if you’re doing this, ask people (ideally diverse groups of people). Alternatively, do some research – it’s totally out there.
To continue that last point, do some actual research on this topic. The Anita Borg Institute, the National Center for Women & Information Technology, and many other organizations have some great research and feedback in these areas. Below are two example documents with some information. I strongly encourage you to go digging to find more on your own.