7 recruitment tips for “performant anywhere” development teams

mark hardwick
5 min readJun 25, 2019

--

In my recent article “Build performant anywhere teams” I mentioned that we adjusted our recruitment and on-boarding processes to be remote friendly. In this post I want to cover 7 things we focus on during recruitment of new staff, and then how we onboard them.

I have a mix of fully remote and mostly co-located staff. I say “mostly” because we have 3 offices, global clients and even co-located engineers travel and therefore need to be able to work effectively no matter where in the world they find themselves.

This article is more relevant for engineers who will be working fully remotely.

Recruitment

  1. Multiple Interviews
    We hold multiple interviews (nothing surprising there) but as part of that we assess quality of remote communications. Remote developers often work in chat or ticket systems, but actual talking is necessary and desirable. If there are constant network issues or we simply can’t understand the person, we’re unlikely to recruit. Strong accents are not too much of a problem (we get used to them quickly), but simply being bad at English, or having consistently poor sound due to network issues, is.
  2. Paired programming interview
    We’ll set candidates a task and use screen sharing to remote pair. Again we assess not just the candidate but if the paring works technically and at a communications level. We’re quite comfortable pairing just with screen sharing, however there are IDEs like Atom that do a reasonable job with pairing (there are a number of paired programming plugins available).
    Pairing helps to quickly identify if the candidate is a good match for our culture. Note: if you choose to do this, remember that a good candidate may find this intimidating — you need to be supportive.
  3. Doing code tests with PRs
    We do at least one code test, but we also ask developers to improve their solution if we’re not convinced via a normal PR. This way we find out how they take criticism and how they respond to being asked to go further. I’ve had a number of people refuse to do a little more work to tidy up a code test solution. That speaks volumes to me.
    We’re also interested in turn around time and initial questions. We’re looking for developers that jump in and quickly and gain clarity before coding, this is very important for people in different time zones because their window of overlap with the UK office may be restricted. We want people who strive to save time by resolving uncertainties early.
  4. Are they passionate?
    Here we get them to speak on a subject. For example, ask them to “describe their perfect life”. This will show if they’re creative, passionate and able to enthuse, then ask them “what are you doing to achieve that life?”.
    These softer but challenging questions help us discern ability to express their opinion, levels of focus and passion. The point here is that “performant anywhere” people need to be passionate and good communicators. They need to own things. I find that people with strong life passions are better at taking ownership and take pride in great code.
  5. Can they deal with isolation?
    Isolation stress can be a problem for fully remote developers, especially if the candidate is new to remote working. We ask people about their motivation for working remotely and prefer candidates who have worked remotely before (if they will normally work outside the office).
    I’ve not found any particularly good ways to see if someone will suffer isolation stress. I have found that first time remote workers are more likely to suffer from it.
  6. Can they travel?
    Our staff need to be able to travel to our offices to meet people. For developers within a few hours of an office, we have them in for a few days every couple of months. For distant developers, we try for at least once a year. We don’t recruit people who can’t travel.
  7. Can we put them in front of a client?
    At pi-top we have customers globally, and we may want a suitably located developer to help with a customer situation. Here we require someone who is polite, knowledgeable and straight talking. Having a distributed pool of performant anywhere developers to help with clients is an important benefit of our remote strategy.

On-boarding

Once we’ve selected a candidate we need to onboard them and make them feel welcome. There are simple steps we follow:

  1. Weekly group get together
    With a wide range of remote workers in different teams we have weekly get togethers where people give brief demos of their work or, if there’s nothing to show, communicate what excited them in the last week and what they’re looking forward to in the next.
  2. Cross team projects
    We involve all developers in cross team projects to explore new products or learning materials (we’re an ed-tech company after all). This is pretty important so that remote developers work with a broader cross section of the company.
  3. Regular paired programming
    Paired programming sessions are the best way to expose new people to our processes, systems and architecture. Documentation is useful and we try to keep it up to date (often during paired programming sessions). I find paired programming leads to a deeper understanding of our systems than is achieved if we ask new recruits to read documentation.
  4. Detailed PRs
    Extra effort goes into the PRs for new people, we use it as an opportunity to communicate our code style and values.
  5. Agile coaching
    We want to be agile not do agile and we’re pretty particular about how we make that happen (the topic of my next blog post). It’s really important that we get new developers working with data and voicing ideas as early as possible, and I find giving an re-introduction to agile useful.

I hope this list is useful and please do comment if you incorporate other elements into your remote worker recruitment & on-boarding.

In my opinion, the hardest things to gauge with remote developers is how they’ll cope with isolation. If the developer in question is new to remote working, they may find it more of a culture shock than they expect. I’ve not found any great tests that will help you determine how someone will cope with working from home every day. Some people love it, others don’t.

The best way to mitigate against the risk of isolation stress is to provide remote friendly opportunities for training and personal development, and try to get remote workers in for a few beers regularly (location permitting).

--

--

mark hardwick

I love startups, creative use of technology, remote working and writing on these thing