Ask HN: What do you look for in a remote developer?

[daryllxd]

I'll be applying for jobs soon. I'm a Rails dev with 4 years exp, currently learning Elixir. I've just created a blog for my future employer and potentially future clients, gotten testimonials from my previous clients, reading interview questions, anything else that I can do to improve my chances/add value to the company I'll be joining?

[DoofusOfDeath]

My background: Worked many years in offices, and the last ~4 years remote.

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.

[lostcolony]

You mention it, but I want to harp on it -

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.

[chasd00]

"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."

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.

[longerthoughts]

As somebody doing this now I am absolutely out of the loop on certain discussions but while it's often challenging, it can actually be helpful in certain cases. Many of my teammates end up being roped into meetings and ad-hoc tasks as backup but ultimately provide little or no input and just waste their time. Meanwhile, I'm protected from a lot of the distracting, low-value work and am left to focus on things I'm leading and anything important enough to be communicated to the group as a broadcast or call to action. Additionally, my group has become so accustomed to working in a way that accommodates remote work that the colocated team members have started working from home more often, encouraging further adjustment to support remote work. That being said, I don't think my arrangement would have been successful without having my manager and a couple of colleagues acting as my advocates on the ground.

[paulryanrogers]

Good management will also avoid including people unnecessarily and encourage a culture where people can depart when it's obvious they're not needed. I tried making an early exit from meetings more acceptable with humor. But ultimately everyone has to buy into the idea.

[sas1ni69]

Where were you when I took my first remote job?! I had the misfortunate of working on a team that was mostly colocated ANDDDDD in a completely different time zone. 11 hours ahead.

North America vs Asia.

Talk about isolation. Don't do it folks.

[Spoom]

IMHO there needs to be at least two hours of overlap for remote teams in different time zones to be feasible. This can work if one of the teams adjusts their schedule to fit, but otherwise it leaves the remote team out in the cold.

[_ea1k]

That is all exactly right. It is really hard to overstate just how important this is.

Even just having one or two workers collocated can create strange cultural problems and weird duplications of work due to communications breakdowns.

[rwagen]

I couldn't second this statement more. I've been on both. Remote with a colocated team is a special kind of hell. You are out of the loop on so much and the isolation is overwhelming.

[timmaah]

Hell? I'm out of the loop a bit for sure, but in two hours when we do our sprint planning.. their backdrop is a tiny windowless office while mine overlooks the pacific ocean.

[ljm]

> They need to understand the challenges posed by distributed teams, particularly if the team isn't entirely remote.

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.

[Zyst]

I’ll be 100% honest even though it might not be applicable for you:

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.

[JBReefer]

Second this - I worked remote for 3 years, and it's a unique skill set. I don't think I could do it again, until I have kids at least - the loneliness and "you're never working, or done working" thing gets weird. I'd need to know someone has already worked through all of that.

[Finbarr]

Our team is entirely remote (mostly contractors currently). Here are the things I look for:

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.

[zachruss92]

This is a pretty good question! When i'm looking to hire this is what I look for: (1) Excellent written and verbal communication. Since there is limited in-person interaction it is paramount that a developer can clearly and effectively communicate about a project/status/whatever.

(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

[thisjustinm]

Strongly agree with this list. Communication, communication, communication.

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).

[arkadiytehgraet]

Unless this is a some kind of deeply sarcastic/ironic answer, I love it as a prime example of how interviewers do not actually know what they are looking for, and most of their questions are just there to reinforce their initial gut feeling about a candidate.

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.

[mping]

Of course you can. Someone may not need oversight, but may need guidance. If I hire the best developer on technology X, he will still need guidance navigating my own problems before fixing X's usage.

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.

[jfaucett]

I'm a Freelancer and work a lot of remote projects. Here's the most important skills.

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.

[kowdermeister]

"Excellent Communication skills"

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?

[jfaucett]

Think of it this way. You are not in the office with the team. You need to actively do as much as possible so no one notices this. This means reading other peoples commits and PRs just to know what everyone is doing. If you had been in the office they would have probably mentioned it in conversation. If someone messages you every 5 minutes you need to discuss that so you can work, just like if someone was interrupting you every 5 minutes in the office. But again, like in the office if its work hours and someone messages you, just like if someone asked you a normal question in the office, then you should answer promptly and be on top of it. You don't wont people to not be able to get in touch with you or not know what you are doing - and this is on you to solve not them.

[ztbrown]

pludge?

[mooreds]

Maybe plow + trudge? I've been on a few projects where that was a valid verb.

[funkymike]

Plunge is probably what was meant.

[mooreds]

So you are really asking two questions:

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!

[colemorrison]

Aside from all of the usual hot fluff, I know some will disagree, but..

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.

[manoa]

