It's been about 3 years since I quit my traditional in-office job and started working from a co-working space for a remote-friendly company. In that time I've gotten a lot of questions from folks about it, and the most common questions tend to focus on how to get started as a remote worker.
"How do I get a remote job" has quite a few facets, including:
Today we'll look at these questions in depth! This post is part 2 of 3.
Alright, step 1: How do we even find remote jobs?
There are a number of ways:
These methods excel at quantity, but to be honest, I've never had much success with them. I'm sure that many of these organizations are wonderful, but it's a bit overwhelming to me. Feels like looking for a needle in a haystack.
Instead, I've had more success by keeping an eye open, and doing my own research. I'm active on Twitteractive on Twitter - when someone shares that they're working on something cool, I'll check out their profile, see where they work, and research that company. When I stumble upon a cool product in my day-to-day life, I'll do the same. Over the past few years I've come up with a list of companies with friendly remote policies:
Note: this isn't really an endorsement of any of these companies (I don't actually know very much about what it's like to work at Mozilla, for example). Rather, these companies are ones that I believe could be a good fit, in terms of remote policy, tech stack, culture, etc.
You should start curating your own list, based on the things that matter to you!
It's very easy for companies to add "remote work" as a keyword to a job listing, but it's much harder for companies to create policies and culture that treat remote workers well.
This section looks at how to evaluate a company from the perspective of a remote worker.
The first question I always ask when trying to evaluate an organization: what % of the company is remote?
If the company only has one or two remote workers, it's almost a guarantee that all elements of the culture are biased for in-office workers. These kinds of arrangements can still work, but it's a much steeper hill to climb. By contrast, some organizations are fully distributed - they have no head office, every employee works from their own environment. Entire categories of problems evaporate with this kind of arrangement.
If you've read Part 1Part 1 of this series, you've seen that I've run into a few problems in my remote career:
These issues (and many others!) tend to disappear as an organization moves further towards the "distributed" end of the spectrum. It's hard to overstate the importance of finding an organization that is more remote than not, especially for first-time remote workers.
A bonus question you can ask: is the company remote-friendly "all the way up"? Are there members of the exec team working remotely, or is it only individual contributors who work remotely? In my experience, it's a bit of a yellow flag if remote workers aren't spread across the org chart, including management and senior leadership.
If the company is not fully distributed, it's important to figure out whether remote work is treated as a first-class concern, or whether it's an afterthought. When designing company policies, are remote workers top-of-mind? Is remote work a core part of the culture?
If a company has a public handbook / onboarding doc, it's worth looking through. Glitch's handbook, for example, has an entire sectionentire section dedicated to distributed work, and references to remote work are sprinkled throughout the handbook:
"We are a proudly distributed team, so the way we communicate shapes our shared virtual workplace. In order to work effectively across multiple teams, we narrate our work so that our colleagues and customers understand what decisions we are making and why. This means sharing mistakes and lessons with one another to encourage accountability and welcome feedback."
If a company doesn't have public documents like this, you can probably get a sense peripherally by asking questions around communication and workflow. Remote work should come up naturally in conversation quite a bit.
If a company is 50% remote, it means that a 10-person meeting will typically include 5 people in the same space, and 5 folks calling in. This can produce an awkward dynamic, where the employees in the same room are more likely to talk with each other. If there are no lulls in the conversation, it can be hard to jump in as a remote participant.
There are a couple strategies for mitigating this:
The first solution is dependent on having someone who doesn't mind playing that role; crucially, this should be a volunteer position, since it would be cruel to foist it upon someone with social anxiety.
The second solution can greatly increases the load placed on the network; if there are 5 in-office participants, it requires 5 times the amount of bandwidth! This is a non-trivial problem for the company to solve, and it's exactly the kind of strong signal I'm looking for; companies should be willing to solve stuff like this for their remote employees!
I'm always sure to ask remote companies how they make sure remote folks are included in the conversation in meetings. I don't expect companies to have a perfect solution, but I do expect them to have thought about this problem, and made some kind of effort to address it.
A common misconception around remote work is that it's a solo activity. In my experience, it involves a ton of collaboration! Even though I'm not in the same space as my co-workers, I still need to collaborate with product and design to hash out implementation details, or pair-program with another developer to figure out a gnarly problem.
This kind of collaboration is easiest when you have a personal relationship with your co-workers, and it's easiest to develop that kind of relationship in person. For this reason, it's important that companies have regular opportunities for the whole team to meet and hang out in "real life".
Be sure to ask whether the company values these kinds of interactions, through regular team offsites, or a flexible policy around visiting HQ. Ideally the company won't have a limit on how often employees can visit, but if there is a maximum, it should be 3x a year or higher. A remote-friendly company will recognize the value that in-person team-building can have on the workforce.
One of the trickiest parts about working on a distributed team is that not everyone is in the same timezone. This presents a challenge around scheduling meetings; how do you ensure you aren't scheduling a meeting during someone's dinner, or at the crack of dawn?
Some companies restrict remote work to a somewhat narrow band. For example, some companies only hire folks working within primary North American timezones, which represents a 3-hour range. Then, a policy ensures that meetings can only be scheduled during the 5 hours of overlap (between 9am and 2pm for west-coast folks, which is 12pm to 5pm for those on the east-coast). This felt like a fair policy to me.
If the company hires globally, this gets a lot more challenging; there aren't any hours of overlap in the workday between folks in California and folks in Berlin, for example. It's all well and good to put more emphasis on asynchronous communication, but it's harder to work effectively without ever being able to speak to someone over a video call.
For information-sharing meetings - all-hands, trainings, etc - this can be solved by scheduling duplicate meetings (eg. one for Europe timezones, one for North American timezones).
When interviewing, be sure to ask which hours of the day are "fair game" for meetings, and be sure that the answer is something you're comfortable with.
I'm Canadian, and I've worked for 3 American companies. Happily, this doesn't involve any sort of US VISA.
There are two ways that this kind of work can be structured:
Going the subsidiary route can be a pretty tall order for companies, especially for smaller orgs who don't have a ton of Canadian employees. For fully international companies, it becomes untenable, since every country has their own complicated set of laws and restrictions.
For a lot of people, the contractor route is a deal-breaker. Companies are rarely forthcoming with this information, so it's best to ask upfront. You don't want to make it through a grueling gauntlet of interviews only to learn that you're not comfortable with the logistics of the offer.
There can be additional costs associated with remote work:
While perks generally aren't the most important aspect to a job offer, I consider it a good sign if a company has perks specifically for remote employees. For example, I work for Gatsby (we're hiring!we're hiring!), and our remote-specific benefits include:
It can be disappointing to see how few companies will cover the costs of renting an office—more than anything, my workspace affects my productivity, and it seems like such an obvious win to me!
Some companies cover a portion of the expense (eg. "Up to $250 a month"), and that's cool too. If the company isn't willing to provide any sort of reimbursement, I'd consider it a yellow flag.
Also, tangentially related: some companies will list "remote work" as a perk or benefit. Depending on the tone, this can trigger my spidey-sense. It's a yellow flag to me if the company sees remote work as a kindness they bestow, alongside gym memberships and catered breakfasts.
For the past year or so, I've had the privilege of working with a local coding bootcamp. One of the things I do is career coaching; I help recent graduates land their first job.
The most common obstacle they face is the chicken-and-egg problem: to get a job, you need experience... But to get experience, you need a job.
This catch-22 has a remote equivalent as well; remote-friendly companies want to hire employees that are skilled at working remotely, and prior experience is the best sign that one has that skillset.
How do we develop this skillset without that experience? And how do we showcase it to prospective employers?
A lot of popular community-run projects are built entirely by volunteers in their spare time. This system is kinda problematickinda problematic, but it actually works kinda well for our purposes:
In fact, this played a pretty big part in how I got my first remote job at Khan Academy! KA maintains a number of open-source projects, and I had been using AphroditeAphrodite in a side-project. I found an open issuean open issue, with a feature I needed, and collaborated with the team to come up with a suitable API. The resulting PRresulting PR got merged quickly, and the feature made it out in the next release!
In my final interview with Khan Academy, this contribution was highlighted by my interviewer. I suspect I might not have made it that far in the interview process without it (I sorta bombed one of the technical interviews 😅).
When people talk about the skills needed to be a successful remote worker, communication skills are usually at the top of the list. When working remotely, you need to collaborate with multiple stakeholders, folks who might be working from different corners of the planet. Being able to package your thoughts into clear, concise messages is absolutely critical.
Not all companies have open-source projects like Khan Academy does, but that part isn't critical; any open-source work you do is valuable, just be sure to talk about it in your interviews!
If you're looking to get started in open-source, Kent C. Dodds has a wonderful, free Egghead coursewonderful, free Egghead course on the subject!
It's unfortunate and unfair that contributing to open-source can be a "ticket" into remote work, since not everyone has the privilege to spend their nights/weekends hacking on side-projects. The sad reality, though, is that just about any sort of job hunt will require time outside of working hours. I don't know of any way around that, and I think this is maybe the best way to spend that time.
If you currently work in-office, you might be able to negotiate the ability to work from home occasionally. Some people work from home one or two days a week, and commute to the office the rest of the time.
The thing about these arrangements is that they tend to be at companies that aren't set up to be very remote-friendly. There generally isn't much of an effort to push communication to Slack, or to make sure that remote participants are included in meetings.
In a way, though, this experience is super valuable. When you interview with a remote-friendly company, you'll be able to share the struggles with your previous arrangement, and how you overcame them. If you can successfully figure out remote work in an environment not designed for it, imagine how successful you'll be when distributed work is baked into the policies and culture.
I have personally never tried to negotiate a partially-remote arrangement, but manymany, manymany, manymany articles have been written on the subject. I suspect it's more feasible than you might think, if you haven't tried it yet.
Being a developer means that we're in a constant state of discovering new things. The idea with learning in publiclearning in public is that you document those discoveries, in the form of blog posts, tutorials, meetup talks, podcasts, whatever.
Two of the most important skillsets for remote work are:
We've already looked at why communication is important for remote work, but it's hard to overstate: being able to distill thoughts into words that are easy to understand is a critical part of working remotely, where a lot of communication happens over Slack.
Passion is important because of the inherent flexibility and freedom that comes from working remotely. If someone is relatively indifferent to the work they do, it might be harder for them to find the motivation to work when nobody's watching.
Again, this is something that assumes a certain amount of privilege, since your current employer probably won't let you write blog posts while "on the clock". But I believe it's an effective way to get on a remote company's radar.
If you've been working as a software developer for a few years or longer, you've likely made many connections with folks who have moved on to other jobs. As remote work becomes more common, it might be more likely than you think that some of those connections are working remotely now!
Scroll through your LinkedIn rolodex, and see where your former peers are working nowadays. If you find a good remote-friendly company, an internal referral can make a huge difference in the likelihood of getting an offer.
I have a friend who took a totally different path to remote work, but wound up in a very similar situation: he used a contract agency to place him in a remote job.
Websites like ToptalToptal broker deals between companies and "freelance" developers. I'm sure that these contracts come in all shapes and sizes, but some of them look an awful lot like traditional remote work - collaborating on a team to ship features! Often, these contracts evolve into full-time positions, so this can be a very effective strategy.
The thing about remote work is that it's often not that different from in-office work; if you're an intermediate or senior dev with a few years of experience, you might not face the same kind of uphill battle.
Conversely, if you're just starting your career, you might find it very difficult indeed to find a remote job. I think a more realistic goal is to shoot for getting a remote job in a year or two, and to spend that time following the steps above to set yourself up for success. If your situation allows, you can start contributing to open-source, start learning in public, and try and negotiate a weekly work-from-home day.
This post covers a few different strategies to get that first remote job - hopefully there were some ideas in here that you can use to formulate a game plan and land that first gig!
Any thoughts or questions? The next post in this series will be a "Twiter mailbag" post, so I'd love to hear your feedback, whether there's something I didn't address, or something that's different from your own experience. Tweet at meTweet at me and I'll do my best to respond in that subsequent blog post!
I've already collected some great questions that didn't fit in this post, and I'm excited to dive deeper into some stuff =) be sure to subscribe to the newsletter, so you don't miss it: