How to vet a freelance developer when you aren't technical yourself

I was at a local tech meetup. A man approached the table. "Is this Tech Tuesday?"

He was seeking a freelance developer who could help him finish development on his mobile app. He'd been through the ringer, having contracted with multiple shops and each time having a terrible experience.

Feeling down and out, he just wanted to find development talent he could trust to deliver on their promises.

I spent the better part of an hour listening to his needs and providing insight into how he might go about finding the right person. And I wanted to ensure he didn't waste any of his precious time and money on the wrong person.

If your background is business, you know how to deal with people better than you know how to deal with technology. What are some ways you can use your interpersonal skills to determine whether a developer is the right fit for your project? How do you weed out the candidates who will end up wreaking havoc?

I'm a developer myself, so I'm a bit naive about it. But here are some things I'd look for if I were in your shoes:

Do they have the heart of a teacher?

Do you believe with your heart and soul that your candidate has your best interest in mind? Is their demeanor more like that of your kindergarten teacher, or a used car salesman?

Software development is a two-way engagement. It's tempting to assume you can hand a developer a pile of requirements, wait six months, and get what you paid for. But in reality, your relationship with them is collaborative. Your understanding of how they build your application will prove valuable to you long after their engagement ends.

Ask them to explain how they would solve one of your core problems. And continue to ask questions until you understand, to the point where you could explain their explanation to someone else. If they're reluctant to engage with you in this way, run. Fast.

Are they willing to challenge your assumptions?

My greatest asset to your business is that I'm happy to tell you when you're probably better off not building the thing you think you need. Often, the software ou think you need to build isn't the most expedient way to your business goals when technical realities smack you in the face.

This doesn't mean you ought to find someone who is lazy or unmotivated! But you want them to push back when you explain your needs, and to justify their concerns.

Numerous times I've told my clients that the feature they thought they needed next probably didn't need to be built yet. Or that there was a way to do it that would better serve their needs for less cost.

Your developer is a running expense to your business. Finding one who treats themselves that way is critical.

Are they an effective communicator?

Building software is 90% communication and 10% code. The end result of poor communication in a software product is a poor product, no matter how awesome your developer's hard skills might be.

If you hire a remote developer, it's critical they have excellent written communication skills. Their work schedule might not overlap with yours to engage in phone calls and chats. And you don't want them to rely on phone calls because then they're burning all your money squawking on the phone instead of building software.

What you're really looking for is someone who can effectively engage you through your project management software. Someone who can answer your questions thoroughly, follow up regularly, and ask questions consistently.

When you're getting to know your candidate, email them with a question about a specific aspect of your project. Get a feel for how they engage in an asynchronous (i.e., not realtime, like a phone call or chat) environment.

On one extreme, you might find their responses thoughtless and overly brief. They might not satisfy your need for clear answers.

On the other hand, they might be too verbose, explaining things that needn't be explained and ultimately confusing you.

Give them the benefit of the doubt, but ask yourself whether their manner of written communication empowers you to make effective decisions about your product. Did your test exchange leave you feeling more confident, or more confused? How would you feel if you were relying on them to put out a fire in your business? Would you have faith in their execution?

Ask them to explain a time they failed. Then ask how they resolved it.

What is defeat? Nothing but education. Nothing but the first step to something better.

— Wendell Phillips

Every developer (myself included—oh boy myself included) has failed at some point in their career. We've botched a client deadline. We've built the wrong feature. We've deployed buggy code to production. And we've probably indirectly or directly lost our clients customers because of those mistakes.

If anything is certain in software development, it's that you'll fail. Because of this, the critical piece when vetting a developer is finding out how they respond to failure. Looking for a developer who has never failed will turn up two kinds of developers: Those who have failed, and liars.

Instead of facing the lost cause of finding a developer who always succeeds, ask them how they've responded to failure. Do they step up to address problems irrespective of who was to blame, or do they focus on placing blame, whether on their managers, their clients, or the technology?

Failure isn't always their fault, but the attitude with which they approach failure is an indicator of their character. Use this as a metric for how they might react to an issue on your project.

Is their rate commensurate with the market rate in your area?

The adage is that "you get what you pay for." While there are exceptions, it's most often the case that a developer knows what they're worth. If they're younger and just starting out consulting, a they might not necessarily know their value in dollars per hour or week. But then too, their lack of experience will likely be reflected in the work, whether it's now or after months of engaging with them.

Use sites like Payscale to determine how your candidate's rate compares to the average salary in the area. To convert an annual salary to an hourly rate, divide the salary figure by 1,000. For instance, if the average salary of a Senior Ruby Developer in your area is $100,000 per year, that comes out to $100/hour. This accounts for 20 billable hours per week, since most freelance consultants will spend equal time programming as they do engaging in business development, totalling to a 40-hour workweek.

If there's an obvious low rate outlier among your candidates, ask yourself whether there might be a reason their rate is so low. Do they lack experience? Are they eager to work with you, or desparate? Give them the benefit of the doubt, but don't let a low price fool you into believing you're getting a great deal!

Do they have professional references? Call them.

Always ask for the phone number of at least one professional reference. It might be a former manager, another client, or a colleague.

When you call, explain you're thinking of hiring your candidate, but that you have a few questions and are hoping they might be able to help. If they had a good working relationship, you'll hopefully find them eager and willing to help.

Don't know what to ask? Try these questions:

1. What obstacle would have prevented you from hiring/working with them?
2. What value did they provide to your business?
3. Would you recommend them to others?

These specific questions will help you identify:

• If there was something that gave them pause before hiring the candidate
• What specific value the candidate provided to a real-life business
• Whether someone would go out of their way to recommend the candidate's work

Now you have a first-hand testimonial with real talking points upon which you can base your decision!

Get a second opinion from someone you trust.

If you know someone else in the industry whose opinion you trust, why not hire them to help you with the process? A seasoned developer or technical manager will have years of experience with other developers and will know what to look for.

They'll be able to review the candidate's sample code and portfolio to tell you whether they'd feel comfortable working with them.

And most importantly, they'll give you an impartial opinion because you'll pay them a fee for helping with the hiring process—not for being a prospective candidate.

Review

When you hire your next freelance developer, consider the following:

1. Do they have the heart of a teacher?
2. Are they willing to challenge your assumptions?
3. Are they an effective communicator?
4. How do they respond to failure?
5. Is their rate commensurate with the market rate in your area?
6. Do they have professional references? Call them.

Hiring technical talent can be anxiety-inducing if you don't approach it with a process that helps you filter away candidates that aren't the best fit for your business and project. Have any techniques you like to use?