At Envoy (https://envoy.com/) we have roughly 33% of our engineering team working out of their homes so I can speak to both what we look for and what we've found that works:

(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/)

[anotheryou]

Yay, you are looking for a dedicated Product Manager. Too bad all your job offers seem to be relatively non-remote (I'm in Europe).

[tmaly]

When I have a side project, and I need remote developer, communication skills are the number one skill I look at. Secondly, I look to see if they can code according to a technical specification.

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.

[CyanLite2]

Most important thing I look for as a manager is the candidate's driving/travel distance to a common location.

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.

[lostcolony]

If it's once a quarter, the cost of a flight + hotel is minimal. An extra $1k a trip (and that's cross country in the US + expensive hotel), for four trips a year, is a drop in the bucket compared to the cost of a developer (especially if they're living in a cheaper area). Driving distance shouldn't be a factor if it's that infrequent; I'd happily pay $4k if I could save even more on salary costs, or if it meant the difference between hiring someone who nails the interview and looks like a great addition, and waiting another month as we keep interviewing.

[maxxxxx]

I think number one is the ability to work independently without constant handholding. But there is also the need for willingness to fit in with what's there already. I had remote developers who got a kind of an ego trip and wrote beautiful software but it used some tech that didn't fit with our code so in the end it was useless.

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.

[moltar]

Ability to work independently is a double-edge sword.

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.

[chasd00]

I've been working remote about 4 years and have managed both good and terrible remote workers.

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.

[systematical]

I disagree. I am consistently doing small things around the house and have been for the past 3 years in my role. I view it as my break time or the time people in the office spend at the ping pong table, talking in the break room, or on social media. No one is 100% productive. We're not machines.

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.

[aikitengu]

I would definitely agree here with @systematical. As a remote worker for about 11 years, at least strictly remote with no office travel (ever), there is a real need for human interaction. Be it at a local coffee shop, or a coworking space. We are more than simple task robots, we are humans.

[cjalmeida]

Seconded. I like to take a break and go to nearby park with a coffeeshop just to see other people. I don't miss office interaction at all and I have good off hours social life.

And discussing tech stuff at HN is better than doing it with "average" peers at work anyway.

[greggarious]

Proactive. You're not having those serendipitous water cooler conversations, so you need to go out of your way to be proactive and think about what work should be done in the future, what issues may arise, and make decisions based on those projections.

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)

[codingdave]

Self-awareness and self-motivation.

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.

[amw]

When we hire (we are a 100% remote company), our questions focus on conflict resolution and communication. We like to be able to see assumption of good faith by default, and red flags are things like "automatically blames X for issue Y" or "constantly says negative things about management they've worked with in the past" (people are definitely allowed to have whatever conflicts and opinions they have, but the red flag is bringing that up as the inherently unsolvable obstacle to happy and/or productive work rather than treating it in the same class as any other work-blocking obstacle). We want people to focus on how issues can be fixed rather than who broke them. We look for signs that someone is comfortable receiving guidance from disembodied words in a chatroom, and willing to proactively ask clarifying questions, as well as to patiently answer clarifying questions from other people. Familiarity with remote-collaboration tools is a plus (the usual list of suspects--git and the fancy website UIs built around it, ticket-tracking software, some form of CRM, and IRC/Slack/Discord/keybase chat/whatever, everyone uses some form of group messaging app and this last thing is a really low bar). If the candidate hasn't worked remotely before, we want to suss out how comfortable they will be not being able to see their workmates in person on a daily or weekly basis, because there are a surprising number of people who aren't chill with that and who don't know it until they try. We want some indication that the person can be productive without someone breathing down their neck, although honestly this shakes out pretty fast (once you're with us, we know your commits and your releases and we're either happy with them or not, whether you spent exactly forty or fifty hours a week on your butt in your home office producing them isn't really relevant).

[simonebrunozzi]

I might sound pedantic, but try to write in correct English:

"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.

[linsomniac]

As someone who ran a company that spent most of 18 years with all employees working remote: The most important thing to me was that workers had the ability to treat it as a job. During interviews I'd ask where they planned to work, if they had an office, if they had a family and if so what their plan was for having an office at home.

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...

[kull]

Background: we are 20 people all remote, 2 years old startup, with employees across US and Europe.

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.

[gesman]

Don’t mention remote. It’s unrelated.

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.

[jdbernard]

In my experience looking for remote positions (in the last few months) it needs to be part of the conversation. It is related because most companies are not going to be open to a new hire going remote unless they have already considered it for the position.

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.

[botskonet]

As a remote senior lead who's hiring developers right now, I'm making a point of telling people whether we'll consider remote or not. Unfortunately my company really wants on-site but given their location and the talent we're after... not happening.

[DoofusOfDeath]

I hope you consider posting your job openings in the upcoming "Who's Hiring".

[botskonet]

I sure did, posted last month too.

[itamarst]

Being able to work independently. You're not being closely supervised, so you want to make sure your resume, and interview, convey your ability to work on your own.

[jcadam]

Name != 'jcadam'

I mean, as far as I can tell. I've been trying to land the mythical 'remote gig' for years.

[mindhash]

In past I have looked for candidates with a bit of experience working remotely.

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.

[sebleon]

Excellent communication and responsiveness. If you’re able to respond to any question on Slack or email within 2min during waking hours, that drastically improves the remote dynamic.

[DoofusOfDeath]

But do you really consider that a reasonable bar to set? I don't think most onsite employees want to be that reachable when they're outside the office.