If you’re a Rails developer who wants to join a team of friendly and welcoming people who are dedicated to learning, growth, and building great software then this post is for you.
The times are changing! Like a lot of companies, before COVID, thoughtbot was already thinking about what combination of in-office and flexible remote work made sense for us. COVID and quarantining accelerated some of those decisions and we entirely revisited how we are structured and serve clients.
We’re now looking for developers not just in specific cities, but anywhere throughout the Americas (UTC-3 through UTC-10).
In a post like this, I’m probably supposed to say something like:
thoughtbot is an equal opportunities employer. We encourage candidates from all backgrounds to apply.
Those things are true, but they also don’t go far enough. I want to spend a little more time discussing a few of the things we’re doing to put diversity, equity and inclusion at the heart of our hiring process.
As we share this role online, we’re prioritising job boards and communities that serve groups who are under-represented in our industry.
Our social networks tend to be racially homogeneous, so reliance on referrals and introductions from people in over-represented groups perpetuates that over-representation. We need to reach out beyond our own networks.
Not only that, but there’s plenty of research to suggest that people from under-represented groups are less likely to submit an application. The way different groups are typically socialised – whether they’re taught it’s best to follow the rules, or forge their own path – can lead to a big difference in how people react to something like a list of job requirements. For example, men will generally apply for a job if they match around 60% of the requirements, while women are likely to only apply if they meet 100% of the requirements.
A few of the communities and job boards where we’ve posted this job or previous openings are:
The words used in a job description matter, and can unintentionally discourage certain groups of people from applying. The words we choose can carry subtle messages that we don’t intend. For example, words like “driven” can have a masculine connotation. This doesn’t mean that the qualities associated with “drive” like resourcefulness and motivation are exclusive to masculine-presenting folk, only that language we use to describe these qualities can be highly gendered and racialised. Using a word that is associated with members of one group sends a subtle message to members of other groups that we’re not talking to them.
We try to structure our interviews to accommodate candidates in all kinds of situations. There’s no take-home coding test, which assumes you have the luxury of free time to do a bunch of work before we’ll talk to you. Instead the interviews are all self-contained, and increase in length from stage to stage, meaning that we’re only asking for larger blocks of your time if we are both already feeling confident that this could be a good fit.
Within the interviews themselves, we’re careful about the questions that we ask. We are looking for people with established programming skills, but we aren’t in the business of gate keeping. Our interview questions are focused around the skills and tools needed to do this specific job successfully – if you haven’t had the opportunity to build up a portfolio of open source contributions or you don’t have a background in Computer Science that’s not a problem.
We all have unconscious biases: it’s not possible to live in a society without picking up some of its prevailing assumptions and attitudes, even if we consciously disagree with them. Rather than ignoring these biases, we want to work to mitigate them. We use standardised questions and rubrics to make sure that we’re evaluating each candidate on the same list of criteria. We also don’t pass feedback from one interviewer to the next, so that biases that may creep into one evaluation don’t influence the next one.
This post doesn’t cover everything we’re doing to prioritise diversity, equity, and inclusion in our hiring process, but even if it did there would still be gaps, problems, and areas to improve.
Continuous improvement is a central part of how we work at thoughtbot, and that applies just as much to how we build our team as it does to how we build our software.
We’re not perfect, but we’re committed to doing the work and to always getting better.
Check out our remote Ruby on Rails developer job description, and apply today!