
How to Hire and Build a Remote Team - WadeF
https://zapier.com/blog/how-to-hire-remote-team/
======
zackmorris
Great list. One thing I want to add/emphasize is to consider the remote
worker's motivations.

I'm personally not driven by money (it's just a means to an end). So a
shortcut to getting bites on a job posting is to understand that there are
people working in your field who may very much like to work with you. But they
are deterred by past experiences in the office that drove them to work
remotely in the first place.

Here are a few things to consider with freelancers:

* They are often most productive outside normal work hours

* Roughly half their time is spent doing research and keeping up with the latest trends

* They probably left the workplace to bootstrap their own startup someday

* Their productivity usually goes down if they are on call or interrupted often

* Beware loose specs and feature creep or you might burn them out and lose them

* Their productivity is limited more by time and money than challenge

* Sometimes they solve problems completely differently than you imagined and that’s ok

* Their short game might stink in some areas so balance them with administrators that take care of formalities

* Self-actualization can be more important for them than recognition

* Perks and benefits probably aren’t in their vocabularies unless they have families to support

By them I mean me, so YMMV..

~~~
lotharbot
> _" consider the remote worker's motivations."_

For example: I love where I live and I'm not leaving. I own the house where I
was raised. My grandparents are within walking distance. My parents, some
siblings, and other assorted relatives live in this city, and my wife's family
is within an easy day's travel. It's got my favorite sports teams, the church
of my childhood, beautiful outdoor spaces, an excellent school for my son
right down the street...

So I'm not motivated by your company's "great location" in the NY, SF, or
Boston area; in fact that's a deal breaker for my family [0]. I'm not
motivated by a 50% higher paycheck, most of which would be eaten up by higher
taxes and cost of living and flying out here several times a year to be with
family. I'm not motivated by a "hip" project that helps people go clubbing or
hook up or share more selfies or other things that aren't really interesting
to me in my current life stage. If that's your company, target other
developers -- but if that's _not_ your company, and you market yourselves like
it is, you might lose me. One of my biggest motivations is being able to stay
where I am and live a nice quiet comfortable life with my family.

The best fit is a hard challenge with clear requirements that requires
expertise in multiple programming languages and paradigms, graduate-level
mathematics or logic skills, ongoing learning and self-development/reflection,
and that would benefit from long uninterrupted stretches of focus at whatever
time of day is most convenient (might be 8pm-4am sometimes.)

[0] I'm a stay-at-home dad; my wife just started a new remote position. You
can think of this section of the post as written from our joint perspective.

~~~
syntern
This.

Also, I'm curious: how do you look for remote positions?

