At Row and Table, our dev team is 100% remote, with developers in the United States as well as a few other foreign countries. We love remote teams, but we’ve also experienced the dark side. I’ve personally lost thousands of dollars and precious time by hiring the wrong remote developers.
Here are my top twelve tips on hiring a remote developers.
1. Hire through Upwork
Do not, under any circumstances, work with foreign developers directly. You need to use a service like Upwork for a few reasons:
- Upwork will help you find qualified talent. There are thousands of freelancers available to hire on upwork. Many of them good, many of them terrible, but it is the easiest place to find the talent you need.
- Upwork handles payouts and disputes for you. This is both a protection for you and a protection for them. Yes, they lose a small percentage of what you pay them to upwork, but they also have the ability to build a reputation through upwork.
- Speaking of reputation: Upwork gives you the only recourse you have when working with foreign developers — the ability to leave a bad review. This is (in my opinion) the number one reason to stick with Upwork.
- Upwork allows you to see time logs for your freelancers. Although I would suggest that after they prove themselves trustworthy, don’t make them use this feature. It’s invasive.
So who do you hire on Upwork? If I can give you one word of advice it is…
2. Avoid foreign agencies like the plague.
There are hundreds of dev shops in India, the Philippines, eastern Europe and Latin America that are going to try to convince you they have the manpower to handle your whole project. In my experience, this is the surest way to lose money on Upwork. They will run up the hours and produce terrible code. Everything will likely be run through an interpreter.
Just stay away at all costs.
Speaking of working through an interpreter…
3. Insist on video chatting with the developer.
When we hire people, we let them know a video chat is a regular part of the job (and we mean it, we usually video chat several times a week.) Video chat will help you see things you’ll miss in text. Like:
- Are they likable?
- Can they speak english?
- Do they know their stuff?
- Do they actually want this job?
4. Have someone on the call who knows application programming.
Anybody can create an Upwork account and pretend to be a capable programmer. When you are interviewing a candidate, it’s good to have a programmer on the call with you to make sure that this person actually knows their stuff.
There are a few red flags I watch out for on these calls:
- Do they look puzzled when you talk about important workflow things (like git, scrum, ssh)
- I ask to see their Github profile (almost all developers have one, if they have to create one that’s a bad sign)
5. Look for specific keywords.
We use the Laravel framework for backend work and vue on the front end. So of course, we don’t just search for “web developer” we search for “Laravel” and “Vue” and there are hundreds of programmers available.
I’ve found that further refining the search with another, less well known keyword like “tailwind” (the name of the css framework we use) helps us find people who can jump right in. Here is my reasoning, if they know Laravel and Vue and Tailwind, chances are they are into the same development crowd that we are.
Along the same lines, I like to ask prospective developers if they go to any conferences, read any blogs, follow any developers or listen to any podcasts. In our niche, there are several of these and if they are really interested in programming, they will probably watch/listen/attend at least on of these. If they’ve never heard of them, it’s a red flag.
Example, we recently hired a Full Stack Developer to work on our team from another country. I was really impressed by his communications skills and excitement to work on our project. But one of the things that sold the deal was his enthusiasm for talking about Laravel. He even had a Taylor Otwell bobblehead on his desk (Taylor is the founder of Laravel).
6. Look for people who are a good cultural fit.
At least 50% of working with developers is communication. As a project draws on, you are going to have to talk to these people. It helps if you actually like them and can find common ground to talk about things.
This is another reason to avoid developers from halfway around the world. Very often they will have nothing in common with you culturally. But its also something to think about even with in-country developers. We’ve found good people before that we’ve decided not to work with just on a gut hunch that we wouldn’t have much in common.
As an example, we were once thinking about hiring a guy in England who seemed like a very talented developer but decided not to because he seemed like he was into the party lifestyle, and just about everyone who works with us are raising families. He just wouldn’t have fit with us culturally.
7. Give the interviewer a small test job (and pay for it).
Even after you talk to someone and feel them out, you won’t know how good they are until they actually do work for you. So we let new people know that their first task is a bit of a test and we pay them to do something that isn’t mission critical. We are looking for how well they communicate, how they think through problems, how difficult it was to get them setup, etc..
We would never ask people to work for free. It’s absolutely worth it to pay for a small job to see how people actually work.
8. Find someone with at least a couple hours of workday overlap.
One of the first developers I worked with in another country (not for Row and Table) was in India. He is a good guy and a talented developer who has become a friend I still talk to at least once a month. I still have him help me with a few personal projects that aren’t important.
But nothing critical — because the only time I can talk to him is early in the morning. When it’s 9am for me, it’s 11pm for him. Our days are literally flipped. It just doesn’t work for us.
On the other hand, one of our best developers lives in Europe and there are at least two hours of workday overlap. He’s finishing up his workday as we are starting ours. It works out perfectly.
Just know that it’s really difficult to work with people who are asleep while you are working. Especially when something is urgent.
9. Value communication and organization over technical skill.
Being a developer is about a lot more than being a technical wizard. At least 50% of it is about being a good communicator and being organized and self-motivated. Hiring a brilliant developer who doesn’t get his work done or who can’t carry on a conversation and explain what he’s doing isn’t going to help you.
Again, this is why you need to get them on video chat and have a conversation with you. You also need to have clear expectations about how they are to communicate.
10. Look for undervalued prospects, then pay them more than they are asking for.
We’ve had really good results in looking for guys on Upwork who are just starting out and haven’t developed a reputation yet. These developers charge smaller hourly rates and so they are cheaper, but that’s not the way we look at it.
We get them on the phone, feel them out, make our assessment, give them a small job and then if it works out pay them MORE than they are asking for. We basically pay them in the next tier up. Then we have them work on our projects for awhile to further test them before we involve them in client work.
So we might find someone asking $20 an hour and end up paying them $30 or $40.
Why? Three reasons:
- It lets them know that we recognize their value.
- It engenders loyalty and lets them know we aren’t trying to rip them off.
- It helps them stay with us longer and not use us as an immediate stepping stone to higher paying projects.
11: Aim to keep them busy less than 20 hours a week.
I don’t believe that most programmers can actually work more than 20 hours a week on one project. It’s just too intense. Most freelancers won’t bill much more than that.
So we always try to keep people working about 20 hours a week. It’s my opinion that if you pay someone full time then you are probably paying for a lot of messing around and down time. You can get amazing results on 20 hours a week.
12: Protect your code
I know at least two entrepreneurs who have spent over a hundred thousand dollars on software, only for their remote development team to delete the code they paid for or hold it hostage to some ridiculous demand. Both of these cases could have been avoided with a few simple protections.
There are three things you can do to avoid this:
First, hire in an open market (like Upwork) where you can challenge them and leave a bad review for this kind of behavior.
Second, Setup a GitHub organization account, make the repo private and add developers with write (but not admin) access. Every change they make needs to go in that repository. You can kick them off at any time. Be very careful about who you give admin access to for GitHub, for your server, etc. because this can come back to bite you. But if they are pushing code to Github and you control the project, you can always remove their access.
Third, make sure you control your servers. We use Laravel Forge for our servers and only allow people we really trust to have access to our Forge account. Anyone who has access to your server can mess up your entire app 1000 different ways. Be very careful about this.
Even if you follow these twelve tips, there is no guarantee your project will be successful. Building apps is risky business.
At Row and Table, we want to help you with this. Our team has a successful track record making rock solid web based software. We won’t just write code for you, we’ll help you think through your project and give you a solid plan for marketing. Reach out to us today and we’ll start discussing ways we can make your project a reality