Well, I just got laid off from a company that decided to experiment with remote workers, then pulled the plug after six months.
They never really made an effort to incorporate remote workers into their culture. The development team is about 20 people, 4 of whom were remote. It was a trial and an effort to get work out of them; there were days I wouldn't have much to do. Managers would book meeting times and then miss them; you'd spend an hour waiting for a ping on Google Hangout or Skype, then go back to doing something else. Group meetings required dialing in because they felt having a spare laptop in the room for a Hangout camera was more effort than the voice-only conferencing system "we've always used."
Last week I was notified that the remote workers were being given an ultimatum: move to Silicon Valley or accept a layoff. I have a family, a mortgage, and roots where I live. I accepted the layoff.
I've worked remotely for three companies. At two it worked: the teams were small, and coordinated, and serious effort was made by management to involve themselves in the day-to-day worklives of their developers. Developers weren't left to wonder for weeks on end what their role, assignment, deadlines and deliverables looked like. The third left me exactly wondering that, and wondering why they threw their money away idling us. I guess they just couldn't hack it.
I'm in Melbourne, Australia, working (contractor) on a project based out of Sydney, Australia, with team members working in Georgia (state, not country), Alabama, California and in the Philippines. In the past, I've worked (from New Zealand) for a company out of Finland, and (from Melbourne)for a couple of companies out of SF.
My main experience of remote work is that a 'normal' 8 hour day doesn't work - everyone needs to be a little flexible with their days and hours of work both for regularly scheduled standup meetings and for ad-hoc conversations with workmates. The oft-seen "US only" may be a timezone related concern.
I understand that international payments are seen as comparatively cumbersome, and (for employees, at least) the tax situation may well be more complicated.
Oddly enough, I'm an American developer outside the US working remotely for a US company.. I'm going to be starting my own company soon (as soon as we wrap up this funding agreement) and will focus uniquely on hiring remote (distributed) developers. As you've said, there is a ton of amazing talent outside of the US, and its actually a win/win by hiring remote. I will consider it as a competitive advantage until all of the "leading edge", "innovative", and "groundbreaking" companies out there in SV decide to catch up
I've worked remotely for the past 4 years as a contractor. I'm in Santiago de Chile, the headquarters are on Sydney.
It has worked fine most of the time, I remember only a handful of times in which I've had to stay up very late because of problems on the production server (we're 12-14 timezones apart!). The support for another of the products of this business is handled by another developer in Sweden, so it's a very distributed team :-)
I've also worked as a contractor with another team based in Cape Town, South-Africa.
To look for remote jobs, besides HN, check on StackOverflow. They allow you to filter job offerings by those which allow telecommuting, but many of them have clauses like "work from anywhere in the US" or "must be a US citizen or have a work permit to work on the US".
Companies hiring you will likely not want to pay more than the market rate for you, where "market" is defined as your geographical area. This limits the desirability of being a remote worker to begin with. It's also a mistake, IMO; companies that use this approach are likely to find themselves giving programmers nice CVs, who then go on to move to a different country with a better "market".
Another big barrier for smaller companies is the logistical difficulties in payroll, currency, international banking, tax compliance etc. - it's easier to be a contractor.
Thirdly, the company culture needs to be set up for remote working. Otherwise you'll have poor communications, and the remote people won't be plugged in to what's going on.
One of the most important things in remote development work is good communication between the employer and the client. This may sound obvious but it is still important.
If the employer and the client are not comfortable conversing in the same spoken language, it is almost guaranteed that the project will cost more money and be delayed. When dealing with a client or employer that does not have the competence of a native speaker in your language you must specify exactly what you need, as if you were talking to a child or machine. Most of the horror stories you see on sites like TDWTF are results of poor communication, not incompetence or malice.
I'm going to guess that a lot of people in the US, like myself, have been brought in on projects that were originally developed overseas--projects that we're in pretty sorry states when the product owners finally gave up and hired a US developer. While it is obvious that there must be many excellent developers from all over the world, I can still say that my experiences with non-US developers have not been good.
(note: Most of the reason for this is because US companies going overseas are primarily doing so to save money and probably are trying to cut more corners than they should.)
Well, we[1] don't hire remote workers, because we don't hire any workers yet, as a self-funded, bootstrapped startup. But, when we do get to a point where we can hire people, here's what I'm thinking:
1. If you limit yourself to "locals only" you stand to miss out on some good talent.
2. Distributed software development teams certainly can work in practice, just look at many F/OSS projects.
3. Guess what, all our stuff is OSS anyway.
4. But, there is extra coordination cost and overhead when it comes to dealing with remote workers.
5. And there are times you just want everybody in a big room together to hash things out. This is obviously harder with a distributed team.
6. All of that said, we'd almost certainly look into remote workers. Within that framework, I think there might be some slight preference for people in the US (less language barrier, fewer time zone issues, etc). The idea of "rural sourcing"[2] strikes me as interesting as well.
7. But we would definitely consider non-US as well. I've heard good things about working with folks from Eastern Europe (Latvia, Ukraine, Estonia, etc.), as well as the Philippines. I think South American countries like Brazil would be intriguing as well. But, at the end of the day, it's about a match between talent, skills and the needs, weighed against the tradeoffs of cultural barriers, timezone issues, language issues, etc.
8. Perhaps surprisingly, I see India as lower on the list of places to seek remote talent. Partly because the timezone, language and cultural mismatches seem more severe between India and the US, compared to some other choices. And also a perception (which might be flawed) that there are fewer individual developers in India looking for remote work. My perception is that it's all Infosys and their ilk when going to India, and that doesn't interest me so much. That said, I'm not saying we wouldn't work with folks in India, just that some other areas seem like they might be better options. But time will tell.
disclaimer: all anecdotal experience
I work at a big co on the west coast and we have had developers in India, hired by the company's India arm, on some projects.
There are coordination issues because it's exactly halfway around the world, especially if a project requires collaboration with another department. Projects sent overseas need to be well-defined and self-contained to get a good result. This alone could cause you to shy away from hiring in other time zones.
Expectations and the engineering culture are different in the two countries. I have worked with India developers who produced work that was worse in terms of depth, quality, and maintainability than the same project later taken up in the US. I do not have an anthropological explanation, and the developers from India I've worked with stateside didn't have the same issues. /fireproof
More experience and tech muscle is concentrated in the US team. How about this: if you were highly skilled and experienced, as a rule you would have moved to the US for the greater opportunity and the big bucks. There's a positive feedback loop here, because banging together lots of skilled workers creates more opportunity and attractive companies, creating more motivation to come, and so on.
I'm a Canadian doing Android, BlackBerry 10, and other assorted dev work. I've done a mix of working remotely and working in the Bay Area. In fact, I'm here in the Bay Area right now. I don't mind a mix of the two, since it is straightforward for me to move back and forth. Most startups seem to like local workers, but it does vary.
From my experience, coding is something really easy to do as a remote worker. However, if you're more into "product design" or in a position where you have to take lots of decisions and communicate with the teams, I found it harder. Also, nothing beats the coffee machine or the beer after work to brainstorm on new ideas.
Seems that the nodejistsu guys have a strong team overseas: https://www.nodejitsu.com/company
"8 timezones: Covering the past, present and the future 7 countries: Equal chances for all employees"
Any Jitsuka here that can tell us more?
How are this stats correlate with odesk/elance and more companies stats? is there a similar trend? what about separate them by industry field? I imagine that financial companies are not hiring that much remote developers.
I'm a remote consultant, and I have no issues getting clients. But, I'm in the USA, and I'm an American citizen. I also have no problem hiring remote workers. My designer is from Canada (I got him through Reddit).
I am from brazil, and I wonder why noone want to hire me remotely (not even in Brazil!).
I just don't understand all those "US-only" hiring.
The two biggest problems are communication, and time delay.
Remote communication just takes a lot more effort - many underestimate the frictions of constantly setting up remote calls (sometimes with poor quality), dealing with any language barriers, proper scheduling ahead of time according to time zones, etc.
Now add engineering into the mix, and things get even more complicated. If there is a time delay, it means you are working at different hours of the day, so if you need a change, maybe it happens 7 hours later.
You have to design your systems to require minimum overlap and proper decoupling, which means more time planning and more architecture.
You also have to assume your engineers are good communicators, and can constantly be working out issues over instant messaging and email.
The last 3 companies I have worked for (one of them a startup I cofounded) I have worked for remotely, I wrote about it http://arandomurl.com/2011/09/03/working-remotely.html
I was actually surprised speaking to a university lecturer today that had no idea companies like Mozilla hired people remotely. I had somewhat taken it for granted as the norm.