Understand that companies hiring remote developers, especially for the first time, might not be aware of things they need to do for success. These include:
(1) The manager needs to be above-standard.
(2) They need to be ready to treat communications challenges as first-order, high-priority problems.
(3) They need someone onsite who will advocate for you, particularly w.r.t. challenges that are specific to you working remotely.
(4) They need to understand the challenges posed by distributed teams, particularly if the team isn't entirely remote.
As far as what you can do, I'd suggest:
(1) Learn everything you can about the challenges of being a remote employee.
(2) Address those challenges as best you can at your end.
(3) Be ready to educate your employer about those challenges as well.
(4) Recognize that the employer just might be incapable of properly handling a remote employee. I'd suggest screening employers carefully if possible, and be prepared to move on to another job if they're not able to do what they need to do to make remote work.
There is a huge, huge difference between being a remote employee on a mostly colocated team, and a fully distributed team.
I would NOT take a job that had me be remote to a colocated team, unless you have experience doing that, and the team in question has experience with remote members already.
Transitioning from an onsite to a remote role on the same team is different, as you already have carved out what expectations you have with your team, and going remote doesn't change those. But starting out like that makes it so only -you- have the communication difficulties. That conversation that changed all the priorities this sprint that happened in a hallway? You missed it. No one thought to tell you. Etc. That sort of thing -happens-, and it's very hard to solve.
A fully remote team, however, hard as it may be, at least doesn't suffer from that. Everyone -has- to be cognizant of who is involved in a conversation; every conversation requires a bit of effort, be it on Slack, email, the phone, video conferencing, etc. That little extra effort that is required for any conversation ensures all the relevant parties get looped in (unlike a conversation at someone's desk or in the hallway).
That's huge.
So, if you haven't worked remotely before, look for a fully remote team, or look to transition from a colocated job to a remote one. I would seriously consider staying clear of being a remote employee on a colocated team.
North America vs Asia.
Talk about isolation. Don't do it folks.
yes! That is very good point and can't be overstated. Being the only remote worker on an otherwise face-to-face team takes an almost peerless manager and team. Even if it starts off well i've seen it devolve to where the remote team member is left out of all discussion and becomes just a place to park tasks.
Even just having one or two workers collocated can create strange cultural problems and weird duplications of work due to communications breakdowns.
Out of all of the fantastic points listed this is by far the most critical because it most likely will be the root of every other problem.
The thing is, it's not entirely the challenge of being distributed, it's the challenge of having an inconsistent team dynamic where the needs of the colocated team members aren't aligned with the needs of the distributed members. Without strong leadership, discipline and culture it's all too easy to try and patch over the communication and collaboration issues with all kinds of workflows, Slack bots, and tools that ignore the essense of an interpersonal problem and turn it into a technical one.
For example (in my own experience):
- The expectations around availability aren't clear so individual flexibility takes priority over team flexibility and it's hard to set some healthy boundaries on it (e.g. remote or not the team wants to hear how it's going at 10.30 to see if expectations for delivery need to be adjusted)
- There may be an isolated/individualistic mentality where you're building code on a production line (which is counter-productive for budding startups that need business/dev collab)
- Colocated colleagues are privy to far more information than remote colleagues unless they remember to share it in public channels (e.g. Slack), _or_ it's all done through private channels and nobody is on the same page about anything
- Half your work day is scanning productivity tools for updates (github, jira/pivotal/asana/trello, dropbox, slack integrations) instead of having a conversation
- The remote side will almost _always_ be scapegoated or be the reason for something being more difficult than it normally would be
- There might be an absense of serendipity that makes the space for creative and interactive problem solving because the connections aren't quite there for it
It's pretty much the sort of thing that becomes a problem once the team or company matures beyond petty blame and starts to treat the remote part of the team as first class. The issue in a nutshell is that you might initially be dealing with an over-correction so rather than striking the balance that gets the team working well together whether they're in the office or not, you get one that stifles colocated activity.
The fact it happens to be a clash of remote and colocated dynamics is irrelevant, it's the failure of leadership to bring the team together as one while also respecting its occasionally incompatible requirements that's important.
One of the most valuable things I look for is someone who has already worked remotely.
From my personal point of view not everyone is suited to doing remote work.
* Some people cannot work up the motivation to get stuff done when the bar for others realizing they are slacking off is a lot higher.
* Some people realize they miss the meatspace interaction and decide to quit after three months which you mostly spent ramping them up, so not quite their full potential.
* And some others realize they cannot really focus at home for a plethora of reasons.
Anyway, hiring someone with no remote experience always feels like a risk. Perhaps you could find a way to assuage those concerns, and improve your chances that way.
1) Productivity. Is this person working and getting things done? Can I rely on them and trust them?
2) Quality. Is the work being done to a satisfactory standard?
3) Communication. Can this person speak English well enough?
For number 1, do you have a github profile with private contributions showing? It's the first thing I look at when talking to anyone. If you have a wall of blank, I'm immediately less interested. Obviously there are false negatives here, but there are so many candidates that it's easier to just move on to people who look productive. Other things I look for here are positive reviews on sites like Upwork or good tenure at previous positions.
For number 2, we typically hire very quickly and just give people test tasks. If they are completed well, we keep on giving more test tasks. Eventually the tasks become much larger.
For number 3, this is really simple. If the writing is good, then I'd look to have a video call and see how good the verbal English is.
(2) Asks lots of questions. Builds off of communication.
(3) Be a self-starter/self-motivator. Supervision is very low, so I need to make sure someone can get started/done without a ton of oversight.
(4) Knows how to ask for help. Don't be shy about not knowing something and getting stuck. Sometimes it's better to ask someone for help rather than trying to brute force the issue yourself.
Edit: formatting
How can points 2 and 3 even remotely co-exist? They are like completely opposite of each other! You by definition cannot be a self-starter and get work done without oversight, if you require to ask a lot of questions to do anything. Yes, it is always helpful to ask clarifying questions whenever you are not sure about something (and sometimes even when you are sure), but this is like the very opposite of a lack of oversight.
Now you may try to clarify whatever you meant, but, oh no, that would mean that you yourself cannot communicate effectively about what you are actually looking for and what you mean, which makes the first point very vague as well.
Also bear in mind that initially you will need some orientation, but the expectation is that you will progress to self starter.
And finally, a good communicator doesn't really need to communicate well all the time.
When I'm hiring for my remote team I look for communication skills as #1. It's much easier to mentor or get training for someone who lacks some particular technical skill than it is to get someone to pick up a different style of communication.
And to address the other reply saying that 2 and 3 are opposite of each other (even though arkadiytehgraet's tone is mean-spirited I think it deserves clarification) - self-starter is not necessarily about _knowing_ but rather _doing_. An example would be a developer who comes to me and says, "I started working on task X and noticed that it could have an effect on how we store things in the DB so I went and talked to Bob since he's the most knowledgable there and we came up with solution Y and I wanted to run it by you before I start since it differs slightly from what was outlined in the task and may have several other ramifications..."
In this example the developer has taken the lead on their task without relying on constant hand holding or specific direction and has come back with a well thought out and researched solution and _now_ they have some questions.
Put another way, self-starters can take vague or partially defined tasks and come back with a well defined task and lots of questions (which are often the _result_ of the process they went through to better define the task).
1. Clear communicator. Get in front of and clarify issues so you dont waste anyones time.
2. You get things done on your own. You dont waste time on irrelevant stuff, but you constantly pludge forward getting stuff on the agenda done, without anyone having to watch over you / motivate you.
3. Excellent Communication skills. Did I alread mention that? Ita that important. You better be able to clearly communicate and be able to manage sending emails, answering chats promptly, etc.
This sounds like a perfect candidate to the Dunning–Kruger effect. While one might know that they are poor communicators, this does not really come up until you are out of your comfort zone.
Can you elaborate on this?
Is there a thing like over-sharing? If somebody is constantly writing walls of texts on slack or "tweeting" every 15 minutes about their progress is good thing or can this be too much?
How can I improve my chance of being hired?
And, if I am hired, how can I improve my chance of success at the company.
I will defer answering question #1 to folks who have hired plenty of remote devs (I have only hired a few).
For question #2, I have a few things to say, based on my experience as a remote developer and observations of others. Many of these are predicated on working for a company where remote work is not normal.
1. Set expectations. This will be a conversation between you and your manager. Depending on how experienced the manager is, you may or may not be driving the conversation. But have it either way. This will include things like:
How is status communicated?
Are there core hours of availability I need to keep?
What are the best tools to use fot asynchronous and synchronous communication?
Can we set up a regular meeting to check in about my remote work performance?
2. Be proactive. Proactive about communication. About your work. About making sure your manager or lead knows what you have done and are doing. Don't let any needed question go unanswered.
3. Perform above average, at least for the first 6 months. This is important when starting any job, but especially when you aren't there. This means being on time to every meeting, going above and beyond in helping other team members and in general bringing your A game. This will pay dividends when your situation comes up in future management discussions.
4. Be prepared to ask a lot of questions. Discussions will happen without you, and you need to be able to confidently ask how decisions were arrived at. If possible, document how the decisions were arrived st (Google docs, slack). This discipline will benefit everyone, but is easy to slack on when everyone is onsite.
5. Be prepared to have a slower career trajectory. Even for remote friendly companies, management is typically a onsite function (unless the company is 100% remote, of course).
I love my remote commute (roll out of bed, walk a few feet to the office). Good luck!
a) open source activity b) github activity c) active blogging on knowledge or topic related to dev
The reason? Remote work takes a lot of independent work (obviously). And external activity from just a job is a great signal that "hey they like this enough to do it in their own time." This indicates that their interest goes beyond just what they're getting paid for.
I know, I know. "But that's not necessarily a great indicator!"
When you're on a big time crunch to fill the role, and you have 100s of folks to look through, you've got to filter somehow. And quite frankly things like this are going to be far more proving than just "well I have nothing up because it was all company work so I can't show you" or "I have a life outside of coding" etc etc.
(1) High I/O. Communication between folks on and offsite can be lower bandwidth due to tech, not always face to face or synchronous, and fewer serendipitous interactions. You need folks who love hearing from and reaching out to people, such that they have a bias to compensate for these limitations.
(2) Overlapping time zones. Related to above.
(3) Fully formed, mature human beings. Related to above.
(4) Evidence they've been effective doing it. Not everyone can self-manage and motivate. I, for one, suck at it.
(5) Working experience. It's harder to have less-experienced folks tether to teams in other locations, because by nature they need much more communication both ways.
As a bonus, here's what you should look out for when seeking your next team:
(a) The same stuff as above :)
(b) Unintentional biases. Ask when the meetings are scheduled. What tech they use to "dial in" folks. Unclear differentiation in comp, benefits, etc. (it may be different by location, but there should be a methodology behind it) Even clues like heavy use of the word "remote" (which sounds 2nd class) vs something like "distributed".
(shameless plug, we're hiring. https://envoy.com/jobs/)
There have been countless times where I have had to spend excess time going back and forth due to lack of these two skills.
Your situation might be a little different if your employer is not someone who can write technical specifications. If this is the case, I would say the skill of translating the customers requirements into a specification would be an important skill.
Example: If the job's main HQ is in Atlanta, you can work remote and live in Tennessee, Alabama, Florida, Georgia, etc. If we're having a new kickoff meeting and we need everybody to be on site for an in-person meeting, then a short 2-3 hour drive can solve a ton of issues.
Upper management gets to see real live people tackle a project. (If you think your CFO isn't internally questioning spending 6 figures on a remote developer then you haven't spent enough time with him/her). It also builds rapport with the rest of the team. For the remote folks, after working in a house for so long it can start to feel like a prison, and a road trip is a good excuse to get out of the house. I also work remote, so when I travel it's actually a good break during the day.
And we don't do it often. Perhaps once a quarter or so.
It's really important to listen a lot and understand current processes first before you try to add some innovation.
Be willing to clarify things a lot and if you go the wrong direction be willing to drop your work without hard feelings.
I’ve been in situations where independence was communicated to be desired. Yet CTO was a micro-manager and very nit picky during code reviews. This kind of approach backfired and I ended up asking a lot of questions and consulting them on every decision to make sure I don’t waste time writing things that were not up to his unwritten/uncommunicated standard.
You have to position yourself as someone who can handle working remotely. Some otherwise great people just can't do it very well, no knock on them, it's just the way some people are wired.
Join a coworking place and put that in your blog. That says to an employer even though this person is remote they appreciate a workspace separate from their personal life. Intermingling work and personal life, even trivial things like folding a load of laundry over lunch, only leads to problems.
Also, say up front that you're up to traveling from time to time to meet face to face. I try to spend about 4 days a month at corporate having lunch and coffee with the people i chat with on slack all day. It goes a long way both for them and for me.
As for coworking spaces. I am only now joining one because after 3 years I am beginning to get a bit lonely. The one I am looking also has a ton of other benefits like an onsite gym.
And discussing tech stuff at HN is better than doing it with "average" peers at work anyway.
This can take the form of brainstorming potential future features/issues, but it can also be as simple as trying to schedule quick 1:1s with coworkers to allow for unstructured verbal conversation.
(Personally I don't think Slack/IRC allow for the same sort of interaction as a verbal conversation)
I worked for 5 years in a fully remote company, and every single new hire spent a few months iterating and tweaking their own work life -- their office setup, working hours, home life, etc. You have to be able to do that, and manage yourself in general, to be effective. There is nobody there telling you how or when to work, when to relax, when to slack off or not, etc.
Everything else can be practiced and learned, but to be remote it is a fundamental requirement to have the ability to manage thyself.
"reading interview questions, anything else that I can do to improve my chances/add value to the company I'll be joining?" -> there should be a ; after "questions", or even better a full stop and a new sentence.
As an employer, I value your grammatical skills as much as your coding skills. I believe that the two go hand in hand.
For example, I had one employee that I spent a significant amount of time over nearly a year trying to help with his performance. The situation seemed to be that his stay-at-home wife just wouldn't respect that he was "at work". One of our discussions he said "My office currently doesn't have a door on it, and she's always coming in to ask me questions."
But, of course, just being at an office doesn't mean the job will be treated seriously. Another co-worker would do maybe an hour of work a day, and spend the rest of the time dicking around on the Internet. Actually, I'd say this described the bulk of my co-workers when I was at the phone company...
The key is a great communication. You need to show you can easily communicate via emails, slack, video. And I mean: being quick to reply, never keep unanswered questions, be proactive and be able to write and say your thoughts and difficult concepts is simple language.
Example: after the interview, send a follow up email to the interviewer. Send me daily updates on the status of the project even if I did not ask.
What you need to convey is low risk and high fidelity service that you deliver.
All with constant communication.
Make employers realize that requiring someone to sit on their local chair can mean more risk and less quality to them then to hire you.
For example: at one company I talked with the dev lead/manager was 100% remote, so I assumed it was at least a possibility and didn't directly address being remote until I got to the last round of interviews. Ultimately they passed because "we have no doubt of your ability but we want people in the (open) office regularly."
Mentioning it at the beginning would have saved us both time.
I mean, as far as I can tell. I've been trying to land the mythical 'remote gig' for years.
If you have never done this, you could partner with someone (from different location) on a side project. Product hunt community has a slack channel for finding people.