"As part of our engineering team, you will work in a fast-paced environment using best-of-breed technologies to deliver cutting-edge solutions to challenging business problems."

People love to talk about themselves, and companies are no different. Explore the job pages at any tech employer and you’ll agree. Each job listing will contain boilerplate text about their fun-loving culture, describe their engaged and productive employees who enjoy solving big problems, and outline their generous benefits packages. But what about the job descriptions themselves? What the job listing says-- and doesn’t say-- plays a huge role in who applies for the job. Typical postings use dynamic, action-oriented verbs combined with generous helpings of industry jargon and endless lists of requirements. This language attracts a very specific type of job seeker. I recently had the opportunity to participate in the recruiting process for early- and mid-career developers at my company. The first thing that I did was to review the language that was typically copied-and-pasted into each job listing. I immediately saw words like “drive”, “influence”, “solve”, “impact”, and “lead”. What these words communicate is that we were looking for very confident and influential engineers whose primary focus would be on problem-solving. We further related that many of our key engineers had worked at companies like Google, Netflix, and eBay. What would all this mean to an early-career developer? Someone who lacked the confidence of their more advanced peers? Someone who was looking for the opportunity to learn and grow, maybe under the guidance of a mentor? Someone who had enthusiasm but lacked experience? It’s simple. The message is, “You don’t belong here.”

"Deliver high-impact contributions and technical guidance to an agile software development team that solves complex problems to regularly ship high quality, performant, secure software that operates on data at massive scale in the cloud."

I had expressed dismay before at our hiring practices. It seemed that whenever we had our monthly engineering all-hands meeting, the new hire announcements featured three more young white guys. I felt that we could do better. My manager agreed, expressing a desire to attract unconventional candidates for our open positions, and hoped that we would find good candidates from underrepresented populations. I knew that this was unlikely given the way our job description had been written. What’s more, I felt like the values that we seemed to implicitly communicate to candidates, based solely on the way the position was described, was out of step with our actual engineering culture. We have what we refer to as our Operating System, which outlines the characteristics that we value in our employees (bright, kind, and goal-oriented) and leadership (trusting, inspiring, and learning) and our core values (partnership, integrity, innovation, and responsibility). Our job description did little to communicate these values and seemed to be targeting people with a very different set of attributes. If you truly believe that your engineering culture is welcoming and provides opportunities for growth and learning, shouldn’t you make that a core part of your message to potential employees? For many people, the job description is the first and perhaps only thing that they will ever read about your company. It is your opportunity to make a first impression, and if you don’t make a good impression, that person will come to believe that you’re not a good fit for them or their peers, friends, and acquaintances. The important point here is that a job listing isn’t just about communicating qualifications. It’s a critical part of expressing what a company truly is and what it values.

"Must be able to work independently on projects, manage day-to-day assignments and deliver solutions as a proactive team member."

I decided to scrap most of our existing job posting and start from scratch. I referred back to the documents and presentations that were given to me as a new employee. I read them carefully and compared them to my experience as a member of the engineering group, and made note of how the culture as described in this material manifested in my professional experience at the company. I had to ask myself, “What are the traits that actually make me successful at my job?” To be honest, it wasn’t my nine years of experience with Ruby and Rails. In fact, in the first six months at this job, I had spent all of two weeks writing Ruby. Instead I was learning and writing Swift and Go, languages that I had never been exposed to before. I was loving it, and loving the support that my peers with experience in these languages were providing. Problem solving is a core component of any software development job, of course. But the job description as written didn’t really communicate how we actually solve problems. Engineers are paired with business partners, non-technical staff who understand the relevant part of the business and represent internal or external users. We work closely with these business partners: negotiating, exploring, discussing, and collaborating with each other to come up with viable solutions to the challenges the company faces. Engineers aren’t expected to solve problems on our own; we’re expected to be good communicators who work well with others. I decided that in writing a new job description, I would focus on describing these traits rather than creating lists of the technologies we use and creating the expectation that in order to succeed you had to be some sort of technical genius. This was important in attracting diverse candidates because there are behavioral differences in the way that men apply for jobs versus their marginalized peers. A study conducted by Hewlett Packard in 2016 found that women apply for jobs when they meet nearly 100% of the listed criteria, while men apply if they meet only 60%. So I started by emphasizing that although we have a set of tools and technologies that we rely on to get our work done, new hires weren’t expected to have already mastered them. Rather, we would actively work to help them gain comfort with these tools and learn the skills necessary to use them effectively. And even for people who had been exposed to these technologies already, we would provide the chance to further their understanding and expertise. Next, I looked for opportunities to emphasize the collaborative nature of our work. I described our teams not in terms of the deliverables we produced but rather the process that we followed to create those deliverables: remote teams consisting of people at different levels and with different sets of expertise, using a variety of communication techniques and development strategies to work together in an iterative manner, learning and exploring as we go along. After going into detail on some of the tooling and technologies that we use daily, like service-oriented architectures and continuous integration, I was careful to point out that we’re excited to share our expertise with new members of the team. What’s more, our expectation is that new team members would help us adopt more effective practices and explore the full potential of these technologies.

"You must demonstrate the ability to take initiative and work in a fast paced environment with little oversight."

Next I rewrote the section of the job listing that listed non-technical qualifications. I strongly believe that since technologies come and go, the most valuable skills that engineers can have center on collaborating, communicating, learning, and teaching. So I wanted to use language that would select for people who valued these skills, too. The first thing I did was to change the heading of this section from “We expect engineers to have...” to “We are excited about you because…” This makes the content more personal: we’re not describing engineers in the abstract, we’re talking directly to the person who is curious about working with us. I went on to write about the attributes that would make someone successful in our environment. Enthusiasm, collaboration, and a desire to build on their experience. The motivation to help the entire team learn and grow. A focus not on creating solutions, but creating experiences. An interest in developing leadership qualities, and inspiring the people around them. Respect for the work, combined with a desire to find new and better ways to carry it out. I ended the section with an explicit call for very specific kind of person: “You are respectful, empathetic, and humble. Like all successful engineers, you are kind and considerate. We want you to take your work seriously and be excited about personal and professional growth.” I also pushed back on labeling the position as “junior” or “mid level”. Our industry doesn’t have a standard for measuring the experience level of developers, and all too often we conflate years of experience with capability. If we truly wanted to attract kind and bright individuals, it shouldn’t matter how many years of experience they have with what are essentially disposable technologies. I talked with my manager, and we agreed that the job would be open to anyone who had at least some experience as a developer, and at a minimum three years of experience in any kind of professional setting (in any capacity, not just as a developer). Our confidence in our culture helping people become successful by creating learning opportunities made us more comfortable recruiting people with less experience, but our requirement for professional experience of some kind came from the need for a successful employee to have basic organizational, communication, and collaboration skills.

"The successful candidate must show a passion for the latest / greatest tech and tools while working in a fast-paced environment with multiple teams in a large organization."

Finally, I suggested that if we reached the final round of hiring without any viable women or minorities in the selection pool, we should take this as an indication that we had not done a good job at outreach. We would start the recruiting process over, and try harder to attract diverse candidates. After regular discussions with my manager, conversations with members of our recruiting team, and collaboration with a few other hiring managers, I had approval for the new job posting. So how successful was it? We had over three hundred applications, almost 75% of them from underrepresented minorities in tech. In the end, we filled all three of our positions with engineers from marginalized communities. But rather than patting ourselves on the back, we have begun the hard work of making them feel welcome and realize success. We're looking forward to learning and growing together.