If you want to build a house and you're not sure how to best build a house you're going to be very cautious hiring someone to build a house because you don't know if their way of building a house is any good, because you don't know how to build a house.
That is a tough problem for a group to solve.
The work trial is no longer required, but it is an option since some candidates really enjoy working with us to get a better sense of what it is like before deciding.
I think it served us really well in the early days but you're right it doesn't work for all people (especially more senior folks). And of course we offer to pay people for the time.
In terms of overall comp, we pay more than 7 out of 10 comparable companies (sub 200 employees, tech, in the bay area) across both cash and equity according to http://conneryconsulting.com/ who we hired to help us with this.
Overall, our hiring process (especially in the early days) was weighted toward not making a bad hire, so this means we missed out on some good people occasionally, but ended up with a stellar team. Given the chance to do this over again, I'd make the same choice.
Finally, I'd suggest reading some of Paul Graham or Sam Altman's advice on this topic, for example: http://blog.samaltman.com/how-to-hire
"Have people audition for roles instead of interviewing for them" "A single bad hire left unfixed for long can kill a company." etc
We definitely didn't have it perfect early on, and still don't, so apologies if you had a negative experience. It is something we are always working on.
1. Time zone differences are very real. A 14 hour difference only allowed for a brief window of reasonable real-time communication. Latency went from seconds to half a day.
2. My project had a hardware component, and we could not easily assist each other with electrical or mechanical issues, or even things like firmware (e.g. "why won't this board boot?")
3. Meetings were worse. Video conferencing often had technical problems, and we'd waste time trying to get it to work. Normal human interaction (body language, nonverbal cues, etc.) was lost. Remotes frequently interrupted, through no fault of their own.
4. I came to resent the remotes for enjoying this unequal perk, one that inflicts a cost on the rest of the team. Why don't they have to sit in traffic and then in this noisy room with the rest of us? What makes them special?
Seriously? Because your working conditions are terrible, remote engineers are bad for having good working conditions? Here's a hint - stop wasting your time hating others for being happy, and work out how to improve your own working conditions into something you enjoy.
I resent my peers being given visibly unequal treatment. It's no different than if some engineers get free lunches and others did not. I guarantee you there's onsite engineers in Coinbase who feel the same way.
As for "improving my own working conditions," that's exactly what I did, by quitting that job and taking one with a co-located team, and I'm much happier because of it.
I like the idea that those are separate things and when people hire remote engineers they should go for engineers in the same time zone or ones who want to work synchronously wherever they are.
[0]: Hardware isn't software. I can see where that might be an issue.
First of all due to the timezone differences I will assume you are US based and outsourced to somewhere in Asia - this alone without the remote working has its own set of challenges (n.b. there is a good comedy TV show "Outsourced" about this). As an example, if someone in India gets stuck doing something they are unlikely to speak up about it until you ask then about it, this isn't because they are lazy or whatever but just because their culture is a lot different to the West. The way you need to work with a team here is a lot different to how you would work with a team in the West - this alone can be the cause of a good chunk of problems that occur when outsourcing.
As your team is remote you can't ask them a question and expect an answer in 10 minutes, but you shouldn't expect this of a onsite engineer either as you'll just ruin their flow. Have daily stand ups at times that work for both teams and discuss any issues after that.
In regards to the communication just use Skype (audio) and get a good microphone. If you don't have a good internet connection or it's not working, just call them on the phone. Companies have been working with distributed teams long before Skype was even invented...
As to 4, well sorry but that's your problem. No one is stopping you from getting a remote job except yourself :)
Google even has a name for this: "defragmenting," where they attempt to reduce the amount of remote work by giving engineers opportunities to move, or to switch to a local project.
I would consider a remote job, but only on a 100% remote team. It's mixed teams that I want to avoid.
I understand how for some people remote just doesn't work, but I think that's mainly because the company doesn't know how to work with remote engineers. The best company I've worked with in terms of remoteness had teams in India (+5.5), Greece (+2), London (+0) and LA (-8).
1. Team building. There is no doubt being around the office is good for socialising and creating stronger bounds.
2. Stronger junior people or people that need direction. Many, many, many developers are only good when they have the superstars around. It's people that need direction and help. Having the stronger workers around make these other average workers stronger.
If your team is made of superstars/hyper-professionals then there is no obvious reason not to be doing remote work. If on the other hand your team is mostly made of regular 9-5 workers, well, not doing remote work must just be the excuse for hiding some other bigger issue in the organisation.
There's an incalculable benefit to me to socialize on a daily basis with a consistent group of people. A great deal of ex-coworkers from non-remote work jobs are still good friends of mine who I communicate on a weekly basis. And it came from gradual and steady interactions. Being remote has made it very hard to build closeness with a lot of the people within the company, especially the newcomers. It's arguable whether or not closeness or friendship is important to a team, but I'll say that I perform better when I personally care about the people I'm working with.
Furthermore, by not being there (while others are) I also miss out on spontaneous information sharing that happens between people in moments like sitting away from the computer, having lunch together, or lining up to wait for something. It's also difficult to participate with small groups who go on-site to observe customer behavior.
I'm not against remote work because the benefits largely outweigh the negatives. It's just after over two years of doing so, I've gradually moved to the belief that I really prefer a split solution where I come into the office once every few days to energize/adjust my connection with the team.
Doesn't mention which languages in the post. Am I supposed to know this?
Remote work is a big part of the future in development. It is a big favorite of developers who are self starters, good communicators and deliverers.
Over time it will take longer to build bigger things and people do indeed move in some cases every couple years for many reasons, doesn't mean they aren't as committed because they can't be within 2 hours of an office. Remote works biggest benefit is keeping a team of professionals on the team even if lives change and locations move, might even be a big advantage to those currently that can do it well.
Every remote capable organization has better communication virtually and better external views of themselves. This is also key for working with clients/customers (almost always remote) and other offices (again remote offices in the same company). Remote work can even improve intra-office communication/information flow as many times even though you go to the office, you work with many people in the building or the building over remotely just closer in vicinity.
However, you should take it a step further and not "fly them out to visit HQ" but instead:
Take the entire team out for some team-building and working from a different locale (you can stick to the US - as most remote-first companies do).
Your company is not exactly the same as the next advertising-eyeballs SV startup, so perhaps getting out of the Silicon Valley hype-train and "pat each other on the back" environment, exploring a different area/wilderness will open your team up to greater innovation and lateral thinking.
See Automattic for a reference-point of how to do it.
