Learn how to code
The hard truth is if you're hiring someone to code for you, you should learn at least a little bit of code.1 That takes time, and some effort, but it's worth it for a couple of reasons.
The first is that you need to know what you're talking about, at least at the surface level, because that's going to inspire confidence and trust in your developer that they're working for someone who knows what they're doing; that they're working for someone who values their contribution.
But beyond that, you need to, at least on the surface level, know what they're talking about, and the basics of the argument they're making for themselves. There are many places all over the internet you can get access to an hour of code, just to start you off.
Check The Portfolio
It's not your job to know everything, however. The best lens into a developer's skills and experience is through a portfolio of their work.
Whether it's just screenshots or whether they're able to bring in an application they worked on, actually being able to see examples of their work can give you a sense of what they're capable of.
But you can't just look at webpage. You need to be strategic in how you're ask a potential developer to describe their experience, and drill down on their portfolios. Find out what their personal contributions were. Push for the reasoning behind why they make that choice and not a different one. Get them to describe how they worked on their projects, whether it was remote and freelance or leading a team.
Look not only for their expertise, but how engaged they are in telling those stories. It's worth taking at least 5 minutes on each example to really get a candidate talking. People will reveal themselves once they're put in the position of having to relate their experience.
You want someone who's thoughtful and excited about what they do, not disengaged, condescending to a non-programmer, or talking over your head.
Ask For Recommendations
The other way to get a thorough, but thoroughly non-technical, sense of a good developer is to ask for recommendations. Before you make a call or shoot off an email, ask the candidate what they think their references are going to say.
There are a few additional ways to judge a developer.
A trial period, or beginning a working relationship with someone on a project basis, is almost never a bad idea. It gives you a chance to test their ability to contribute effectively to your team - and see the progress they make with their code - without the full commitment of a salary and benefits.
Ask them what their experience with and how open they are to regular check-ins. Again, good developers won't just be able to code. They'll also be open to feedback and willing to present their ideas to non-technical teammates.
Some specific questions that can help you gauge a developer: ask them what their favorite stack is, what language do they like to code in and why? Do they do any testing, and if so, what kind of system? Do they use version control, like Git? Just because someone's been coding for a while, that doesn’t mean they’re good.
Look for someone who’s open to trying new things, and who seems like they can adapt to the constantly changing methods and technology.
It's really that willingness to communicate, and the ability to explain themselves and be held accountable, which separates good developers from just developers.
Even if you only need some one-off help, you're bringing someone into your team's locker room. It's not enough that they can code. They also have to communicate.