How to do a Hiring Process that Doesn’t Suck

I’ve been working as a software developer since 2008. That’s long enough to have been part of dozens of hiring processes. I know how hard they can be. But because I’ve never hired anyone in my life, I can’t say for sure that I know how to do a great hiring process. That doesn’t mean I can’t help you to avoid at least some of the most common mistakes.

But before proceeding, I want to make it clear that I know recruiters have tough jobs. As it happens with developers, most often than not they don’t fully control their work. Someone else defines the position and the information that can be disclosed, and then a recruiter tries their best to find good applicants. So I’m not here to bash them. I’m aiming at the people who have control over the hiring process.

Now, without further ado, here are my tips.

Money matters

Imagine you’ve just arrived at a restaurant. You’re comfortable in your chair, so you start to read the menu. Then you see this:

“Chicken Cannelloni: fair price
Cheese Manicotti: enough for us to have a profit
Ravioli with Meat Sauce: affordable price”

Pretty ridiculous, right? But that’s exactly what software developers see all the time on job posts. The most common salary for us is not a number, it’s “competitive salary”. It’s insulting. Our bills are not abstract, they have numbers on them. So we need a salary number or at least a salary range before deciding to apply for a job.

Money is literally the reason why people have jobs. If you’re not providing salary information, you’re asking us to ignore the position. No one wants to waste time. The hiring process can be exhausting, and the salary offered in the end might be less than the minimum the applicant is willing to accept. In cases like this, everyone wasted their time.

The smart approach here is to provide salary information upfront. You can do it in the job post, or in the first message that you send to developers. The only reason to hide this kind of information is the hope to underpay a suitable applicant. That’s a dirty tactic, and you shouldn’t start a working relationship that way.

You’re not recruiting for the CIA

Sometimes the secrecy goes beyond the salary information. I had a few recruiters approaching me about positions, but without providing any relevant information. They didn’t even say the tech stack or the name of the company. At most, they said something vague like “it’s a fast-growing company with a vibrating culture”. It’s not like I can search about the company with that. And any questions I had would only be answered in a later call.

If you want to do it right, you need to assure that right in the first contact we have all the information we need. The goal here is to entice developers who are a good match for the job. But if you don’t share anything useful, you’re not giving us any reason to apply. And we need some motivation, because we know we’ll spend some time in the hiring process. So if you’re not giving us enough data to decide, we’ll apply for a position that does.

You don’t need many interviews

I know it’s tempting to torture applicants with an endless series of interviews with absolutely everyone in the company. But as strange as it may sound, this is not a smart choice in any way. Most people will get tired amid the process. And if they’re doing other processes at the same time, you’re risking losing a good applicant just because your hiring process is needlessly long.

And let’s be specific here: 2 interviews are usually more than enough. 3 at most. If you need more than that, you should probably improve your process.

Keep the interviews short

Having fewer interviews is a good start, but it’s not enough. You need to keep them short, no more than one hour and a half.

I’ve witnessed first-hand the terror of an excruciating long interview. It took 3 hours! Not even my mom wants to talk to me that long. I still have nightmares where I relive that terrorizing experience. Please, don’t traumatize other innocent software developers.

The problem with long interviews is that they’re exhaustive. You’re setting up the applicant to fail. A tired person is not in their brightest state of mind. What you have is someone off their A-game. They’re not worried about giving good answers anymore, they’re just saying whatever will make their suffering end quicker. This is not a good setup to know how good a worker a person can be.

Let applicants choose how they’re going to be evaluated

The world would be a better place if people could just believe me when I say I have advanced knowledge in every language/framework/tool ever created. However, unfortunately, the world is full of cynical people, so we have to prove our skills when applying for jobs. The two most common methods to do that are live coding and code challenges. I don’t know how familiar you’re with these practices, so I’m briefly describing them below:

  • Live coding: a process where the interviewer proposes a problem to be solved through code. The applicant writes the code during the interview session, and the interviewer can see it while it’s being written. The interviewer not only evaluates the code produced, but also the thought process that led to that code.
  • Code challenge: here the interviewer also proposes a problem to be solved through code, but the problem is usually bigger, almost always a small application. Because the applicant will have more code to write, it doesn’t happen during the interview. The applicant submits the code before the given deadline, and then the code is reviewed. In most cases, the interviewer asks questions about the solution in the following interview.

I’ve always preferred live codings, mostly because they take less of my time. I was ready to recommend you to favor them when I started drafting this post. But then I talked to some of my friends, and I found out that not everybody thinks the same as me (what a surprise!). Some people get really anxious doing live coding sessions. Just because they know they’re being judged in real time, they perform considerably worse. Then a strong applicant looks lost in the hiring process.

So my advice here it’s to let the applicant choose one of these two approaches. It will give you more work to do, as you need to think about problems and solutions for both formats. But by doing that you have a bigger chance of not letting good candidates slip just because the process doesn’t favor them.

Provide closure

No matter how bad the applicant was in the process, be decent and give feedback after it’s over. Even if it’s a short email with an automated and soulless answer. Anything is better than silence. It’s extremely disrespectful to let people wait indefinitely for an answer that will never come.

If you don’t want to do the right thing out of courtesy, do it because it’s the best business practice. When you don’t notify failed applicants you’re sending the message that as soon as your company has nothing to gain in a situation, it will pretend it didn’t happen. This is a terrible message to have your company associated with. Especially because the person doing the association is a developer who most likely knows other developers. Now all these developers know how unprofessional your company can be. And because you jeopardized your company’s reputation, it will become increasingly difficult to hire new developers. So how about avoiding all this trouble with a simple email that won’t take more than 5 minutes to write?

It doesn’t matter why the applicant is looking for a new job

This is the last item on the list because I know it’s debatable. Maybe it doesn’t bother other developers. But seriously, why do recruiters have to ask the reason why we’re looking for a new job? More often than not, it’s because we want better pay. Even when it’s not, does the reason really matters? And more importantly, there’s a chance you won’t ever know the actual reason. You’ll have an answer that sounds good in an interview.

This is even more enerving when the applicant wasn’t looking for a job, and it was the recruiter who made the initial approach. It shows that the interview is just a fixed script. But it should be a more relaxed conversation with the goal of finding out if the applicant is a good fit for the job. Any question that doesn’t help us to get closer to the answer should be left out of the conversation.

Final thoughts

Time is the scarcest resource in life. The person leading the hiring process is in a unique position to save a lot of time. To do that, you must provide as much information as possible, as earliest as possible, and in the clearest way you can. This is how you prevent people who are not a good match for the position from even applying.

Additionally, a hiring process that doesn’t suck needs to respect the applicants. It needs to respect and value their time, avoiding anything that is not necessary to run the process. This will benefit the company as much as the applicants.