Skip to content

Instantly share code, notes, and snippets.

@idan
Created November 7, 2013 15:28
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save idan/7356486 to your computer and use it in GitHub Desktop.
Save idan/7356486 to your computer and use it in GitHub Desktop.
Getting hired remotely

I’m from Tel Aviv, but my heart is in San Francisco. The vicissitudes of life (my wife, her career, our kids) make it unlikely that I’ll relocate to the bay area now, but I’d like a job with one of the companies I love out there. I’m interviewing with them as an explicitly remote candidate.

I’m still in the thick of the process, but given the topic’s popularity lately (and my fortuitous timing with the release of 37Signals’ book on the subject), I’ve got a few practical observations to share about the process.

The book

I bought my copy via iBooks. I wish they also sold a DRM-free version directly à la O’Reilly, but I digress.

I’m only partway through the book. Much of it seems obvious to me as an open-source hacker comfortable with collaboration over the internet, but I can see that it’s a novel message for straitlaced businesses. Jason and David have a particular talent for distilling this brand of wisdom and packaging it in a form that management types can relate to (and hold up to their bosses as proof that they weren’t doing something reckless).

I’m thinking of buying a few copies and giving them to my contacts at the larger companies I’m scheduled to talk to. Third-party validation might accomplish what I can’t alone.

Size matters

Image: person deciding between garage and office building

Remote is the #1 concern voiced by the larger companies I’m interacting with. They’ve got existing culture and practices in place. They’re worried about my interactions “up” to to the people I report to, and my interactions “down” with the people who would report to me. Changing their default interaction behavior to favor asynchrony is like altering the course of a large ship—not impossible, but it will require a lot of energy and buy-in.

On the other end of the spectrum, I’m speaking with smaller teams of 10-15 people. Often, I’m their first potential hire that isn’t where they are. Universally, they say something to the extent of “We’ve never tried remote before, but you’re a good fit, and we’re having trouble getting the right talent on board.” They’re openminded about the process, and willing to give it a shot, but a key part of the conversation is demonstrating that I’ve done remote work in the past, and demystifying the nitty-gritty of how it could work. They aren’t so much afraid of remote as they simply haven’t pictured how it would work in the context of their business. Being articulate about process and tools is key to making those conversations work.

For these smaller teams, I’d be their “Director of Design” — something I’d be swinging solo at first, but which is expected to rapidly blossom into a proper team in its own right. I’m also finding it important to express that I’m open to relocation down the road, when there’s a clear business case for my being present full-time. Often this is as simple as stating that it’s a conversation that we should have when it becomes obvious that we should have it. Convincing me and my family to move when there’s a business blasting off into the stratosphere right now is much easier than abstract thinking about what needs we might have “someday”.

How and when will we communicate?

Image: phone with wings / envelope with wings in orbit around a clock

Setting clear expectations about communication is also important—because I’m not going to be able to participate in the Friday afternoon (Pacific time) all-hands meeting, which happens in the wee hours of my Saturday.

One of the more observant interviewers I’ve spoken to was also a remote employee previously, and now moved to SF. He hit the nail on the head when he said that remote doesn’t work if the baseline expectation is that I’ll simply sleep on a Pacific Time schedule, and be available like everyone else at the main office. That isn’t compatible with a life, let alone a life with a family.

The high-level explanation that I’ve come to use most often is that remote will work, so long as synchronous communication is not the first tool that people reach for in the toolbox when something requires attention. We reach for conversations when it’s the right tool for the job, not when it would be easier than typing.

I also stress the importance of two rituals:

  1. A set schedule for weekly facetime over skype/hangouts/etc. No matter what, it’s critical to see faces. We are human, and we are wired for empathy. Maintaining those relationships solely through text is more difficult.
  2. Flying me out to the mothership at the start of the job, and every three or four months thereafter.

Part of what makes open-source communications difficult is the lack of empathy. Text alone leaves a lot of room for misunderstanding. Friendships established by spending time together is like an innoculation against those misunderstandings—it’s harder to misread tone when you can hear it in the voice of the person writing to you, and you know their personality. Attending conferences bound me far more tightly to the Django and Python communities than any other single thing. Befriending my coworkers in person is more than just “fun,” it’s strictly necessary in the context of remote work.

It’s a leap of faith

In the end, large or small, working remote is a leap of faith for both employer and employed. Recognize that in your conversations with them. Don’t shy away from setting the important expectations, but a healthy dose of optimism is essential too. For people to take a leap of faith with you, it’s important to broadcast conviction—not just that remote can work, but that it will. It sounds silly, but I don’t think my conversations would go as well as they are without winning over hearts as well as minds.

And who knows, maybe the next time I’m in the market, remote will be in vogue, and I’ll need to spend less energy on that aspect of getting hired.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment