| The broader topic for this is "outsourcing". When work is done 90/100% remote, to countries far away, it's commonly referred to as "offshore outsourcing". It's a whole separate production discipline, with unique challenges all the way from staffing to day-to-day management. Many business people and entrepreneurs try offshore outsourcing a couple of times, lured in by the seemingly low prices. They then fail and declare outsourcing as a non-viable solution for product development. It can and does work, but it requires experience. So while you are looking for specific tips for searching for developers, you need to be aware that the work doesn't end there - there's a lot more to it. To get specific though: 1) Always create a private job and invite developers yourself. If not, you'll be spammed with offers from the bottom of the barrel. 2) Filter for location first. If it's your first time with outsourcing, you are best off with developers from countries that are as close as possible to your own culture. For Western Europe, a good bet is Eastern Europe and Western Russia. In the US, you're probably better of with certain south American countries like Argentina and Chile due to the lower time difference. 3) Look for developers that has had long contracts (500+ hours) with 5 star feedback. You can't base much off small contracts with 5 star feedback. 4) Apply same screening techniques as you would, were you hiring locally: Does the guy have an impressive portfolio, CS education, does he have some side projects / Github profile etc, how many years of experience and so on. Don't put too much stock in any single point: There is for example plenty of extremely competent people, who do not have a degree, who do not give a shit about maintaining a Stackoverflow or Github profile and so on. 5) Once you've screened them, invite them to the job listing. Get them on skype, either talk or chat. They need at least a very good written English, if it's your first try with outsourcing. Ask for code samples and review them. 6) If not "just" front-end coding: Have a good, thorough specification ready, for the developers to read. Sometimes they will want payment just to read the spec, sometimes they'll do it for free. Either way, it doesn't show much about their competence. 7) Ask them to deliver a written deliverable of something reasonably advanced. Stuff like a suggested database model, or a very high-level overview of a proposed architecture for whatever it is you are building. This will usually be paid work, between 4 and 8 hours. The purpose is not to get the absolute right db model or architecture - it's to see a written deliverable from the developer. This is invaluable, since it requires real skill, thinking and communication abilities, while still being relatively cheap. If they cannot deliver this, they are not good enough. An exception is if you are looking for some front-end guy, then just get a sample of their markup. 8) Monitor their work closely in the first period of time (first 2-3 weeks is usually enough). 9) Be ready for disappointments. Even with all the above work, you will still not hit a good guy every time. 10) If all else fails, drop me a line, I'll be happy to assist :-) |
My experience (co-managing ~$300k on oDesk) is communication / expectation alignment is one of the biggest reasons a project fails. Project managers, for example, don't know how to vet computer vision experts. Screen sharing is good for seeing that someone is typing something or "appearing" to do work, but most PMs have no idea if the researcher is programming a canny line detector versus AAM. More importantly, just because they know what they want to build doesn't mean they have experience or knowledge to manage an application lifecycle.
Really, the PM should be able to tap into a software pipeline which compliments/augments the expert's natural workflow. Source code management should be a requirement, enforced by the platform, not something one has to vet for. Roadmapping and proposals should be a paid deliverable and a discrete step within the process. And I don't think continuous integration + test cases should be the exception, they should be the norm. Using such a pipeline is self-selecting as programmers who don't understand these concepts will easily be discovered.
Sorry if this is a shameless plug, this is something we've been addressing for a while at Hackerlist.net (we're in private beta). We've open sourced a good potion of our stack in case others want to use these tools to manage their own software development projects.
To support to your list of tips, MortenK, we've also found github to be a reasonable selector. If a SWE has a github account with several projects, this at least demonstrates rudimentary source code management understanding and an interest in open source. It's also an opportunity to review code. We ended up designing an internal search engine for handling discovery / evaluation as vetting great hackers at scale is a big challenge.