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:
- How do I find companies that hire remotely?
- How do I figure out if they support their remote workers well?
- How do I develop the skills needed to succeed as a remote worker?
- How do I appeal to remote-friendly companies?
Today we'll look at these questions in depth! This post is part 2.
- Part 2: Finding your first remote job
Link to this headingFinding remote options
Alright, step 1: How do we even find remote jobs?
There are a number of ways:
- Remote job boards, like Remote OK,
- "Big lists", like this Github repo, and this ginormous Google Sheet
- HackerNews' Who's Hiring posts (Protip: do a page-wide search for 'remote' to jump through remote-friendly ones).
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 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 course of a couple years, I built up a list of 15-20 companies which seemed to offer remote-friendly policies, just by paying attention on Twitter!
Link to this headingEvaluating remote-friendliness
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.
Link to this headingLevel of distribution
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 1 of this series, you've seen that I've run into a few problems in my remote career:
- Meeting-room video-conferencing stress
- Career progression challenges
- Communication problems
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.
Link to this headingRemote integration
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 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.
Link to this headingMeetings
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:
- A remote champion can be designated. This in-office person is responsible for keeping an eye on the chat, and interjecting if it looks like a remote participant has something to say, and making sure to explicitly check in with remote folks every few minutes for comments.
- Everyone in the meeting can call in from their own device. This way, even if folks are in the same room together, they're all communicating through a screen, same as remote participants. This can level the playing field a bit.
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.
Link to this headingGetting the team together
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.
Link to this headingWorking hours
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.
Link to this headingInternational work
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:
- The company can set up a Canadian subsidiary. This is often a very thin construct—just some paperwork and a PO Box—but it allows the organization to hire Canadians as employees: payroll income tax is deducted, health benefits can be provided, and the employer must abide by Canadian labor laws, like providing a minimum amount of annual vacation days. It's the same thing as working for a Canadian company.
- The company can hire international workers as contractors. Workers bill the company for their time, and don't enjoy any of the legal protections and benefits afforded to full-time employees. It can also make income taxes more complicated, though it does come with some tax benefits as well, such as having access to a wider set of deductions.
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.
Link to this headingRemote benefits
There can be additional costs associated with remote work:
- If you wish to work from a co-working space or office, there is monthly rent
- Remote workers don't benefit from catered lunches or in-office snacks
- Remote workers will need to furnish a workstation (keyboard/mouse, monitor, etc)
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, a company I used to work for had the following remote-specific benefits:
- Fully-paid co-working or office costs
- A $500 stipend to set up your workspace
- A $3500 reimbursement for a work laptop
- Home internet and cell phone reimbursements
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.
Link to this headingDeveloping and demonstrating remote skills
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?
Link to this headingOpen source work
A lot of popular community-run projects are built entirely by volunteers in their spare time. This system is kinda problematic, but it actually works kinda well for our purposes:
- Projects are often looking for help. Many maintainers are thrilled when folks offer to contribute!
- Open-source work involves a ton of collaboration, and this is always done remotely, often asynchronously. You'll need to coordinate with others to figure out how to solve a particular problem.
- Open-source work happens in public. These conversations are accessible to anybody, and you can share links to successful issues and PRs as a way to demonstrate your remote-work skills.
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 Aphrodite in a side-project. I found an open issue, with a feature I needed, and collaborated with the team to come up with a suitable API. The resulting 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 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.
Link to this headingRemote experience at your current employer
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 many, many, many articles have been written on the subject. I suspect it's more feasible than you might think, if you haven't tried it yet.
Link to this headingLearning in public
Being a developer means that we're in a constant state of discovering new things. The idea with learning 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.
Link to this headingPersonal Networks
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.
Link to this headingContracts
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 Toptal 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.
Link to this headingWork experience in general
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.
Link to this headingConclusion
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 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!