Hiring Devs that Don’t Suck

Recently I was asked about the hiring process we use for tech folks at Kosah, a bootstraped startup I’m involved with. After explaining it, Alicia Lin asked me for a copy of my process. I figured if she was interested, then it was probably useful to more people.

Before we dive into the process, a couple of notes about the approach and the why of it. First, Kosah is a fully distributed company, and we are hiring devs for the long term, so YMMV. Being distributed, we really needed some way to assess people without the normal face-to-face interactions, though not a few hires have gone off-the-rails after what seemed like a match-made-in-heaven in-person interview. So we don’t then want to simply replace the in-person interview with the online video equivalent.

On many levels, the hiring process is like dating, both sides endeavor to put on their best image to impress the other side. How can we have a process that somehow elicits the behavior that would be required of a dev, day-in and day-out? Maybe that’s bordering on nigh-impossible, so perhaps the hiring process should be less about “the One” and more about avoiding the hire that will suck.

The last thing is that this “process” is very much a constant work-in-progress. I based much of this on Dave Martin’s post “Inside Automattic’s remote hiring process” and many of those items are from his post. I have further changed and added to it based how questions and conversations go, and new things I’m learning about human nature.

The Process

This should not be followed as a step-by-step, but more as general guidance to elicit certain responses that generate deeper conversations.

First Pass Application Review

Fit Fail

Hi John, Thanks for your application to Kosah. We don’t think there’s a great fit at this moment, but keep an eye on our openings, and consider re-applying as your skills and contributions to your own or open source projects grow and expand.

Best, Brock Freeman

Who knows what the future may bring. I personally dislike the black hole my applications have gone into in the past so I try to send this out to anyone who applies, somewhat customized to include why it’s not a fit at this time.

Fit: send an email/message to them

Hi John, Please add me on Skype (myusername). I’d love to chat with you about the position.

Best, Brock

Text Chat Interview

Immediately after I accept the Skype invite, I kick things off by saying something to the effect of:

Hi John!

Rather than set up a specific time to chat, let’s just keep a conversation going in chat. I’ll ask questions, and you can answer as you have time. Could be today, tomorrow, whenever you’re available. Sound good?

Next, I ask an open ended question to get to know them:

I’d love to learn more about you. Let’s just keep it as text conversation in Skype for now, as most of our communication at Kosah is done via text. Tell me a bit more about yourself. What are you passionate about? What do you enjoy doing that is not just tech related?

I want to see how well they can express themselves, and how well they communicate, starting with this question and throughout the rest of the text interview. We want more well-rounded people with interests in more than just sitting in front of a screen; some sort of exercise or sport is also important both for mental and physical health. Overall the response here and the conversation that follows helps to find some similar interests that determine whether they’ll be a good culture fit at Kosah.

What’s the most difficult thing you’ve ever accomplished? What are you most proud of?

I really love to see the responses to these questions, many times they bring up experiences that are not on the résumé. I’ve see very difficult technical problems, to a volunteer project.

Tell me more about your character, are you known or seen by others around you as self-disciplined? Are you good at resisting temptation or do people see you as impulsive?

Self-discipline has a bigger impact on performance than intellectual talent. How many times have you seen someone super smart or talented fail due to lack of self-discipline or not being able to resist some temptation, and I’m not referring to the moral kind here.

I’m not in love these two questions being so direct, as someone can just feed me what they think I want to hear. Yet those who answer with nothing in the temptation area at all does leave you to wonder how in touch with their own character they are. I’d love to see your suggestion on this.

Reaction to criticism:

How do you respond to someone finding and pointing out a bug in your code? Tell me exactly how you would react and respond.

We want people that welcome learning from mistakes and have a great attitude when someone else catches an error. Peer code review is something we practice and is really the only way to operate.

Have you done a personal programming project that you did NOT do for work or school? An example could be an open source project that you contributed to, or just a fun project you did for your own interest and learning.

OR

At what age did you start programing? What was the first programming project you completed (likely just for fun)?

The idea here is to gage passion for development; if they have never done a project for purely personal reasons, and only developed software for pay or for a class, then it’s very likely we will reject this candidate.

Can you break down how comfortable are you with the following, on a scale from 1–10 (10 being expert): JIRA, PHP, Laravel, Angular.js, node.js, JS, HTML, CSS, Bootstrap, Docker, CoreOS, DevOps?

While we hire for character and a growth mindset, we still want to see how high a learning curve they are going to have with our technology stack.

What is the newest programming language or framework you are learning or dabbling in? Why did it grab your interest?

A passionate dev will generally love to tell you all about the latest stuff they are self-learning, and maybe even why they think it’s superior. We want to avoid those who are not learning anything new on a regular basis, or learned only because a job forced them.

When it comes to growth, would you say you skew more towards: a) Doing a little bit of research, and then just starting to test stuff, or b) Devoting more time doing research up front before you narrow in on which tests to run?

I’m not looking for a right answer here, but more getting to know them. There are advantages and disadvantages to both depending on circumstances. Better they see that both are useful depending on the situation.

At any place through the interview you’ve already made up your mind about an applicant, just end the interview there. When an interview doesn’t work out we write something like:

I appreciate your taking the time to chat in this interview about a position at Kosah. There were a number of things that I liked about your application [mention something if possible], unfortunately I don’t think there’s a great fit at this very moment because [bring up why in a kind way]. I would encourage you to keep an eye on our openings, and also keep us updated and consider re-applying as your skills and contributions to your own and open source projects grow and expand. All the best!

I always liked knowing why I didn’t fit a role, so be a hero and tell them why. It gives them a chance to improve in the future.

Video Interview

I would like to set up a video conference sometime in the next few days with you. Mainly I would like to watch you as you code a solution for a small challenge test I have for you. A good programmer can do it usually in under 5 minutes. Let me know what your availability is.

I pay attention to how well the applicant communicates during this part of the process.

• Do they suggest dates and times with time zones?
• Do they send over calendar invites? Do those have time zones attached?
• Do they offer multiple ways to connect, such as phone, Skype, or Google Hangout?

Effective communication is so key in a remote position that these little things are a sign of a person who might be a great fit, or not.

In the video interview we have them solve a coding problem. But I’m also observing how they work, how they communicate.

Coding Project

If the candidate does not have any open source contributed code we can examine, we ask them to perform a coding project that will usually take them around two hours. We try to give them something that will contribute to open source, not our own stuff.

At the same time the coding project is going on, we will have our technical advisor for Kosah, someone with years of experience, do a short interview with them.

Audition / Presentation to the Team

We ask the candidate to prepare a short (15 minutes) lightning talk on a topic of their choice. It can be anything. The hangout starts with a brief round of intros and then the applicant gives the presentation followed by Q&A. This gives our team a chance to interact with their potential teammate. The last thing we want is to bring someone on that the existing team is not comfortable with.

Trial Period

Everyone that gets hired at Kosah goes through a paid trial process. They are given a project or set of work (usually a set of prioritized bugs), which they can work on over a week. That’s the first checkpoint, for both of us to see if we feel good about the fit. It gives them an opportunity to take Kosah for a spin, with no strings attached. No matter if they continue, they get paid for the work they do.

In the second part of the trial lasting 3–4 weeks, they start doing development with the team. During this time we will communicate more often to ensure they onboard with a good fit. Once this second part is finished, we consider them part of the family.