You are here

On Hiring Remote Developers

A friend of mine just posted a link to Alexander Dymo's LinkedIn post entitled 2 Tips for Hiring Remote Software Developers [sic]; she also posted a mild critique. I have to say that I'm not super-enthused about this piece either. Here's some of my concerns… First, I hate to be this way, but I question whether anybody should be managing remote devs with that level of written language skill. (I'm assuming, since Dymo is from a YC company, that the management is of English-speaking employees in English. In any case, the problem here is more than just bad grammar: the description and organization in this essay strike me as somewhat uncommunicative.)

I've watched a lot of remote developers and their managers. I've also managed a lot of remotes through the Google Summer of Code program. I'd humbly suggest:

  1. Previous successful remote experience :-): If the candidate has done the remote thing before and everyone agrees on their success, it makes it easy. Past performance tends to predict future results.

  2. Strong communications skills: The candidate should have a record of appropriately frequent high-quality (in style and content) use of async comms channels such as email, fora, bug-trackers, and blogs for technical project communications. The candidate should also exhibit good selection of appropriate channels (sync and async); choosing appropriate channels for situations as they arise is critical.

  3. Initiative (related to Dymo's first tip, but not quite the same): The candidate should exhibit past creativity and initiative in problem-solving, such as project and sub-project initiation, spontaneous design and implementation critique, and spontaneous V&V initiatives for projects. Someone that you have to micro-manage (or even heavily manage at all) is going to be really hard to work with remotely.

Having said all that, (2) and (3) are a bit of a stretch. By far the most reliable way I know to predict remote dev success is (1). Fob