I'm curious because many startups hire remotely at first, and there's still a lot of problems with that atm.
His insight is that you want a process to bring people in and shoot them quickly if they don't work out. It's sort of sink-or-swim but with a rubber ducky that has a leak in it. If they figure out the system from documentation and start contributing good stuff the core team will start working more with them. If they're slow to respond, don't submit stuff that looks useful they just whack them and move on.
He has some pretty amazing people on his team, that said he's dealing with the typical timezone and remote worker synchronization problem that all these teams have. Recent conversations have turned towards building a core team that is "in an office together" somewhere to get core work moving quickly and smoothly with stuff at the edges being worked on oDesk team members.
I personally haven't done any oDesk projects yet but I imagine "Hire carefully fire quickly" is going to be the best advice I can give.
That he's wasted so much money and now suddenly thinks everyone should be in the same office is a sign he's probably a terrible project manager. Probably.
He is looking to get a really small core team in a small face-to-face space to accelerate their work. It's about speeding up iteration cycles and anyone who has worked on distributed teams know the challenges of not being in the same room with each other. That said I've had success with distributed teams but I've yet to see one loop through cycles as quickly as one that is in the same physical space on a regular basis. I'm not saying it can't be done, just in my time and experiences I've not seen a distributed team out pace a team that is in physical locality to each other on a regular basis.
1. Post smallish fixed price jobs and say more is at stake if they do well.
2. Hire several people for the jobs, if there are good candidates.
3. Stick to your typical screening methods. For me, I like checking out their stackoverflow and github.
4. Communicate well, ask for their honest feedback, and don't tolerate BS. If their work in a small fixed price job is good but not great, it will likely only get worse.
5. It's better to have a go-to team of specialists for many things. Ie Don't have a general PHP hacker help design your database. Foundational and architectural stuff is worth paying more for a specialist.
End of day... Small fixed price jobs limit your losses and failures in a major way.
Once you like someone, get a contract going. Rinse and repeat if you're growing and profiting.
This is a giant red flag for me as a freelancer. It immediately puts me off as a sign of this guy is being defensive for some reason.
"I know we're paying you lower than your usual rate, but if you do this right, there's another project down the line."
No thank you.
Besides, ODesk uses a BIDDING system. They tell you the average bid price. Bid whatever rate you want.
If you are above the average bid rate (which sounds likely) and can sell the client on why they should pay you more, then put it in your cover letter. It's the exact thing that happened with my last devs.
You've seen the bad code out there. We have to be defensive if we want to keep our money around long enough to see the project to fruition. But I never said to underpay. I said to not commit to bigger things until you know what you're getting.
Don't forget that the client might not know what the budget should be, and on most sites, you can simply bid above their max and explain in the proposal why their budget was too low. Likely you will stand out if you brought up something they forgot to include or didn't consider.
Question: what if they said there will be an audition project at your specified rate? Not fixed bid, but you would be expected to provide an estimate. That is how I am doing it for my next project and would love to hear feedback.
Don't put words in my post/mouth. This is garbage.
1. Reviews by clients are not worth much. I've had a situation where my client asked me to fix the project after previous developer, who's code was horrible, but at that time my client didn't realize it, so they gave him 5 stars.
2. Pay attention to the language candidates use - very often their summary/portfolio is written in correct English, but during conversation they make lots of very basic mistakes. I'm not a native English speaker, I also make mistakes, but quite often these people just can't communicate in English, and this , sooner or later, will become a problem for you.
3. It's better to invite developers than to just post an offer - I've seen offers starting with "ONLY DEVELOPERS BASED IN US" to which hundreds of people from Asia applied. People don't even read descriptions, they just apply everywhere.
4. Developers' summaries are overrated - I've interviewed people with "more than 5 years of experience in web development" etc. whose code was more like junior developer's.
5. Having said that - ask people for samples of their work. The best is some OS project, because then you know it's their code, but actually few people write OS. Anyway, reading the code, even just 2-3 simple files, helped me to reject a few developers who made good impression during the talk.
TL;DR: chat to see if they can use English, read their code, be sceptical about what they and their clients wrote about them.
Good developers don't use oDesk to find freelance work. They have a good enough reputation to find work through their professional network. oDesk is a race to the bottom where you compete on price instead of skills. Its a market for lemons (http://en.wikipedia.org/wiki/The_Market_for_Lemons)
I'm a contractor and I wouldn't touch oDesk with a 10 ft pole.
Since then, I've expanded my opportunities by reaching out to my competition to build friendships and explore ways of working together.
I found my (limited) corporate background a bonus because I was used to working on a relatively productive team (edit: so I could basically pull a team of freelancers together and bid on a large project as a group of independents), and a liability because I tended to think "I could always go back to the corporate world" instead of taking every opportunity to figure out how I might make self-employment work. It wasn't until I hired a business coach (a former SV corporate guy himself) that I started to learn how to make the whole thing psychologically/emotionally sustainable. There are opportunities to write your own failure narrative around every corner. :-)
But contractors in lower cost countries are just as capable, while charging one third to one fifth of Western European / US prices. While this sounds low, the living cost, tax rates and average salaries are such, that oDesk freelancing becomes very appealing for a person in such a location.
A specific example: A frontend dev salary in Eastern Europe (full-time position) of 3.000 USD a month is quite decent. On oDesk, he can charge 25 to 30 USD pr. Hour. If he is good, he will end up with full allocation, and thus a salary of 4000 to 5400 USD pr. Month given a 160 hour work month. Additionally, he also has the personal benefit of working 100% from home, at hours which he usually has some control over.
Being unable to find good people to work with on oDesk and similar sites, is due to lack of experience in outsourcing, not because it is a market for lemons.
That aside, given the ease of access to information the internet age has brought, I think it's more likely that hourly rates and skill aren't as coupled to geography as you suggest. A skilled developer even in Eastern Europe, if he is at all aware of his own skill, is likely to charge as much as any western developer unless he's hopelessly ignorant or just plain desperate. The rest are as average or below-average as their rate indicates.
2) Assuming 100% utilization is completely unrealistic. Does this frontend dev ever want to take vacation or take a sick day? Does the time that they spend searching for new clients not count towards utilization? Etc..
3) Every actually good developer with excellent English skills I've ever run across from lower cost markets like Eastern Europe, Asia and South America all charge full high cost market rates.
2) It is only unrealistic for freelancers doing many small jobs. Not for contractors with ongoing 40+ hour contracts, of which there is a lot on oDesk. Maybe the confusion is semantics: When I talk of 100% allocation, I mean 160 hours of available work. Over a year, you'd remove 10-20% for vacation and illness, like mentioned above.
Check the work history of the higher rated contractors on oDesk if in doubt about this. There are many doing much more than 160 hours on average.
3) This is certainly not the norm :-) Not a lot of companies are interested in hiring a person a thousand miles away for the same amount of the guy next door. Especially not the type of companies who can afford developers contracting at high-cost market rates i.e. 100-300 USD pr. Hour. Again, if we are nitpicking, there are of course exceptions like especially well known developers or developers who are proven and known to a specific client. Then it's an entirely different story.
3) I'll readily admit that this point was anecdotal from me. But as someone who has worked with many both "good" and "bad" offshore ESL freelance developers, I can definitively say that the good ones asked for a competitive wage while the bad ones were asking for pennies on the dollar. It was really self-segmenting in this way.
Up your rates and suddenly shady guys don't contact you, and good clients recognise talent and you get a good paying job.
You might be making a fine living. But I suspect that if you're a good developer on oDesk, you'd be making a lot more off of oDesk.
Switching to oDesk and raising my rates immediately helped me land $X+400%/month. Immediately. It was just astounding to me. I'm sure I could earn more on other websites, and as a matter of fact I'm currently attempting to join TopTal.com
I've heard great things about that site and the way they operate.
Things I avoid:
- Groups where I have to talk to a Project Manager. Especially where the Project Manager is the translator to the team because this can cause a lot of misinterpretation and mis-communication.
- Non-English developers. This doesn't mean the developer has to be fully fluent in English, but if they can't convey their ideas via text/email where they have as much time as they need then it's hard vice versa.
- Yes-(wo)man. A Yes-man is a freelancer that just says yes on everything you say instead of coming up with other solutions. This is common when you deal with Project Managers.
Things I love:
- Talking to engineers and letting them know they can freely give any input.
- Engineers that provide feedback. I had two engineers say they can do the project in the way I wanted it, but also mentioned that they could do it a better way that's faster, safer, and less expensive. I hired them for a few more projects after that and they kept saying the same thing. I ended up partnering with them with equal shares on future projects.
If you need any more help, feel free to message me
You must find someone who speaks excellent English -- it's too frustrating otherwise. The number of hours a person has worked on other projects the most important. I'm sure anyone can fake reviews. Devs will also say they can do everything, so you have to track down their specialty. I was looking for experience with date functions so I made sure to ask for that and confirm with the devs I shortlisted.
I am currently working on oDesk with a guy from India. His English is excellent and the project is going well. I pay $20/hr. I am very careful with the assignment of hours. Any extra hours are negotiated up front. If he doesn't negotiate an extension on his side then he won't get paid for it.
Another thing to consider is that you may have to work late in the night or very early in the morning, especially during debugging sessions, which can be disruptive to your life. Due to the time difference I would actually prefer to hire an American dev but I didn't see that many on the site, and I guess they would charge much more.
I worked with more than a handful of remote developers on projects over the years, and had more troubles with ones in India than in other countries. The troubles almost always stemmed from variations of "this is what needs to be done. do you understand?" followed by a lot of "yes" affirmations. Time would go by, and it would become painfully obvious that there was a basic non-understanding of the task at hand.
This happens on every project - even face to face ones, no doubt - but it happened disproportionately with remote developers in India, and interpreted it as a cultural thing of not every wanting to publicly(?) admit to not understanding something, even if it meant jeopardizing project timelines for the rest of the group.
This has been several years now, and my sample size was small, but it's also not been terribly out of line with war stories I've had from other colleagues over the years.
On the flip side, I did a code review of a project done by a team in .. Ukraine, and I nearly cried at how well done the whole thing was - good tests, decent docs, good structure, etc. It was some of the best code I'd ever seen in 18 years of doing this professionally. I also know that team was not found trawling odesk and trial and error, but was put together via word of mouth and referrals over several months, then treated as a full long-term team, not just a one-project-and-done group.
I've been freelancing for about 2 years now on oDesk and owe so much to that platform. It's allowed me to find great paying jobs with smart people.
Here's what I look for when applying for jobs. My oDesk rate is usually from $30 to $45 /hr - so this may not apply to the lower end of 'cheap cheap cheap fast fast' developers.
* Well written job titles. Descriptive and concise.
* Clear information on where the project stands at the moment. Is this a greenfield project? Is this in the design phase? Do you have mockups? Specs?
* Client history. If I see a client has an average hourly rate of hiring at $10/hr I don't bother applying as I don't think we'll be a good fit. Likewise if the client is new with no feedback or previous contracts completed, I may be hesitant to apply.
---
These are the key things I look for to find good jobs on oDesk. If you want to attract great developers, keep them in mind, they're a must!
If nothing else, HN job threads tend to be full of people looking for remote work.
(I have no experience with oDesk, on either side.)
Sometimes smart people just want something to do and getting paid a bit is nice on top of that. That said I imagine most of it's noise and you really have to focus on sorting through the noise.
If you're just looking for "cheap labor" for the goal of having "a cheap startup" then you've already failed.
You have to be very careful about the type of job you hire for. It needs to be highly structured, with very limited flexibility. The instructions I post are often as long as the document that needs to be written. Because my instructions are so explicit, there is little room for error. They know exactly what they need to do, and how to do it. If they screw up, I take it as a failure in my instructions, and tweak them for the next time.
The job details also include something about how they should write their bid. I usually ask them to write a sentence that indicates their understanding. This is usually specific, and relevant to the job, such as a list of topics they're able to write, based on the job description. You'd be surprised how many people don't do this. It's a quick and easy filter.
Once the freelancer has successfully completed an assignment with me, they've earned a little bit of trust. I'll hire them again. Eventually, I'll give them more flexibility, more pay, and more challenging work. Most freelancers won't get there, but that's OK. I've structured things so that it's hard to fail. It's also not particularly easy to get ahead. They've got to pass the filters.
I moonlight on Elance but I'm trying to build a solid portfolio to get away, and I think most decent remote workers do the same, mostly because projects posted on these websites are a race to the bottom.
I would say stay away; you're better of posting the position on the 'Who is hiring' thread here on HN, careers.stackoverflow etc.
If you insist on hiring developers from freelancing websites though, my personal opinion is:
1. Have a realistic budget. You get what you pay for. Yes, there are differences between countries, and not everyone needs to charge $100 an hour to make ends meet but when you're hiring a developer for $15 an hour (from anywhere in the world), you're taking a huge risk.
2. Don't bother with job posts, the signal to noise ratio is too low, especially when you specify a decent budget. Just search around for developers with solid portfolios. Don't pay too much attention to reviews, all it takes is one bad client who's not able to communicate to ruin your 5-star record.
This works for front end development to mitigate risk. Every time we get a very clear winner and it's not always the one we predicted before hand.
I would never use odesk for architecture work, that's what my job is for. Mission critical systems should be developed internally, or at the worst completely understood by someone internally.
odesk is also fantastic for advise or simple scripts on things I don's specialize in. I can often get a script/optimization in an hour that would have taken me a day to figure out myself.
Post a job - maybe somebody is looking for a job and you can't see him/her. And try to find them also - maybe they are working so hard that even don't have a time break for job searching.
I've tried multiple times over a span of 4 years and never once had a good experience or even got a single project done -.-
Review the applicants' portfolios thoroughly. They are a good indication of experience and ability.
The trick is to have very extensive, clear specifications. Also, oDesk is good when you need a specific technical problem solved.
Set some defined milestones, make sure they are met, bail if there are unmistakable signs the contractor can't cut it.
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.
The developer I hired worked out well and he is still employed.
With regards to recruiting and the 20% good recruiters charge, most companies are set up to expect recruiting fees and don't convert the extra cash into rates or wages when they don't have to pay them -- in theory a company that spends $0 on recruiting fees should have 20% more to pay, in practice it almost never works that way so avoiding recruiting fees seems to be a one-sided benefit. If you're good enough to get quality contracts through a good recruiter, you're not going to make more money on oDesk and you'll lose billable hours to managing site profile, and going through entire bid/negotiation and in some cases estimation processes without getting paid. Assuming that most contract developers feel the same way, the site is likely to cater to the bottom of the market, which makes finding talent extremely hard.
Remote work has it's own challenges, the things that I've found essential is:
- Great communication - Great documentation - Smart lightweight processes - At certain stages of company avoid outright remote (even 9 days remote + 1 day in office every 2 weeks is a very different animal from outright remote -- you actually meet everyone in the company in person in one of these two cases) - Personality and culture fit as well as general empathy are important: negotiation and responsibility under pressure with people you've never met in person is difficult. - Great management - Manage time zone differential if the product is subject to lots of change: (12 hour cycles for back and forth Q&A on something that's unclear is extremely expensive).
Note that by great in the above requirements, I mean higher quality than most early stage start-ups achieve.
The easiest way to find good developers is have them come to you, and the best to way do that is to have a good job ad.
* Tag the ad with the appropriate tech
* Add a high level description of what the job is. Not just technically, but what is being made too. Also, whether it's as part of a team or completely autonomous.
* Include links, to a company website if you are one, or to your own website / twitter / github / etc if you have them.
* Post hourly jobs only. Fixed price jobs may be appropriate sometimes, but only if they're fully specced out to avoid scope creep.
* oDesk allows you to specify the experience level you want (Entry Level - $, Intermediate - $$, Expert - $$$), treat this more as how much you're willing to pay rather than the real experience level. Ideally, they should correlate, but they often don't.
Tagging the ad with the tech is important, I have a filtered view on the job feed to remove all that isn't relevant to me. I see only ~10-15 new jobs per week and may apply for one or two of them. If your ad is tagged and it's something that I'm interested in then I'll see it.
Next, filtering out the less good / less interested freelancers by making the job application process a little more difficult. Many freelancers spam out applications without even reading the ad contents, you want to exclude them.
* I've seen some ads that ask freelancers to include a certain word in their application so the client can filter based on that.
* Even better (IMO), and the best way to find good hires, is to include a couple of your own questions in the application. oDesk allows you to set these in addition or instead of the standard cover letter approach. It will filter out a lot of freelancers that are solely spamming out applications and don't have time for anything that doesn't fit the standard template. Those that get through, you can filter them on their answers.
Once you have a few freelancers that you're considering hiring, send them a bit of extra information on the job, maybe discuss it a little, set up a Skype meeting. Don't go overboard here, it should be a short-ish process, not a free consultation.
Then, hire someone. If it doesn't work out, we're easy to fire.
--
An additional note on the job ad (from experience), be honest in it about rates etc. Don't tick the "expert" box if you're looking for someone at $cheap/hr. If you're a startup that's looking to pay in equity that state that up front instead of after going through all of the above.