How NOT to Hire a Freelance Developer

I’ve seen a rash of really bad job postings on Elance lately and I thought I’d step in to offer a little (ahem) constructive criticism.

Here’s the thing. Bad job postings are bad for everybody, because they lead to unclear expectations. Developers hate it because we have no idea how to bid these kinds of jobs… and the job posters hate it because they always end up paying more and getting less.

Now, certainly there’s something to be said for how a developer should submit their proposal back; however, 1) I can’t see how other developers do it, so I have no case studies and 2) it’s hard to critique the proposal if the job posting itself is jacked.

So, here’s a list of things NOT to do:

1. DON’T Be Ultra-Concise

I’ve literally seen listings like this:

I need a custom WordPress theme.

Then, the job will be listed as a fixed price job and the budget will be “not sure”.

As the developer, there’s almost nothing I can do with this. Yes, I can submit a proposal without a price and ask all those questions, but here’s the rub for you the business owner:

A good developer won’t.

Good developers (the kind you want) aren’t desperate. They have plenty of work and generally only look through job postings every couple weeks or so when other projects are finishing up.

And, they’re picky. They won’t take just any client. And, they’ve been around the block enough to have developed a sort of “radar” about what projects to avoid.

And, this is the kind of project they’ll pass right over.

What this kind of job posting does is attract more desperate developers… developers who will take just about any job. Developers who haven’t worked on enough projects to know when to walk away.

In a nutshell, NOT the kind of developer you want.

Instead, take a few minutes (or hours) and really think through your project. Flesh out the details. Know what you want. If you can, develop mock-ups of exactly how you want it to look and function.

You’ll attract better developers and you’ll get better proposals and you’ll know right away which developers paid attention and which ones didn’t. And, your chances of landing a quality developer are much better.

2. DON’T Be Incomplete

Here’s a perfect example of how to be incomplete:

This is a high level description and does note reflect the final description. Some more features will be added. Your bid should reflect the total price for the entire project considering these requirements represent 70% of the total requirements.

The big problem with this is it was posted as fixed price job. If it was a posting for an hourly job, it’d make more sense, because the details could be fleshed out and they’d be billed at the hourly rate.

But, for a fixed price job?

I’m not sure how you can expect someone to bid your job accurately when you’ve only given them a vague description… and it’s not even the WHOLE description. Details matter when bidding a job like this.

It’s hard enough for a developer to estimate how long a job will take them… even with a full, detailed description. A proposal like this will typically get two types of proposals:

1. Overbids. Developers who at least recognize that the scope of this project will most likely increase pretty dramatically and they will bid accordingly so as to not be accused of “jacking up their prices” later.
2. Underbids. Desperate developers who just want the job and who will bid it low to win. But, once it comes time to actually build out the project and they see how much they have to do and how little they’re getting… are very likely to abandon the project.

Neither is accurate and both will lead to turmoil down the road.

Instead do one of two things:

1. Either, flesh out the details of the project before-hand and post a full description including mock-ups, if possible.
2. Or, post it as a hourly rate job and be willing to pay the developer for non-development time… that is, time helping you flesh out the details.

Personally, I specifically avoid fixed price jobs with incomplete descriptions because it’s the perfect breeding ground for massive scope creep… and generally it’s the developer that takes the heat when timelines and budgets get blown.

So, to attract good developers… be complete.

3. DON’T Be a Douche

I see postings all the time with some sort of harsh language in them like:

Note: Don’t be lazy and actually read this posting before submitting a proposal.

Or something along those lines.

Here’s a hint for you…

The people who don’t read the postings… don’t read the postings. Whether because they’re using some sort of software to auto-submit or they’re copying and pasting their proposals… whatever the method… they’re NOT reading them.

Which means they’re NOT reading your note about not reading the posting.

On the other hand, the developers who DO actually read the job descriptions see that note and are immediately turned off. Again, good developers have developed a kind of “radar” about these things and they’re constantly looking for cues as to what type of person they’d be working with.

And, this is a major red flag. It screams snarky and good developers will move on.

Again, you’ll end up with desperate developers who need the money… and who are more likely to abandon you later.

Instead, just do what you’re doing anyway without actually feeling the need to state it. That is, immediately ignore the proposals that obviously did not read your job posting. It’ll be pretty easy to spot. Just ignore them and move on.

Because, you’re GOING to get them whether you put that note there or not. Sad but true.

And, that way you don’t send any red flags to the really good developers… the ones you want.

Don’t Try to Buy Steak From McDonalds

Another important point to consider here is the quality of the network in which you’re searching for freelance developers.

You wouldn’t expect to get a high quality New York Strip from McDonalds’ dollar menu… so why do you think you can find a high quality developer on a price-oriented network for $5/hour?

You can’t.

The standard approach is to visit an “open” freelance network like Elance, oDesk or Freelancer.com… post your job and watch as 800 Tom, Dick and Harry’s harass you about how great they are.

With these open networks, it doesn’t take much to get approved as a freelancer… and the onus is on YOU to separate the wheat from the chaffe.

Even worse, all you have to go on is a written service description, a limited portfolio, and some ratings.

If you’ve spent any time on these sites, you know most of the freelancers all tend to blur together after awhile and it’s difficult to know who is really great.

But, a new breed of freelance site is emerging.

These new sites are much more aggressively curated. Sites like Crew and Ziptask (among others) curate the freelancers for you by making them go through a rigorous application process.

This means only the best, most committed developers get through.

Probably the most unique of these I’ve seen is Ziptask.

When you land on the home page you see a live video feed of an actual project manager waiting to answer any questions you have and work with you to build a team for your project.

You click “Get Started” and you can be chatting with an expert in seconds… and that expert will work with the necessary developers for you to get your project complete.

It’s immediate and managed. And, it’s impressive. I have yet to see anything else where you can be talking to someone so quickly.

But, regardless of what network you go with… you need to understand what you’re getting into. If you go with a site like Elance or oDesk, it’ll be on you to curate and manage your developer.

With a curated site like Ziptask or Crew… they handle those things for you.

So, don’t try to buy steaks from McDonalds. Recognize if you’re set on going to McDonalds… you’ll probably have to settle for a cheeseburger.

Who’s Advice Should You Take?

Finally, I want to talk a little bit about this whole business of giving advice on how to submit job postings and hire developers on freelance sites.

I see a lot of marketers offering advice on how to submit your postings on sites like Elance and oDesk.

That’s cool. I’m sure it’s valuable to see how they do it.

But, BE careful. A lot of the advice I see… from the developer’s perspective… is… well let’s just say “not quite accurate”.

Here’s my favorite I see a lot of marketers teaching:

This job should be easy for someone who knows what they’re doing.

I see marketers teaching that you should put this at the bottom of every job posting.

Look, I get what you’re trying to do… but we’re not dumb. A good developer sees right through this. Insulting my talent to try and get a lower price won’t work. I’m going to bid the job what I think it deserves regardless of how easy you happen to think it is.

Because, frankly, I know you don’t actually have a clue how easy something is or is not. If you did, you’d just write it up yourself.

More probably, a good developer will just move on… because we’re picky. And, you can choose from all the leftover, desperate and  unseasoned developers who are probably going to make your life miserable.

Have fun with that.

But, at the end of the day… we really do want to help you. We love watching your project come to life, seeing how excited you get, and watching as you launch and start bringing in those first dollars, and so on.

It’s a great experience that we get to re-live project after project.

It’s just those first few encounters. They set the tone for the entire relationship… and, if you heed the advice above when crafting your job postings, you’re much more likely to attract quality developers who will actually bring your project to fruition.

And, that’s good for everybody.