~~~
toomuchtodo
[https://weworkremotely.com](https://weworkremotely.com)

[https://careers.stackoverflow.com/jobs/remote](https://careers.stackoverflow.com/jobs/remote)

[http://nomadjobs.io/](http://nomadjobs.io/)

~~~
up_and_up
[http://www.authenticjobs.com](http://www.authenticjobs.com) has a remote
search option.

There's also [http://www.jobmote.com](http://www.jobmote.com) which seems to
be a decent aggregated list.

I actually found a great remote job off of jobs.github.com. The job was listed
with the location `anywhere`

------
joesmo
> Also, in the job posting, ask them to apply in a unique way—don't just ask
> for resumes. Instead, try to make the application process prove their
> abilities for the job.

I can't think of a quicker way to turn down top applicants, at least in
software, than asking upfront for work that is likely to be rejected. Even the
custom contact forms on companies' websites are a drudge to fill in and
usually not worth it. Candidates know this and won't bother. The best approach
is to have a connect with LinkedIn or just a simple email that can receive
resumes. Anything else might make it slightly easier for the company at the
expense of losing out on qualified applicant.

~~~
joncalhoun
This comes up often on HN and I feel like most people who make these comment
are missing the point.

Interviews are rarely about finding all of the top notch candidates. They are
about finding N candidates who are a good fit. That's it. Doesn't have to be
the best developer or best communicator, they just have to meet the needs of
the position.

If one of Zapier's requirements is "you must really want to work at Zapier"
then this is a perfect filter. It weeds out developers who are just looking at
job openings, and only candidates who are excited about working there will
apply. It doesn't matter if they miss 10k great ccandidates. They just need to
find enough to fill their open positions

~~~
joesmo
This is advice to other companies not just Zapier. How can one be excited to
work for a company the know nothing about? Maybe for a company like Google,
but even then, you still have no idea what you're getting into. Until there's
an offer, there's nothing to get excited about. This kind of expectation is
ridiculous on the part of the company.

Also, what company would not want the biggest pool of candidates to hire from?
That's just bad practice. I'm sure it happens because of the proliferation of
the "shortage of good engineers" myth. If you make your applicants jump
through hoops, just to apply, of course there'll be a shortage for your
company.

This is just to apply, where chances are probably greater than 90% that you
won't hear anything back. It doesn't matter if the company responds to every
application because most companies don't and that's a pretty normal statistic
when applying to places. Perhaps they're just looking for truly desperate
candidates that are willing to jump through all the hoops on the off-chance
that they might get a response. Then they say that they don't want people who
are applying for just any job. That's just ridiculous because that's exactly
what they're getting. Instead of weeding them out (and why would you?) you're
targeting the exact group you're trying to weed out. Stupid.

------
idan
As someone working remotely, this line rubbed me the wrong way immediately:

> More potential warning signs are individuals who are poor at following up
> via email, forget when the interview was scheduled, _or aren 't flexible
> with an interview time_.

Communication is a two way street. If you're looking to hire people remotely
and you expect them to simply adjust to _your_ timezone, you're setting up a
bad remote employment relationship.

I've worked for years with a 10-hour offset from most of the people with whom
I communicate, most recently with Heroku. A large part of what made Heroku
attractive to me as a workplace was the pleasantly frank conversation about
communication and limits. I'm generally available for meetings (my)
10p-midnight, which is noon-2p in SF. Otherwise, email / trello / hipchat /
etc. Obviously, exceptions happen, and they really are exceptional (no "just
this week" things that appear every week).

I've spoken to a ton of distantly-remote employees over the years and all of
the stories that involved radical timeshifting on the part of the remote
employee ended in a move to HQ or burnout and quitting — with a lot more of
the latter.

------
bshimmin
There's a lot of good material in this post.

It struck me as I read through the traits of "great remote workers"
(wondering, as a remote worker myself, if I had these traits and was thus a
great one) that it's never going to be easy to hire a junior developer - or a
junior anything, really - in a remote role: in particular, the ability to
prioritise is something that you can really only acquire with experience, and
"propensity towards action" is a little pointless unless you're actioning the
right things; likewise, many developers, in particular, take some time to get
their written communication up to an acceptable level; and as for
trustworthiness... well, a junior developer is just as (if not more) likely to
be honest than anyone else, but would you actually really trust that they're
doing it right, based on your past experiences?

This leads me to the conclusion that remote working is perhaps best reserved
for those with a little more experience, and that maybe this great movement
away from centralised offices may never quite materialise in the way that some
seem to imagine it inevitably will. Perhaps I'm wrong though!

------
lucb1e
> The email is personal,

The email is not personal. It has a name and a few words (the "<insert
something interesting they mentioned>") but it gives no feedback on why you
are not hiring them. Reading the rejection email as someone who might be
receiving it, it would leave me wondering and frustrated, and more likely than
not I'd reply to ask why I was rejected. You're not going to hire me, there is
no reason not to just tell me.

Maybe this is just American culture (they seem a bit less straight-forward
with negative things than the average Dutchman), but the ever-polite
"hopefully you'll stay in touch" is more annoying than nice to me. Staying in
touch is regular communication, not a line you should say to _everyone_
regardless of how terrible their resume was and how applicable they may be as
a future employee in a different position when really you're meaning to say
goodbye.

~~~
corysama
In America, if you discuss why a candidate was rejected and your reasoning can
be interpreted as one of the many reasons that have been deemed illegal, you
open up your company to being sued for discrimination. Given that your company
will likely have many reviewers discussing many, many candidates, the only way
to be sure no one ever slips up and gets sued is to have a blanket policy of
never discussing why a candidate was rejected. Not with the candidate. Not
even with people inside your company but outside of that candidate's hiring
process. I have never discussed hiring process with a company that did not
have this policy.

~~~
byoung2
_In America, if you discuss why a candidate was rejected and your reasoning
can be interpreted as one of the many reasons that have been deemed illegal,
you open up your company to being sued for discrimination._

This happened at a company where I worked. A candidate who was rejected
emailed and asked why he didn't get the job, and one of the interviewers
replied that he had a thick Indian accent (coincidentally, the interviewer was
also Indian), and that would make it difficult for customers to understand
him. He sued and later settled out of court for a rumored 6 figures. After
that, rejections were handled automatically via snail mail direct from
corporate.

~~~
enraged_camel
That said, I don't find it likely that someone will sue you for saying, "we
need someone who has more experience with <language/framework> or <type of
project>", which is what many rejected candidates are looking for when they
ask why they are being passed on. I mean, on what grounds would they sue?

~~~
byoung2
I guess the fear is that seemingly harmless feedback could be twisted by an
unscrupulous candidate (or his/her lawyer). For example, "we need someone with
.NET experience" in an extreme interpretation could mean "we want people who
can afford Microsoft licenses, not poor programmers who can only afford free
software", and now you're looking at discrimination based on economic
background. That is obviously an absurd example, but it is better to say
nothing at all to the candidate than to have to waste time and money in court
or on a settlement.

~~~
corysama
Even if there were no absurd lawsuits (which certainly do happen), you cannot
realistically expect 100% of your interviewers to be 100% educated and 100%
consistent while giving feedback to lots and lots of candidates. The cost of a
single suit is high enough that you must take the risk of someone ever
slipping up with an off-hand comment very seriously. The only way to reliably
prevent mistakes is to reliably prevent any form of feedback.

It's unfortunate because I'm sure many people I interview would appreciate
feedback and I would be quite happy to give it to them. But, the aggregate
risk across all candidates is too high.

------
rafe33
I'm not sure why any venture backed startup, in an area that has local talent,
would want to deliberately go the remote workforce route. It hampers your
ability to scale, hurts your future acquisition chances, creates and will lead
to communication redudancy, and culture distractions. It rarely works out
positively.

In short, while I am sure that there are some instances where it works well
(eg Basecamp / 37signals), I'd expect that they are the exception to the norm.

Note: I did build a remote startup with incredibly talented people and after a
lot of soul searching and time required them all to come join us locally (or
helped them find a new job elsewhere). Hardest decision we made at the company
and certainly the right one.

NOTE 2: the best remote recruiting tool we had was to handpick whole invited
to work with us. We hung out on mailing lists and read potential employees
blog posts to see what kind of amazing open source projects they were sharing
with the world, before trying to individually recruit them.

------
guybrushT
There is a recurring theme in this post about "putting candidates to the test"
\- sometimes simple testing in the hiring form (to select the ones with the
highest intent) and them to "test with a project" to find out the best ones. I
wonder if this is very practical for a company that isn't a popular/based-in-
vally startup. I have a two part question: (a) How successful have you been in
getting this level of engagement with candidates before you hired them? I
would love to learn more about this. And (b) How well does this work for "non-
programming" roles - that is, can you really devise practical
projects/problems for people to solve. I know the business development example
mentioned in the OP, but that is a small test in the form of a question - but
I can't imagine what a real "project" for this type of role would be? --
sorry, thats 3 questions :) .. but I am curious to dive deeper into this
aspect of the post.

~~~
mooreds
I did a bit of testing at my previous employer, where I was the hiring
manager, but it was in the interview (so candidates had no choice). I think
that is a nice compromise--the candidate is fairly far along in the process,
and you can still learn a lot about a developer with a small project. Granted,
these were junior positions.

As far as (b), I have no experience in this, but I can think of problems for a
non technical person to fulfill. If confronted with doing this, I'd just ask
the hiring manager to list 2-3 pressing problems and have the candidate
outline a solution to one of them. Maybe I'm missing the thrust of your
question?

------
physPop
Is it really appropriate to expect a slew of candidates to drop everything and
do "sample work" so you can assess them?

~~~
arenaninja
Here's a long story: I did a sample work test last week, limit 4 hours; it was
for a LAMP developer position (if you check my post history you can see for
whom!). The entire time I spoke with an HR rep, which I've no issues with but
felt very impersonal. I was e-mailed the project and requirements, and there
was no vagrant included. I had a few vagrant boxes of my own but I figured I'd
just get a new one from puphpet... HUGE mistake. puphpet box requires latest
version of Vagrant. Vagrant successfully updated after over 40 minutes (this
includes Vagrant updating ALL existing boxes). New and shiny puphpet box
didn't work. Try existing LAMP box, something went wrong with the update, it's
broken. Too much time lost, install WAMP quick! Uh oh, missing DLL file...
Installed wrong DLL (x64? x86? I don't even remember), 2 computer restarts. I
had a dev environment after 75 minutes. Water break 5 minutes, I was now
stressed out.

I spent the rest of my time with the exercise, already drained but the
exercise was _very_ simple which was encouraging. Unfortunately, 2.5 hours
just wasn't enough: I missed two of the requirements and I wasn't happy with
the UI. The framework for it all was already there, I used PDO prepared
statements so I wasn't worried about SQL injection, but knowing that I didn't
finish the project I knew my prospects went dim. Oh, and this was after work
so I was coding from 8pm-12pm.

I sent it in, two days later, I received an e-mail from HR person saying I
wouldn't be moving forward. Overall, a draining experience, nothing gained
(usually talking to technical hiring managers you learn _something_ ), no
consolation prize of a technical review on the project, no offer. I probably
won't be doing one again

~~~
Domenic_S
And once again my skepticism for the vagrant/puppet model (outside of server
environments) is validated.

~~~
porker
It is a _complete and utter_ pain for setting up and managing development
environments.

I've been running a separate Linux box for 7 years as a development server -
preconfigured, new virtual host, get working. It's a pain when per-project
technology is needed and I want to find something better.

Vagrant is hip, so I've used that for the last 3 gigs. Getting the box
functioning well, working round issues has cut my productivity by ~15% and
doesn't seem to be decreasing with experience.

There has to be a better way.

------
mbesto
Communication is absolutely key for remote teams to work. That being said, I
often find remote teams using hip tools as a crutch for communication. We use
Trello/HipChat/Hangouts/etc, but it doesn't mean Asana/Slack/Bootcamp/etc work
as well.

IMO, I usually rate remote resources on the following:

\- Are they a resource that will "finish my sentence"?

\- Do they constantly set expectations about progress and milestones?

\- Do they tell us when things aren't going well and need help?

\- Do they update our communication channels frequently?

And we do this by putting them in a small project first and then moving
forward after. The project typically has very little to do with code, but
rather to see if the points are true.

Source: I've almost exclusively been running/working-with remote teams for 8
years now.

------
tieTYT
I have a question as a potential remote employee: If I live in a city with a
very high cost-of-living, will it be difficult to find a remote position that
pays reasonably well relative to my cost-of-living?

I assume one of the biggest benefits to hiring a remote worker is you can hire
someone with a very low cost-of-living and pay them relatively relative to
that. But if I'm living in a place with a high cost-of-living and the company
can hire someone from any part of the world, why wouldn't they wait and find
someone that's super inexpensive?

~~~
Swizec
Because you should never compete on price, but on how good you are. If your
only value prop is that you're cheaper than somebody else, you have already
lost.

------
netcan
Remote teams is one of those things that can be a secret weapon.

I think remote work doesn't work for a lot of companies. A big part of what a
company is is a culture and that culture is usually built around a physical
place, for better or for worse. But, there is evidence aplenty that culture,
great work and collaboration can be happen online. It's a new world and a
company needs to find its own way, but if successful a remote working culture
that works can be a secret weapon.

------
skasriel
Hi OP,

I recently wrote a small eBook about building distributed engineering teams,
based on our experience in building the team that builds odesk.com (yes, we
eat our own dog food and we've learned a lot along the way).

People can get it for free here: [http://work.odesk.com/recruit-manage-
distributed-engineering...](http://work.odesk.com/recruit-manage-distributed-
engineering.html)

Hope this is helpful, I'd love to hear everyone's feedback about it.

------
EGreg
Yes! A very good overview of how to hire people remotely. Removing extra
(often irrelevant) constraints such as location lets you focus on other more
crucial things. Also, a remote team leads to more personal freedom, goal-
oriented focus, and encourages that you work via a Asynchronous workflow and
thus more efficiently.

------
syntern
Thank you for writing a detailed guide about your best practices. It is a
long-term struggle to convince managers that good remote work environment can
be done (and good for both their budget and their employees well-being), and
such stories definitely help this effort.

------
xentronium
Can't help but notice that 8 out of 10 of their accepted applicants' locations
are in US. I've been wondering whether american startups even consider hiring
somewhere from e.g. eastern europe or africa or central asia.

~~~
cedsav
They do, but all things considered, it's simpler to hire within the US when
possible. You keep similar time-zone, work with native english speaker
(usually), and have a well understood set of employment laws.

~~~
mbesto
> _have a well understood set of employment laws_

If you're "hiring" remote workers, you generally don't have adhere with local
laws unless you have a physical presence there. What I mean by that is - they
remote resource is generally responsible for their own legality.

------
sethammons
My only concern would be the requirement for GoToMeeting. Anyone who develops
on a linux rig would be unable to meet.

~~~
fernandotakai
company where i work is using fuzemeeting since it supports linux well enough.

------
clebio
Hmm, I don't know. A banner image of a bunch of white guys, and then

> Not everyone is cut out for remote work...

sort of lost me somewhere between the lines.

~~~
EdwardDiego
What does them being white have to do with anything? Also, I think you may
have misgendered one of the people in the banner.

