4 Comments

Writing a Gender-Neutral Job Description for Developers

Jeanette and Matt pair programming

As our CEO Carl Erickson wrote last week, we’re trying to build a more diverse team, focusing first on gender diversity.

I was asked to look at how we market our job openings and find ways to reach more female candidates. One of the first things I discovered was the idea that job descriptions themselves can be oriented toward one gender and discourage members of another.


This post is the second in a series about addressing unconscious bias and making Atomic a more rewarding place for everyone to work.

 

Job Descriptions that Alienate Women

Getting people to look at your job opening is pretty easy if you spend a little money. In the past year, we’ve listed jobs or advertised openings on LinkedIn, Facebook, Twitter, Stack Overflow, Ann Arbor Spark, Hacker News, and our own blog and website.

But getting people to apply for a job? That’s more difficult. People don’t want to waste time applying for jobs they won’t like (or likely won’t get).

The thing is, men and women (on average) tend to have different perspectives and ways of communicating—that’s one reason diversity is so important. And a lot of job descriptions are unintentionally discouraging women from applying. How?

  • They list things as “requirements” even though the company would be willing to forego them for the right candidate. (Women are far more likely to pass on jobs if they don’t believe they’re fully qualified; it’s part of the confidence gap between men and women.)
  • They use superlative terms (expert, high-powered) or other words that appeal more to men than they do to women (competitive, ambitious, outspoken, confident).
  • They fail to clearly describe what the job will be like and what benefits it includes.
  • They use macho language (like “coding ninja” or “development rockstar”) that implies a competitive “bro” culture.

See the end of this post for some of our sources.

Our Starting Point

Atomic’s pre-2015 developer job description had a lot of room for improvement. It had a “we’re looking for the best” attitude, with phrases like:

“Software development at Atomic is a dynamic and challenging job. We are experts at becoming experts in new technologies and business domains.”

The requirements were vague, daunting, and included things the candidates were expected to grow into over time:

“We’re much more interested to know that you learn quickly, are disciplined in your work, and have already… become proficient in a variety of languages and tools. We look for people who… program in their free time, who are continually uncovering new things and enjoy sharing them.”


“You’ll need to become comfortable and effective at understanding and discussing business goals, budgets and timelines with clients. Additionally, you’ll help market our services…presenting at conferences, contributing to our shared company blog, networking within our client’s organizations and among your peers, and expending your creative energies in ways we will not attempt to predict.”

It didn’t describe what the job actually entailed, and it said nothing about employee benefits.

Atomic Object's diverse office

Identifying our Required “Requirements”

We started by formally codifying our job requirements. This was especially important for Atomic, because all employees participate in our full-day job interviews.

We devalued a few things we used to rely on, such as “writes code in their spare time” and “contributes to open source projects.” These can indicate a passion for development, but they require a lot of free time, so they favor people who are wealthier and/or don’t have children.

We also thought about the non-technical skills we need, since all of our developers are also consultants. We’ve always said, “You have to fit our culture,” but we wanted to directly apply our values to this job.

Bearing that in mind, we created a list of must-haves—things we need to see before we hire someone:

Technical Requirements

  • Familiarity with several programming languages and in-depth experience in at least one
  • A degree in Computer Science or a related field, or professional industry experience (Many developers don’t need this, but Atoms do. All Atomic developers do complex work across many platforms and languages, so they need a strong grasp of computer science fundamentals.)
  • A willingness to adopt our development practices (Agile, clean code, TDD, etc.)

Personal Requirements

  • Self-managing; able to work on a small, maker-led team
  • Sees the big picture (the client’s goals), not just the code
  • Willing to keep learning new tools and languages
  • Cares about doing good work; likes to improve practices
  • Strong communicator; able to help clients and teammates make good decisions
  • Able to work constructively in a group; not led by ego

These qualities also show up in the question script we created for job interviews, which you can read more about next week.

This initial list will evolve as we continue to improve our hiring process, refining our expectations and looking for ways to remove bias.

Writing an Attractive, Gender-Neutral Job Description

We had several goals for our new job description:

  • Tell prospective candidates everything they might want to know.
  • Emphasize soft skills like teamwork and creativity. These are more difficult to find than technical skill, and they signal to candidates that we’re a welcoming environment for women and men.
  • Sell Atomic as a great place to work.

This ended up being a lot of text, so we broke our new developer job description into five parts:

  1. Introduction – what we’re looking for
  2. The Position – what it’s like to be a developer at Atomic
  3. Requirements – the skills and qualities we expect from candidates
  4. Why Atomic? – reasons Atomic is a good place to work, with a link to more benefit details
  5. Becoming an Atom – how to apply, and what you can expect from us

We also made sure our website had a Careers page with details about our benefits and culture, and a Diversity page that outlines our philosophy, statistics, and plan.

Once the draft was written, we solicited feedback from several developers (women and men), and used Textio to test for coded language in our job description.

Conclusion

So far, our new description has brought us a lot of great candidates–several of which have turned into excellent new employees, including two female developers.

If you have any suggestions about ways we could further improve our job descriptions, we’d love to hear them. Please let us know in the comments below.

Sources