In SaaS companies, one of the most important hiring decisions we make is to bring on new developers to our engineering team. And even for technical founders, the developer hiring process can be arduous and fraught with indecision.
Here at Castos our developer hiring process has evolved quite a bit over the years we’ve been in business and today I want to share how we recruit, screen, and hire developers to our engineering team. Hopefully this framework gives you ideas about how you could implement a similar (or just take our entire process and implement it yourself) process in your business.
The job posting
As with most forms of content one of the first things to get right is to capture your target audience’s attention. For job postings, this is a combination of writing a great job description, and posting it in places where your ideal candidate is looking for new opportunities.
For the latter, we post our job postings initially directly on our site. We have a Careers section, and each new job posting is linked to from there.
In each job posting we try to highlight 3 distinct areas of what might attract highly qualified candidates to work with us here at Castos:
- Working on interesting problems: developers want to work on new and challenging problems. We hope that our tech stack, how we work, and the problems we’re solving are interesting enough to bring the best talent out there.
- How we work: we’re a remote-first team. Always have been and (hopefully) always will be. This is baked into our DNA and we hope that applicants will come from similar backgrounds because working remotely is a different experience for everyone than an office job.
- Our value of work/life balance: We don’t have schedules that we demand team members to be on or a bunch of meetings that they have to attend. Our top priority is freeing everyone up mentally and emotionally to do their best work. We hope to convey that approach to our work/life balance through a posting like this.
Tools for this step in the process
We’ve experimented with a bunch of Applicant Tracking Systems, and have used them in the past for previous roles, but at this point in our hiring lifecycle it’s just overkill and I can achieve a better result with a combination of tools:
- WordPress – our castos.com marketing site (where the job postings live) is based on WordPress, which is infinitely customizable and we add job listings there directly as new Pages.
- Gravity Forms – a powerful forms solution that has a LOT of integrations right out of the box.
- Zapier – we use this to send Gravity Form submissions into a single Google Sheet, so I can easily scan through applicants and track their progress through the process.
- Google Sheets – this is our ATS I suppose. A single Google Sheet has all of the responses from each applicant in one place, so it’s easy to filter, sort, and review.
Where we place the job posting
We take a phased approach to promoting and listing our job posting in various outlets. The reason for this is partially that we want to give different avenues a chance to work before we decide to move on to larger (and some paid) places to list the job.
First, the job listing goes on our Castos Careers page. Having this on our site is a MUST for me. I don’t get how/why some people want to place their main job posting on an ATS or other 3rd party site. Get folks to your website any time you can, I say.
We then publish the opportunity to our social media channels, and reach out to our friends/partners in the podcasting/SaaS industry to ask them to help promote it.
Always our best-case scenario is to hire someone who’s already using our plugin or hosting platform, so promoting the opportunity to our customers is a natural fit there. Plus, I think customers like to see that your company is growing (especially these days when so few are).
This last part is particularly true in us expanding the reach of our potential applicant pool to underrepresented groups. We reach out directly to development communities that specifically cater to women and ethnic minorities so as to get as much diversity in our applicant pool as possible.
In our latest round of hiring, we let the social media and adjacent-community outreach efforts go on for about a week before we listed the job on our first job board: Dynamite Jobs.
Being a member of the Dynamite Circle, a membership community put on by Dan and Ian of the Tropical MBA podcast (which I’ve been a longtime listener) we are able to post there for free, and their applicant reach is huge. Especially in the marketing, support, and admin roles I’ve found that Dynamite Jobs is a fantastic place to list your job and you get some really interesting candidates from very unique backgrounds.
We leave the listing on Dynamite Jobs for another week and then will usually proceed to WeWorkRemotely to post the listing, especially for developer roles. They just tend to have a bit more technical crowd than other platforms I’ve tried in the past.
At this point the job posting has been in the wild for a few weeks, and we give another couple of weeks for applicants from the job boards where we posted most recently to apply. Overall the application period is roughly 6 weeks.
The job application
Once someone sees the job posting the next step for them is to fill out an application.
Our application form for each role is slightly different, but you can check out our form for developers here.
The goal with the application form is to get as much quantitative data about applicants as possible so we can make an effective first screening.
Initial review of applicants
Before we start the review of any applicants we de-identify as much of the Google Sheet that all applications are populated into as possible. Much thanks to Laura Roeder from Meet Edgar for sharing with us all how they hire. This inspired a lot of what we do in this step of the process.
We do this simply by hiding any columns of data from our application form which may introduce bias into the initial screening steps. This includes things like name, email address, location, and even GitHub profile (because there are headshot pictures there typically). The goal here is to remove any potential for bias about applicants.
In this first pass, we look at as much of the qualitative data we can. For our company as we work in both the WordPress realm and in Laravel for our web app looking at applicants experience in both of those environments is a good first pass.
Another easy screening is to filter out any applications that have empty fields. If someone can’t take the time to give at least SOME response to each of the ~12 questions we ask then they won’t move on to our next round in the process.
Additional candidate screening
Specifically for developers, one easy way to look at the work that they’ve done is in open source contributions and their Github repos. We look through the work that someone has done there and how it fits with what our development needs are and our tech stack.
We also always ask for a sample of someone’s writing.
Whether it’s a technical document, a blog post, a white paper, a social media post, anything is fine, just a way to get a feel for how applicants communicate in written form. As a remote team, written communication alone is the vast majority of how we share knowledge, and being an effective written communicator is paramount.
From there we screen the initial applicant pool down into those that we want to invite to first round interviews.
First round interviews
Our first round interview is with me and is completely non-technical. This is a “culture fit” interview to see if the applicant is a good communicator mostly.
I also take this opportunity to ask the single most important question at this phase in the interviewing process: “Why are we here?” What is it that’s making you want to make a career move at this point? Are you going away from something (if so, why), or towards something bigger?
I have been hugely influenced by the Who Method book (thanks Ruben Gamez for the recommendation), which lays this out in much more detail. But it’s essentially a game plan for how to interview and screen applicants. They follow a more thorough and rigid process than we do, but a lot of what we do is taken from that book. Definitely worth a read if you’re hiring at all.
Interview Questions and Notes
In this round of interviews I’ll have more than a dozen 30 minute talks with candidates. It’s tough to keep that all straight, so I keep notes during our conversations.
I also write out a list of 6 questions I ask every candidate in my private Notion area. Each new interview gets the template card duplicated, and I keep notes right there. So questions, their responses, and my notes are all in one place.
Technical project
After the first interview those applicants that are a good fit for what we’re looking for move on to a small technical project. We use CodeSubmit for this part of our hiring process. This is either a Laravel or WordPress project, based on the type of work we do internally at Castos.
We ask candidates to finish these projects within a few days of starting them, but they should only really take a few hours of development time.
They are able to use the tools they feel most comfortable with, and submit their project right from the CodeSubmit project page. We are then able to evaluate the work they’ve done, the decisions they’ve made, and based on their commit messages, hopefully are able to see why they made those decisions.
Technical interview
With the first round interview done and the technical project complete we move on to a technical interview.
In this 30 minute discussion, the applicant and our lead developer talk through the test project. Something that’s very important for us is why someone made the technical decisions they made. Not necessarily is the code the absolute best code, but are the reasons behind it sound.
In this interview the applicant and Jonathan Bossenger (our lead developer) talk in more detail about an applicant’s approach to their development process, philosophies on testing, refactoring and working with a non-technical product manager (like me!).
Making an offer
With the first round culture interview done, the technical project complete, and the technical interview done we make a decision on who we want to bring on to the team. An offer is made (and hopefully accepted) and Castos is one team member stronger!
Parting thoughts
As a non-technical founder hiring developers has always been a bit of a daunting process. How to know what a “good” developer is, where to find them, and how to communicate effectively is something that I’ve grown in immensely in the last few years of running Castos.
I’m sure I have a long way to go with this, but I feel like our developer hiring process now is both very clear, fair, robust, and repeatable so we can continue hiring top quality candidates to our team.
