“He who controls the spice controls the universe.” That’s the best-known quote from Frank Herbert’s Dune. Spice was the resource that enabled space travel, and as such, the universe couldn’t run without it.
There’s something similar to spice in our world: software. Nothing runs without software. As such, if you own or run a business of any kind, you are inevitably going to have to hire and eventually onboard a remote developer.
The good news is that — as you’ll find out in this article — it’s much easier to hire and onboard a remote developer than it is to control the spice. You don’t need to get high with the natives of a desert planet and lead a revolution against evil space nobility. Doing that would be rad, though.
Whether it’s your first time hiring and onboarding a remote developer, or you already have several hires under your belt and are looking to sharpen the process, there are some points worth covering.
For the uninitiated, know that hiring a remote developer doesn’t have to be an arcane pursuit. More often than not, the biggest issue is to know where to start.
For the experienced, know that my business is all about remote recruitment, so while you can and should expect some bias, you can also bet that I’ve explored every hiring avenue and possibility.
So, here’s what hiring a remote developer looks like:
Because more people are hiring than ever and more people are looking for remote jobs than ever, there are dozens of alternatives all around the web. I will characterize the three primary ways you can look for a developer but realistically, know that there are many solutions in-between.
First off, we have talent marketplaces. We usually associate these with freelancers, but nowadays, many of them focus on showcasing people looking for job opportunities. Talent Marketplaces essentially curate jobseeker profiles and surface the selection that better fits your criteria. The level of curation, compulsory paid services, and the how-and-what-you-actually-pay-for differs significantly from platform to platform. The thing these services have going for them is the sheer breadth of candidates on offer. Thousands of people submit their profiles every day.
Talent Marketplaces are an excellent option if you have the time and energy for a grind. Their curation will only get you so far, and you are likely to have to evaluate dozens — if not hundreds — of profiles before deciding on a shortlist. You’ll also have to vet that shortlist yourself for cultural fit and soft skills. Most marketplaces do a decent job with skill vetting, but I would still do it anyway, and I’ll give you a few pointers about how to later in this article.
Next up, recruitment agencies. This is the business I’m in, so I’m not going to dally here, as I would rather you read the article without being put off by the stench of blatant self-promotion. Tim Ferriss often says: “If you have the money to solve a problem, you don’t have a problem.” That’s the recruitment agency game. You pay them a nice chunk of money, and they’ll do the hard lifting for you, often with better results. Not because they are so awesome, but because that’s what they do every day.
A good recruitment agency should give you a shortlist of 3-5 candidates vetted for your particular needs and culture within a couple of weeks. You should also get their commitment that if the person you select doesn’t stick to the job, they’ll try to fill your requirement again for a certain number of times, at no extra cost. Go with a recruitment agency if you are OK with trading money for time and focus.
Finally, there’s your network. The “I know a guy” route can be surprisingly effective, especially if you or your company has a solid social presence. Just posting your job offer publicly won’t cut it, though. It’s much more worthwhile to reach out directly to people you know and respect in the programming field and ask if they know someone. It’s relatively easy for someone to forward your tweet or LI post to someone they only have a passing acquaintance with. That will generate a lot of unfit candidates. On the other hand, when you ask someone if they know somebody, they will think hard about it. No one wants to be the person who sent a dud your way.
Of course, this method is random and very slow. It shines because it is very low-effort and comes with some social vetting built-in. I would use it in addition to one of the previous two, but not by itself.
In a perfect world, people wouldn’t lie in their CVs or applications. Hardly any people outright lie, but most people exaggerate their skill. The amount of technical vetting you’ll need to do depends on your hiring platform strategy (see above), but it’s always healthy to do some.
I’ve always felt daunted by this because I’m not a technical person, so I don’t feel I’m in the position to evaluate developer skills properly. What would I look for?
The answer is: look for the story. Read a candidate’s CV as you would read the synopsis for a novel, and see if it makes sense. What did their education look like? How long did they stay at each previous job? What projects do they take credit for? Can you take a look at those projects?
In addition to that, do the unexpected — call their reference checks! Yes, talk to people. Most people find it very hard to embellish or lie on behalf of others in a call. I know you don’t feel like doing it, but set those feelings aside and go for it.
Finally, get a technical buddy to interview you. If you already have some developers in your team, perfect. If not, grab someone you know and trust. Promise them a dinner. If you have no developer friends (really?), you have no choice but to prep. Any recruitment agency or talent marketplace worth their salt will have an extensive collection of articles about “How To Interview X Developer” where you can look up the main technical questions and what kind of answers to expect. I know, it sounds like a huge pain — and it is! But not as painful as all the wasted time and money from hiring someone unfit for the job.
Let me blow your mind: a great professional might still be a terrible remote worker. It’s sad but true. Working remotely demands a specific set of skills that stand apart from those required for an individual to excel at their profession. The good news is that there are a few markers that you can follow to understand if someone has the R-Factor.
The first marker of an exemplary remote developer is the clarity of their written communication. In emails and messages, do they use concise sentences that nonetheless follow proper grammatical form? Does each sentence have a clear antecedent? In casual conversation at the office, “I need that thing we discussed done by ten.” is acceptable. In remote work, it is not. Lack of specificity in writing kills remote work. Hire people who write sentences that stand on their own and don’t require further clarification. Be unforgiving to anyone who can’t express themselves like that.
Actively judge people based on their internet connection, microphone, and camera setup. If you work remotely, these are the tools of the trade. You wouldn’t want to work with a surgeon who doesn't wear gloves and a mask, so why would you hire someone who looks like they are part of a witness protection program?
Ask them why they are interested in the position. If the main draw of the job is to pursue their digital nomad lifestyle or move back to the town where they met their childhood sweetheart, they are OUT!
Sorry, but you have a business to run, and remote work requires engagement. It demands discipline to get things done. For someone whose primary reason for wanting the job is to fuel their lifestyle choices, that person won’t be engaged. To be clear, it’s fair that that is ONE of their reasons — I’d even consider that healthy. But it can’t be the first reason that pops up. Working from home, a dozen things compete for your attention, and they are often things that you love — your wife, your dog, your PlayStation 5, etc. Your job doesn’t need to beat these things — I’d argue it shouldn’t — but it needs to be competitive, at least.
Finally, check whether they have a plan. A pro remote worker should have a plan for how they are going to manage their work daily. They should have a schedule, a setup, and a strategy. If they stare blankly at you when you ask them about it, or even worse, if they flat out admit they’ll just fit it around their day — run for the hi
The Email Care Package
The week before your developer starts creates their company email. Add it to all your communication and management tool plans - Zoom, Slack, Trello, etc. Email them the details, plus a list of all the tools and apps they will be using, so they can download clients & configure their workspace accordingly.
You get bonus credit if you have someone create all your developer’s logins and save them under their username in your company’s password manager of choice. Then all you need to do is send them the credentials for their access to the password manager (in fact, ask them to reset their password), and you’re done!
Now they’ll be able to hit the ground running on Day 1.
On Day 1, they should get a task list with everything they are expected to accomplish over the first week. At DistantJob, we use assignments in HR Cloud for that. This includes tasks like “read our culture document and leave a review” or “schedule a meeting with the company’s president.”
The idea is to remove any doubt about what they should be doing. In an office setting, presence makes up for a lot — the new person won’t be left hanging around. People will notice them and push them along the right path. In a virtual office, you need to be a bit more intentional. So, give them a roadmap, preferably in a tool like HR Cloud or Basecamp, where their manager can check on their progress casually and see if they need any help or nudging.
Let’s follow up on the topic of intentionality. There’s a lot of “how we do things around here” that goes unwritten in an office. It gently permeates new arrivals, mainly as an oral history. You see someone do something that’s not quite right, and you let them know there’s a different protocol for that.
In a virtual setting, you don’t see people working; you just see deliverables. Mistakes are harder to catch and costlier because you detect them at the end of the chain, if at all. So, you need to codify into written form stuff that would typically be part of an oral tradition. Enter the Team Agreement.
As part of the onboarding process, everyone who joins my team gets a task to read a document called “The DistantJob Marketing Team Agreement.”This is effectively the team’s instruction manual — and it’s public. You can google it. (Go on, google it and bookmark it as a reference. We made it public for you to steal from it.)
That document describes the baseline tenets of the DistantJob marketing team, the core philosophy that I use to run the team. It’s not a massive lump of protocols — those exist in a Wiki to be perused whenever a team member needs — because it’s impractical to have everyone memorize those. But if you can give your new hire a short document that transmits your values and organizational philosophy, they can use those as guidelines to make better decisions from the get-go. This is also a living document — we actively ask new hires to comment on it and suggest improvements. That’s a task in our onboarding checklist in HR Cloud!
Ordinarily, I’m anti-Zoom. I gauge the productivity of my week by how few calls I’ve had. I’m a full supporter of the asynchronous workplace. But I do think calls are an invaluable tool for onboarding.
When I onboard someone, I make sure they get on a call with the core leadership team at DistantJob, the visionaries behind the whole operation. That’s one of the onboarding tasks: to make those calls happen. I leave it in the new hire’s hands, so they’ll learn how to navigate the company structure and get things done. (But of course, I check in and help if they are struggling.)
I also make sure the new hire gets at least one hour of face-time with their direct manager (me) on Day 1 and with the entire team. I very rarely request that people from 5+ time zones make time to get together, but this is one of those occasions. I want the new employee to feel welcome and see real faces behind every username on Slack.
At the end of the onboarding week, I always set aside one hour to sit with the new hire and ask them about their experience. I might or might not have some feedback for them, but I certainly want to hear their feedback about the whole process. I ask them if they enjoyed the week and if they felt they had everything they needed to do their job. I ask their opinion on our systems and processes, culture documents, and leadership. This call is an invaluable chance to see the company from an entirely new perspective! They are the whole reason I’m writing this article — 8 out of 10 new hires tell me that they’ve never had a better onboarding experience, so that makes me believe it’s worth sharing.
Some people write off remote work. They recognize the benefits of hiring the best talent from all over the world, but they don’t believe they can make it work. They struggle with finding the right person over the internet, or if they do, they fail to engage them in work.
But not you. You now have the tools you need to hire and onboard remote developers, and that means your hiring pool just became as vast as the deserts of Arrakis. I’m not claiming you’ll have a smooth ride. No strategy is infallible, practice is a prerequisite for perfection, and treacherous Harkonnen spies lie in wait everywhere. But you do have something that few people do: a solid roadmap and a good set of tools. Time to put them to use!
About Author: Sharon Koifman is the CEO of http://distantjob.com/, a Montreal-based company that provides remote worker staffing and best practices-based advisory services for companies seeking to improve and expand their remote work operations. He is an author, speaker, and entrepreneur with 15+ years of experience in the tech, recruitment & HR industries to pioneer the remote recruitment model