As someone who has been interviewing developers for a few years, I'm sad to hear yet another story about bad interview experiences. Here is what we've landed on for developer hiring process:

Resume screen. As you do.

Phone screen. Make sure we're not a total miss here in terms of what we need and what they have experience in and/or want to do.

Online coding challenge. Something that takes one to two hours. I don't want the time constraint to be an issue, but that potentially means a two-hour test, which is intimidating and hard to find time for. But these tell me more about coding ability than most of my options at this stage. There is a pool of prewritten tasks and I tend to pick the challenges that most represent what we have to do in real life. In other words, string manipulation and array sorting, not algorithmic puzzles. Most candidates score either over 80% or below 30%.

Interview. Most of my candidates are remote, as are most of my engineers, so this is typically done over a videoconference. (See my tips for remote interviews.) Usually, it's three or four of us on our side, with one or two of us leading the discussion. There are two main areas we focus on: diving deep into some technical subject and questions they have for us. No whiteboarding, no brain teasers. Just a technical conversation. That tells us all we need to know. And the questions for us portion tells me all I need to know about what motivates them. I'm looking for questions about the business, products, process, team, culture, and the like. Questions about benefits, not so much--those can be addressed in a follow-up email. The interview is normally also one to two hours, depending on how chatty the candidate is.

We do follow up the interview with a much quicker in-real-life (another videoconference with screen sharing) coding challenge. It's usually less than an hour, and we just work through a test-driven development problem from a popular coding practice website. We just want to see how the candidate actually works. We've seen some results in the coding test, we've heard some thoughts during the interview, now we want to see their thought process in action. This can be the most nerve-racking part of the process for the candidate, but we try to put them at ease. It's rare, but we have had a few candidates make it through the other stages completely fail at this portion, and not only because they were nervous. If everyone always passed this step with flying colors, I might consider ditching it. But it has prevented us from hiring a few people who clearly talked better than they walked.

I have been told that our process is more enjoyable than most. And out of 19 people I've hired over six years:

2 left and I was disappointed. They were both great developers but didn't find the work or culture suited to them.

1 left and I was not disappointed.

1 left full-time due to burnout but continues to be successful as a contractor with us.

1 I had to fire.

Everyone currently on the team is awesome. With each additional team member, making sure to not disrupt what is a healthy team dynamic is really important. As I prepare now to add a few more to my team, the stakes have never been higher! rimshot