Before working at Tithe.ly, I was a little old school at my company Elvanto where everyone worked in the office. Now that I’m at Tithe.ly, they’ve introduced me to the world of remote — and I absolutely love it! I’ll do a write up on switching from traditional office space to working remotely in another post. But for now, I wanted to talk about hiring remote engineers.

Switching from hiring engineers locally to remotely hasn’t been a big step. The way I hire remains the same other than not being able to do in-person interviews.

Remote hiring has opened up a huge world of opportunity and talent. If you need convincing about having your staff work remotely, read Remote by Jason Fried.

I was reading Zapier’s book The Ultimate Guide to Remote Work recently and really loved the chapter on How to Hire a Remote Team. I was surprised when their hiring process was very similar to my own. I felt validated 😋. They have some great extra tips on the whole hiring process so worth a read!

So here is how I hire remote engineers…

I don’t use recruitment agencies at this stage. I haven’t found the need just yet. I just post my own ad.

In the USA, I’ve had some good success with Angel List of late. They have some good ad settings for advertising for remote roles. Spending $150 on a sponsored listing I’ve found a must and helps get a lot more applicants through the door.

The second step is to create a way to track applicants. I simply use a Trello board at this point. Why? It can become quite overwhelming keeping track of all the applicants (and remote can attract a lot of them!) and where they are at in the process. The team over at DoSomething has a great Trello board example on how to use Trello for hiring.

I only want to talk to people who fit my criteria so I spend a little extra time mulling over resumes, looking at their past experiences, trying to gauge them before I talk to them. Their education isn’t so important to me. I never went to college/university and I turned out alright.

I tend to appreciate people that have worked on their own side projects or contributed to open source. This to me shows a little extra passion to what they do.

Working remotely means those hired will be doing a lot of written communication. So I look for questions I can ask applicants before I book a call so I can see how well they communicate. It’s also a good chance to dig deeper into their experience to ensure they have the basic skills required for the role before talking to them.

For those who pass, I then have them book in a 15-minute video interview with me. I want this short and snappy so that I can quickly move on if the applicant isn’t the right fit.

I use Calendly so that applicants can book meetings directly on my Google Calendar. It is super flexible when it comes to limiting the time of day and how many interviews per day. I’ve also got the Zoom integration so that it creates a Zoom meeting link in the calendar event when the booking is made. It’s totally automated.

In the video call (I ensure they have their camera on), I tell them about our company, about the role and ask them questions. I want to get them talking.

Some questions I tend to ask are around their experience, recent projects they’ve worked on, what sort fo teams have they worked in, what do they think about working remotely, what are their aspirations and so on.

My goal at the end of this call is to determine:

If it’s yes to all of my questions I will proceed to the next step.

We have different code challenges based on the role. I generally get smarter engineers in my team to come up with challenges.

We’ve just started using Qualified which is working nicely. We’ve used some of their challenges and also created our own.

Generally, our code challenges come with some Q&A to test their knowledge and then a handful of code challenges. Sometimes more challenges, sometimes less depending on the role and how hard each challenge is. I don’t want people spending 10 of hours on this but you’d be surprised how many do.

I then invite applicants to complete the challenge through Qualified. I find we get some drop off at this point which is great as we want to keep weeding people out who aren’t serious or don’t have the skills required.

For those who complete the challenges, I forward the results again to those smarter engineers to give their feedback.

If an applicant passes the code challenge we then ask them to book in a 1-hour interview. I’ll always include a team member who is an expert in the role I’m hiring - ideally someone who the new hire will be working with but doesn’t have to be. It’s good to get another team member’s head on the process and they can be someone you can chat with after the interview to get their thoughts.

Again I use Calendly so that applicants can book meetings directly on our Google Calendars. The thing I love about Calendly is the ability to create a team calendar with the other team member involved in the interview. Calendly merges our calendars and gives applicants time slots that work for both me and the other team member. This is such a timesaver! Thank you Calendly!!!

In the interview, I’ll generally go through the role and ask the applicant to share answers to similar questions I asked in the 15-minute interview again. This is mainly for the other team member in the interview to get up to speed. It’s also a good chance to have it all retold to refresh my memory. And again, you want to get them talking!

I then have the other team member ask some technical questions which relate to the role.

Before closing the interview, I allow the applicant to ask their questions if any.

From here you can always book in more interviews or do more code challenges if you need more clarity on an applicant. I should also have some other applicants to compare them to.

And of course references! I like at least 2. Make sure you get the email address for each reference because if they are in another timezone, calling might be difficult. Sending an email might be the best thing. Keep the email and questions short so it’s not too overwhelming for references to reply.

I go with my gut a lot from this point onwards.

Once I’ve found the applicant I like, I send them an email offering them the role. I outline the salary, start date, and benefits. Some applicants might negotiate which is fine and it might be worth jumping on another call if required. Once they accept, I have a form offer letter sent off.

I can only hire about 2 positions at once without it taking up too much of my time. When I’m on a hiring spree, I beat even our sales team in the total Zoom calls held because I have so many interviews!

I’ve documented our hiring process internally here at Tithe.ly so I have other team members outwork some if not all of the above steps. I have templates and suggestions to make it a no brainer for our team. I just jump in and help with salary and whatever else I can.

Many hands make light work.

Early days I focused more on skill set than the applicant’s personality. Not that there’s anything wrong with those nerdy engineers who like to curl up in the corner and code, they add great value, but I value and cherish energetic and motivated engineers on my team. I want people who can communicate well and not just write code. I want interesting people from varied backgrounds. All of these things add a great dynamic to my teams.

A lot of candidates I talk to of late weren’t always coders. They were baristas, managers, waitresses, musicians. One day they decided to try coding and fell in love.

So there you go, that’s how I hire!

Try to get good talent as easily as you can and create plenty of opportunities to weed out those who aren’t the right fit. Hiring doesn’t have to be too big of a pain if you do that!

My process will probably continue to be refined so I’ll be sure to keep this updated with any changes 🙌🏼

Originally posted Oct 29, 2019.