Interesting. I interviewed with them once. Their interview process was pretty strange: after a technical round they wanted me to work full-time for them for a week as a next step. Wat? How do I do that if I have a job? Plus, it seemed like they pay their engineers way below the average. Not surprising they are having hard time hiring and had to move on to hiring remote workers.
I also interviewed with them, and they gave me the same offer. I told them that was disrespectful to seasoned engineers, and that they could bone off, and I ended up getting a job at a much more interesting company, so it worked out in the end.
I'm always a bit disheartened when I see misinformation and negativity spiral like this.
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.
"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.
I concur. I've had interactions with that team, and they've all been strange. The engineering and security are buggy and poor, and attempts to get to the bottom of issues are stonewalled and shunted.
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?
> 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.
Those are all very bad reasons to dislike remote engineers. "Remote" doesn't necessarily mean on the other side of the globe; obviously you wouldn't hire remotes for hardware projects; some video conferencing software is better than other; and if you're so jealous of remote workers, maybe you should try your hand at it.
I think people often combine remote with asynchronous. You can have people who work 3PM to midnight in the office, when everyone else is working 9-5 and it can be annoying for communication.
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.
In regards to 1 & 3 it sounds like the problems are more your company than the remote engineers.
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 :)
But in the past year we’ve had a few engineers who needed to move (due to various life events). We didn’t want to lose them, so they became remote employees on our team. In some cases it worked really well.
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.
I've worked remotely for the past year and it has by far been the most productive year of my career as a software engineer. I'm not sure if I will ever want to work in an office again. In my experience, when working in an office environment, people will interrupt you while you're in the middle of writing code. You'll be asked to attend meetings that are ultimately pointless. You'll feel bad about wanting to work from home or from a cafe. The amount of freedom and the feeling of finally being treated like a responsible adult that comes with working remotely is addictive to someone like me who just wants to code all day.
I started working onsite a couple of months ago, after working remotely for two years, and yes it is as bad as you remember. As I'm a contractor I don't even have proper equipment, so I'm stuck with and old broken chair, an old broken table and my 13" laptop vs my setup at home.
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).
In my view, onsite work is only good for two things:
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.
I do remote work and I honestly miss the team building.
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.
I've had nothing but success working remotely on projects. It's all about having communicative remote people, having the onsite team use the same chat/screenshare/video systems. I can get so much done with absolute focus yet still come out for big meetings a few times per year. It gives flexibility to the onsite people to work from home occasionally, too. On a team with poor cohesion or a lot of strong introverts, it might not work.
Kudos to you for embracing the remote culture (partially).
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.
Great move. Love the 'self-starter' bit. People who need to be constantly monitored and told what to do aren't worth it, even if they're easier to hire.
[+] [-] shadow0|10 years ago|reply
[+] [-] colordrops|10 years ago|reply
[+] [-] barmstrong|10 years ago|reply
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.
[+] [-] jph|10 years ago|reply
[+] [-] geomark|10 years ago|reply
[+] [-] jonathankoren|10 years ago|reply
[+] [-] jerguismi|10 years ago|reply
[+] [-] millstone|10 years ago|reply
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?
[+] [-] RyanZAG|10 years ago|reply
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.
[+] [-] scrollaway|10 years ago|reply
[+] [-] nulltype|10 years ago|reply
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.
[+] [-] lucaspiller|10 years ago|reply
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 :)
[+] [-] drawkbox|10 years ago|reply
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.
[+] [-] shawnps|10 years ago|reply
[+] [-] lucaspiller|10 years ago|reply
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).
[+] [-] mpermar|10 years ago|reply
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.
[+] [-] colmvp|10 years ago|reply
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.
[+] [-] iopq|10 years ago|reply
Doesn't mention which languages in the post. Am I supposed to know this?
[+] [-] sergiotapia|10 years ago|reply
[+] [-] ruffrey|10 years ago|reply
[+] [-] phantom_oracle|10 years ago|reply
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.
[+] [-] sanatgersappa|10 years ago|reply
[+] [-] zhte415|10 years ago|reply
[+] [-] navinp1912|10 years ago|reply