How to Hire the Right Developer

There’s one big question that every tech recruiter faces early on in a candidate search. The question is: How can I find the right developer when I can’t code my way out of a paper bag?

Imagine trying to pick the right kind of car if you’ve never driven one. Or trying to pick out the best cantaloupe in the supermarket if you’ve never eaten one.

Just because recruiters talk to technical people all day doesn’t mean they’re very technical.

While my very literal developer friends are going to make fun of me for comparing them to grocery store fruit, the point I am trying to make is that every tech recruiter struggles to match the job requirements to the candidate because recruiters are not developers. Tech recruiters can’t adequately screen even a junior developer because they don’t know a class from a method or a variable from a constant.

How many recruiters called you this week looking for a JavaScript developer when your resume clearly shows you are expert in Java? Everyone gets those calls and it’s frustrating to programmers who begin to feel that they are nothing more than a quota to fill or a commission to bank. Sometimes that’s true, but I believe most recruiters are good people that want to help you find meaningful work. However, it’s the rare recruiter that even knows a little HTML/CSS.

There has to be a better way to do this.

Are Soft Skills More Important Than Coding Experience?

Yes, yes, 100% yes. Soft skills matter more than coding. I won’t hire a coding curmudgeon, no matter how many lines of code they’ve written in their lifetime. You’ve met coding curmudgeons before—they shuffle out from their cubicles and act all cranky because the standup forces them to communicate in a non-binary language. Sadly, today’s Agile programming frameworks are rapidly leaving many of these folks behind, but before they go, they’re going to make you feel dumb for not knowing something that they do. #gross

I’d argue that culture fit along with squishy human characteristics like intelligence, curiosity, a sense of humor, troubleshooting ability, and a closet full of clever t-shirts, makes for a better developer hire. Sure, I’ll be impressed if you have 10,000 lines in your GitHub repository, but I won’t be able to read any of them. Sorry!

Every problem, whether it’s life-related or in Visual Studio, can be solved in a variety of ways. Every developer, no matter their experience, has new things to learn. The right developer is the one that recognizes this as fact, and is excited to get started.

Finding the right developer, at least at AWH, is more about the person’s ability to fit in with the team, how they solve problems, and how they interact within our special culture of nerd. Which is why I say “no” to computer curmudgeons all the time.

While learning fresh skills is a part of the developer job description, at least at AWH, a new hire still needs to be able to get to work on a project on their very first day on the job. This argues for a coding test as part of the screening process.

Trigger alert: Developer testing controversy ahead.

Should You Test Developers?

Yes, yes, also 100% yes on testing. Unless they have a developer portfolio where you can read what they’ve written and see the final product, there’s just no other way to verify skills.

Please don’t make them do it on a whiteboard in a roomful of strangers unless they’re applying for an architect role, though, okay? That’s so unkind. Instead, select a kata that tests them on the skills they’ll apply to the particular role you are trying to fill. If it’s a full-stack role, test them from the SQL side, through the API layer, to the front end, to really understand their skills and even what they gravitate toward. Then put them in a testing environment that mimics what they’ll experience on the job. I mean, Google is our friend. Stack Overflow is our friend.

The answer at AWH was a home-grown kata that does all of this. However, one thing was missing. We know that problems are solved in a variety of ways. So, we added an additional interviewing layer that requires the dev to run the finished application, then flip back to talk about how they solved the kata. This live coding review is intended to understand how the developer troubleshoots and what best practices they apply to their decision-making process.

If you’re testing, please let the dev work on it in an environment that simulates what they’ll experience on the job. Usually, this doesn’t mean they’ll try to solve the problem on a whiteboard. AWH doesn’t even set a time limit on our testing process, so the developer can do it at 2:00 am if that’s when the good code really pops out. Sure, everyone is driven by sprint deadlines, but setting a 30-minute time limit on a kata when the developer is sitting in a strange conference room in their too-tight suit, doesn’t really mimic that environment.

Bottom line? Do test. But do it in a way that is humane and creative and doesn’t set arbitrary rules that have nothing to do with the job.

Finding a Better Developer

You know I Googled “how to hire the right developer” before I wrote this, right? No joke, there were 85 million results. Like the truly stubborn rule breaker that I am, I didn’t look at any of them and just wrote from my experiences at AWH. I’ve been here four years and I still think recruiting and hiring is an imperfect process that we’re constantly honing. Each company and individual recruiter will rely on a different process to vet their candidates. However, I think the best way to hire the right developer is to understand the work environment they’ll experience then try to match for culture first. The testing process is in place to back this up with concrete screening that measures the hard skills. Together, these steps in an imperfect process at least give us a bit better shot at finding the right developer for our excellent team.