I’ve spent some time recently restructuring our hiring process for software developers.
The goal of this project could probably be copy+pasted by any tech company actively hiring developers these days:
We want to hire competent, talented, and diverse software developers to be great Makers at Atomic Object. To accomplish this, we need to ensure that the hiring process isn’t unfairly filtering out or turning away qualified candidates, while also appropriately vetting all the skills necessary to be successful at Atomic.
Of course, the saying is easier than the doing. Evaluating our current process turned up some obvious areas for improvement, and it would have been simple enough to make an adjustment here and there and call it a day.
But before plowing ahead, I wanted to be confident that any calibrations being made were the right calibrations. And to answer that question, we needed to know how to evaluate any particular calibration for “rightness.” We settled on four goals.
Our hiring process must:
- Be equitable
- Be respectful of everyone’s time
- Set a clear bar for hiring
- Adhere to Atomic’s core values
Be Equitable
This was the fundamental building block on which all the other evaluations and changes were built. It meant that any modification had, at a bare minimum, to make our process more equitable and inclusive than its current state.
This could take a myriad of forms, but I liked that it made it easier to look critically at each part of the process through a broad lens: not just asking why we were doing a particular thing, but also how we were doing it, who was doing it.
One large change that came out of this was the form of our take-home programming assessment. We moved from an assignment that was very strict and narrow in its expectations of programming technologies and possible solutions, to one that basically gives the candidate full freedom to complete the task in a manner that makes the most sense to them. We still have a rubric and set of functionality goals for the candidate to complete, but how they achieve them is their choice.
Doing this necessitated shifting a large burden of work from the candidate to us, as we now had to expect to evaluate submissions in many different programming languages and tech stacks. Hopefully, giving every candidate a platform to show off their strengths means we’re measuring for a more general level of expertise, not a familiarity with a particular style of programming.
Be Respectful of Everyone’s Time
Hiring is time-consuming. It’s in our best interest as a small company to limit the amount of time we need to spend vetting candidates. It’s also in our best interest to limit the amount of time any candidate needs to take out of their busy lives to interview with us.
We didn’t want to sacrifice quality by spending too little time evaluating a prospective hire, but we wanted to make sure that the time we asked of others (and ourselves) was being well spent. If it wasn’t, then something needed to change.
A great example of this is the technical screener we do early in the interview process. Before giving someone the aforementioned take-home, we do a one-hour session to evaluate basic technical knowledge. The last thing we want is to ask someone to spend hours on a complex assignment if they aren’t able to complete it.
Before, we did this session in-person at our office, when possible. We’ve now moved to doing it entirely remotely, with a Zoom call and a shared coding environment in a browser. This change made our process more equitable by not biasing toward candidates who could easily travel to our office or who performed well on display in a new environment. It also meant we weren’t asking people to take extra time out of their day to travel to downtown Ann Arbor, find parking, walk to our office, etc.
We still have an in-person interview as our final stage, but I was very happy to cut out this leg of the journey for our applicants.
Set a Clear Bar for Hiring
As I mentioned above, we don’t want to sacrifice quality in our hiring. Setting clear expectations for what we’re looking for in a candidate and what qualifies them to move onto the next stage of the process serves two functions.
First, it makes the process more equitable by being less biased when evaluating candidates. Note that “grade everyone the same” is not what we’re aiming for here, as that can produce the opposite effect of equitability. These expectations should partly be about acknowledging barriers a particular candidate may have faced.
I think the second important function these clear expectations serve is less obvious but ties back to being respectful of time. If you don’t know exactly what you’re evaluating for, how do you know when you’ve gathered enough data? I’ve experienced this at other jobs as well, where a hiring process is overly complex to cover for the fact that the team or manager didn’t really know what they were looking for.
Enumerating the qualities you want in a candidate and how you hope to identify those qualities allows you to turn a critical eye toward your entire process and identify duplicated or uninformative effort.
We put this in practice in our new hiring process by targeting a section of the final in-person interview, a “Q&A” session. This was supposed to be a time for the candidate to ask any unanswered questions and for additional Atomic employees to “get to know” the candidate. In our experience, candidates already had sufficient opportunity to ask questions, and enough of our people had participated in the process to get an accurate sense of the candidate. It wasn’t helping the candidate clear any particular qualification for the job. We cut it out completely. It’s gone.
Adhere to Atomic’s Core Values
This one was a given. Hopefully, we’re always doing this in every aspect of our jobs. But speaking (or writing) it out loud can help you remind you to not take it for granted. In this process, two values stood out as particularly relevant:
- Act Transparently
- Teach & Learn
A big effort in our hiring process overhaul has been documentation — not just the process itself, but all of the reasoning and decisions behind it, our rubrics and metrics, and how we communicate the process to our candidates. Some of this is admittedly still a work in progress (isn’t it always 😂), but we’re getting there. It’s been a collaborative effort to ensure that the different stakeholders were contributing and having their concerns heard.
Having a well-documented hiring process allows us to be more transparent with our candidates upfront, which helps us:
- treat each person more equitably (no surprises),
- respect their time (reduces questions about the process), and
- set a clear bar for hiring (they know what to prepare for upfront).
It also makes it easier to onboard new Atoms to the hiring process (we’re even documenting that process!), providing a great professional growth opportunity. Just as we’re generalists in our software development, we can be generalists in our hiring as well, providing redundancy in the office with people trained and skilled to manage different parts of the hiring process.
Having more people available to conduct interviews also lets us be more respectful of everyone’s time, giving the candidate more flexibility to schedule interviews and reducing any particular Atom’s need to be available for those interviews. For a small company and office that can’t afford to have a dedicated recruiter and hiring manager, this is a huge boon for our future success in hiring the competent, talented, and diverse software developers we are looking for.
What’s Next?
I don’t believe this process will ever be “done,” but we’re rapidly approaching a stable release. At that point (like any good software project), we can continue to iterate and fix any bugs we discover. As long as we continue to strive for the four values I’ve laid out here, I’m confident we’ll have a process we will be proud of that can serve our needs for a long time.