27 July 2009 | Tips | Guest Blogger

There are thousands of freelance Web developers listed on oDesk who you can hire to build your site. But, how do you…
…pick one for the job you need done?
…keep costs down?
…keep the developer from snowing you on time estimates?

In my experience there is one key consideration that determines your best path to hiring a developer. The determining question is: Are you technical?

This is a trick question for some people. I have friends that consider themselves technically adept. They enthusiastically read up regularly on geek blogs and forums. They can discuss expertly and in-depth about the latest developments in platforms and applications. However, they do not have any real world programming experience. So when they try to manage their oDesk programmers, they inevitably get into trouble. They think they are speaking the developer’s language, but in the end both parties get frustrated and confused. The work is delayed. They end up burning more developer hours than my non-tech-loving friends.

In other words, my technology enthusiast pals know enough to be dangerous, but not enough to be useful in hiring and managing programmers. I am not technical myself but thankfully my business partner is, and he manages all hiring and communication with the programmers. Here is a quick litmus test he created to see what side of the fence you lie on.

#1. What is the process that takes place when you upload a file in php?

#2. The opposite of rel=nofollow is “followed”. True or False?

If you understand the lingo but cannot nail the answers to the questions completely and coherently, then you are not technical.

If you are technical:

• Test your applicants’ coding abilities. Ask each applicant to solve a programming problem. If they try to assure you they know the answer but don’t want to solve it, cross them off the list.
• To control costs, consider hiring at an hourly rate vs fixed price. You have the ability to give very specific and accurate work requirements. By getting tight time estimates and keeping in regular contact with your developer, you can have more control in making sure all billable time spent is on the right things.
• To save money, consider taking a chance on a provider with zero or little oDesk experience. It is riskier, but programmers with no oDesk history tend to be cheaper and more appreciative to be given the nod. They also tend to have fewer jobs going at the same time, which means you will get more of their undivided attention. To hedge your bets, give a new provider a small project, say less than 2 hours’ worth of work, and then cap the provider at 2 hours/week. If they produce shoddy work, are late or can’t get the job done in the allotted 2 hours, cut them loose and try someone else.
• Always be as detailed as possible in your specifications. If you expect them to use a particular platform or programming language, spell this out. Real life examples are always useful. For example if you want a rotating photo gallery, give them a list of websites that already have this implemented.

If you are not technical:

• Stick with applicants that have at least 500 hours of oDesk history and an average feedback score of at least 4.0. These applicants have an extensive and transparent performance record which is invaluable for the person who cannot evaluate the applicant’s work on a peer level. Look for buyer comments that compliment the provider for accurate time estimates and ability to communicate.
• To cap your spending, consider limiting the number of approved hours on the job or hiring for a fixed price. This reduces the risk of the provider either unintentionally or otherwise soaking you for overages.
• When communicating with the programmer, speak plainly and use layman’s terms. A good programmer will come down to your level and it will be easier for both of you. Resist the urge to get fancy and use coding terminology. I wince when a colleague, in talking to his programmer, constantly makes references to “Java” not knowing that Java is a completely different technology from “Javascript” which is what he really means.
• Always be as detailed as possible in your specifications. Real life examples are always useful. For example if you want a rotating photo gallery, give them a list of websites that already have this implemented. Telling or showing them what you DON’T like is also useful.

Jenise Uehara is an internet marketer based in the San Francisco bay area, focusing on urban clothing and streetwear.