A Fair Hiring Process For Software Developers
What’s the alternative to the algorithms we love to hate on?
It feels like every day I open Medium there’s a new post about why the hiring process for software developers sucks.
So, as someone who has just been through a hiring process, I thought I should share my thoughts on how it went.
I’m not here to criticize interviews or argue against algorithms. There’s enough of that out there already.
I’m here to talk about a process that I went through and found to be very fair, hoping to shed light on what a solution may look like, instead of adding to the list of articles talking about the problems with the traditional way of hiring developers.
As a disclaimer, I should say that the company I’m talking about did end up hiring me. However, this article was in my drafts list before I got the offer. In other words, I don’t think their process is fair because they hired me. I think their process is fair because it is (in my opinion, of course).
Lastly, it’s worth saying that these thoughts are my own. I didn’t get told to write this article, nor was it even proofread by anybody at the company.
So, with that out of the way, what did I have to do to get my current job?
Step 1: Email
Applying for the job wasn’t done through a form, it was done by sending over an email to the CEO (we’re talking about a startup here).
In my view, this is already a big plus.
First, you’re not limited by what some fields tell you to include. For example, I didn’t even send over a CV. My personal website essentially has everything my CV has, displayed in a much nicer way. I thought there was no need for redundancy and ended up skipping sending over this “essential document” for a website.
Second, you get to be freer in your approach. You can structure the email in any way you like, which helps show your personality.
Finally, it’s more likely that you’ll get a reply, even if it’s a rejection. It’s far easier to ignore a candidate who’s just a name on a spreadsheet, rather than a person talking to you directly via email.
I don’t know if emails were used because they’re the preferred method or because they’re just easier. But I sure hope they keep it this way, even if applicants end up messaging someone other than the CEO as the company grows.
Step 2: Interview With CEO
This was scheduled to be a 30-minute chat, but it went on for almost an hour.
I now see that on a day-to-day basis our CEO is very busy, so if he had a meeting in the following slot, he might have had to leave on the dot. However, in my case, we went overtime and that’s great.
It’s much nicer to have someone (at least appear to) take interest in you rather than just approach an interview like something that has to be done. I think most of us have had some call or interview that we thought was going well only to have the person cut you off with a “Gotta run, bye!”. It doesn’t feel good!
Step 3: Interviews With Engineers
This part of the process is pretty similar across the board.
If you’re applying for a technical role, someone has to check that you know something. In my case, this happened in the form of two calls, both a little over 30min.
I first talked to the CTO and then a senior developer. Both calls were very relaxed and included personal questions from me to them that weren’t directly relevant to the role. Overall, the environment was very comfortable.
Step 4: Contracting
This step is what I consider the juice of this article. Instead of putting me through practical skills interviews or giving me a take-home project, they just hired me on a temporary basis.
The idea of getting hired as a contractor for a few days or weeks before being given a full-time offer isn’t exactly new, but there were a few things that stood out to me about this specific process, which I’ll get to soon.
However, I want to first briefly introduce this concept for those who may not be too familiar with it. Essentially, in order to see if the candidate is a good fit for the role and the team, instead of getting you to do a series of tests, a company just hires you to do some paid work to see if you’re the right person for the role.
This is as fair as it gets. You’re getting paid, you get a chance to see what the company is like, and you get to work on something that’s not only representative of what your work will be — it’s literally what your work will be.
In my trial period, I worked on issues on the GitHub repos. My work is actually live today — I wasn’t given simulated things to work on, I was working on the real thing.
So those are some of the benefits of this general concept, but here are some things that stood out to me about my process specifically:
“About 50% of candidates get to this stage”
When I got the email back with the offer to work with them for three days, I was thrilled. But a few lines down, the CEO said that half of their applicants reach the trial period.
Contracting for a few days isn’t a special opportunity offered to a select few who have already been through a multitude of tests — this is how candidates are tested. I think this is quite fair.
It makes a lot of sense. Test your candidates in real working conditions and see what they’re actually like.
“We’ll mark your rate up by 20%”
Hourly rates for consultancy/contracting are higher than full-time rates. Period.
Why should it be any different if you’re going through a hiring process? You’re still doing work.
In my case, I was paid 20% more than what my salary would have been, pro rata.
During my contracting work, I didn’t feel like an external part of the team that was just doing some work on the side.
I was involved. In fact, I was given quite a bit of responsibility to determine what to work on, as well as a chance to chip in on decisions.
Overall, I think the choice to hire candidates to do real work is a win-win. In other words, it’s fair.
From my perspective, I was paid a fair amount, given a chance to really feel what my role would be like, an opportunity to show off my skillset, and got to see how well I integrated with the team.
From the company’s perspective, they were able to see what I could actually do, get some real work done, and minimized their chances of making a hire they would regret (and having to spend far more money to find that out).
Step 5: Feedback and Offer
The very next day after my trial period I had a call with the CEO to discuss how it went.
This was great for me because I got some honest feedback as to how the team felt about me as well as what I did right or wrong. Accepted or rejected, this is valuable.
And then, following feedback, I was offered a job!
I didn’t accept it right away. Between their offer and my acceptance (about a week), the CEO and I had a few discussions about what I was looking for in my career and how that could be aligned with my role.
I made some points about where I see myself in the future and he agreed to a role structure that was supportive of those — another plus!
Finally, I accepted the offer and joined PostHog as a technical writer and developer.
I hope this article offered a good overview of what a hiring process can be like, without necessarily criticizing other approaches, which all have their pros and cons.
Different roles call for different methods. But on the whole, the concept of hiring a candidate (for a fair rate) to do some real work with you is something that I think is fair and beneficial to both sides, as well as applicable to a wide range of roles.
This doesn’t need to replace everything else either — it can be used in combination with other methods.
The rule of thumb is this: Value your candidates. Oh, and letting a candidate know if they’re rejected is also a good idea!