How to Hire Programmers

How to Hire Programmers

This is a guide on how I hire programmers. I hope it helps you to grow a successful team.

Part 2: How To Hire Outsourced Developers

In general, hiring programmers is not that difficult. Figuring out how to hire programmers, especially good programmers though, well, that much harder than it seems. Especially if you’re hiring for a full time programmer that is going to be part of your full time staff (remote or not). Lots of things come into play such as culture fit, work ethic and probably most importantly – technical chops (does the programmer know how to do what they say they can do). Lets assume you’re only hiring a contractor to do a small project for you. Well, its still hard to hire a good programer then too. How do you vet them? How do you know what works and what doesn’t? How do you know if you’re throwing away your cash. Thing is, you don’t.

You do the best interviewing you possibly can and then bring the most qualified candidate on board to join the team or complete the project. If it doesn’t work, you try another candidate until one sticks. Problem is, no one has this process locked down. I’m going to share my approach that I use to hire programmers that has given me nothing but top quality talent for remote workers, contractors and full time staff for the past few years. This is the same approach I’ve used for hiring remote programmers as well as on-site programmers.

After I’ve found someone to interview I put them through a process of 4 steps.

4 Step Interview Process

1. Informal Human Resources Phone Screen/Skype/Google Hangout
2. Technical Phone Screen/Skype/Google Hangout
3. Programming Challenge Screening
4. Culture Fit Evaluation

If a candidate makes it through all four steps you’ve very likely hired the correct person for the job. The results of this process rewards you with a person who is:

• Technically capable of performing the job duties
• Comfortable enough to fit well into your company culture
• Someone who can communicate and relate thoughts effectively

The Goal of the 4 Step Process

You’ll note that two of these screens both use Phone/Skype/Google Hangout as a communication medium. Why? The reason is simple: Time is valuable. Its the resource we cannot renew and if I can save my team the hassle of meeting rooms, traveling, etc then I will do so. Thats what this accomplishes. The candidate usually appreciates it as well as it saves them time and hassle. Saving time for my company and employees is what I’m going for in these early steps.

The goal of this process is to save time.

Each step in the process is completed at a different time. Usually 4-6 hours apart at minimum. The reason for the buffer is to allow the team to decide if they want to move the candidate to the next step or not. Example: If after step one is complete the company determines that they do not want to move forward with the candidate they can then inform this person electronically (email, or even phone) and then move on with their day. Same goes for step two and step three. Step 4 is hands on, which will be explained in detail later. This makes the hiring process a bit more agile. Each step is a iterative cycle that builds on the success of the last. Think of it as TDD for the hiring process. Did they pass step 1? Ok, they did. Move to step 2. Did they pass step 2? Yes they did, great. Did they pass step 3? Nope. Stop the process. No more time is wasted.

The Steps

Each step is explained in detail below with examples of questions, links to external material and sometimes riddled with tips and tricks about how you can improve your process.

Step 1: Informal Human Resources Screen (10-30 mins)

End Goal: Identify if the candidate is suitable for the position based upon basic conversation and classic HR questions.

The first step in the process is rather short. When speaking of saving time – this is the first line of defense. Feel free to keep this rather short. You want to be able to identify that this person can communicate effectively, they’re not socially inept to convey thoughts/etc and that they are sane. Example: If someone starts dropping F-Bomb’s every other sentence then you have a chance to cut the interviewing process short as this person may not fit your team.

This step is usually completed by the hiring manager (sometimes this is you, sometimes its not). At this point the manager will state what the job is and they will converse with the candidate. A a few simple questions should be asked:

• Why did you apply for this job?
• How much experience do you have in X? (Where X is something you my be building, a new technology, etc)
• Can you tell me about your last job?
• Etc

Continue down this path and use the traditional interview questions if you want. Those include the likes of:

• How would you handle X? (Where X is some common HR problem, etc. Some examples are shown below).
• Tell me about the time when you ran into a problem you couldn’t solve, how did you solve it?
• Tell me about a time when you worked with a coworker that you did not agree with. How did you resolve your differences?
• Tell me about what you know about our company.
• What questions do you have for me?

At this point you should be able to determine if the person is sane, not feeding you a line of nonsense and if they look capable of going to step 2, the technical screen.

Step 2: Technical Screen (10-30 mins)

End Goal: Identify if the candidate has the technical chops through a Q&A format Skype/Hangout/Phone screening.

The technical screen is the second line of defense. At this point I get to see if the person has the technical chops to perform the job duties; at a quiz level. This technical screen should take ten to thirty minutes depending on the complexity of the questions asked, conversing, and general technical chit chat. If the person starts failing too many questions during the interview, feel free to cut it short. The questions that are asked vary depending on the type of programmer you’re hiring. But you’ll want to cover the language basics, framework basics, servers, etc that you may be working with at your organization. You’ll want the questions to be open ended so the candidate has to explain themselves. Try to avoid questions that have a Yes/No type of typical response. Examples of questions you’d ask might be something like:

NodeJS Example Questions

• In NodeJS please explain what ExpressJS is used for and why you’d use it.
• What is the difference between Sync and Async calls and which one should you try to use more of, and why?
• What testing frameworks do you use?
• Can you tell me what V8 is?

Android Example Questions

• What is AsyncTask and why would you use it?
• What is the ActionBar?
• What is Gradle and why would you use it?
• How do you unit test Android?

Rails Example Questions

• What is the asset pipeline?
• What are controllers?
• What is RSpec and why would you use it?
• What is a route?

Usually these type of interviews are performed by another programmer on the team. Sometimes its performed by two programmers from the company. If this is the case (two programmers doing the technical screen), have a code-sentence that helps you tell the other person that “this is not the guy, lets cut this short.” I’ve gone with ones such as:

• “Oh by the way, remind me to tell you about my experience this morning at the gas station.”
• “Oh, hey, reminds me, after this interview remind me to call my cousin.”

You get the point, make up your own and roll with it. At least 50% of the time (if not much more) you’ll find that you want to end the conversation as soon as possible because the candidate is not the right person for the job. Remember, the point is to save time during this process. Cut the interview short and then move on.

Step 3: Programming Challenge Screening (2-4hours/Overnight)

End Goals: Identify if the candidate has the necessary ability to solve programming problems with code. Gain insight into the quality of code that is produced by this candidate.

During the Programming Challenge* the candidate will be tasked with solving a real problem using the language that the company specifies. The coding challenge should not take an experienced programmer no more than 1 hour to complete at most. I give a range of 2-4 hours (or overnight) to allow the candidate plenty of time to complete the task; just to be fair. I normally allow the person to perform this task at home in the comfort of their own surroundings so that its less stressful and so I can see how they really solve a problem. Some companies prefer to do this on-site by allowing the candidate to use a laptop and internet connection to solve the problem. Regardless how it is done, the goal is simple: To determine if the candidate can produce the code that is needed.

The programming challenge is the great equalizer. Not because the problem is necessarily difficult (it’s not, its easy), but because it allows you to gain insight into the quality of code that the person writes. It also answers a vast array of other questions as well:

• Does the candidate communicate effectively?
• Does the candidate know how to follow directions?
• Does the candidate know how to use Git and GitHub (more on this in a second)?
• Does the candidate follow coding best practices?
• Does the candidate know how to code?
• Does the candidate follow through and succeed?

If I’m having the candidate perform the test at home or on their own time I usually inform them that I’ll email them at 5pm with the instructions on how to complete the problem. I inform them that the problem is due the follow day no later than 12pm. The programming challenge is posted online on GitHub/BitBucket in a Git repo that is built for each candidate. The repo contains all the necessary information about the task. The candidate is to follow the instructions and email me when their done. Here are a few example of some of the programming challenges I’ve created:

• NodeJS Example
• Android Example
• Rails Example

Feel free to fork these and save them for yourself. If you visited any of the sites above you’ll see that each of these examples had the candidate perform a series of steps. If the candidate is not sure of what to do, they could ask me for clarification or simply Google for the answer. When the candidate is done they’re to submit a pull request to me so I can review it. I understand that not everyone uses Git for their source control, so feel free to modify this and use mercurial, SVN or whatever source control system you use.

This challenge is genius because it answers so many questions about the candidate. Namely, can they code and get something done on time. It also gives me the chance to review the code to see if a complete hack or if its something that is quite good. What I’ve found is that on average over 60% of candidates will never finish the problem – they simply don’t know how. This is why I have them do it at home. Steps 1 through 3 can all be done remotely. This saves the company time during the hiring process. Of the 40% that finish only about 20% actual do it correctly and usually at that point you’re left with either 1 or 2 candidates that are looking good. If you have more to choose from then thats a good problem to have!

A common concern when letting someone do this task at home is: What happens if they cheat? What if they call their friend or have someone else do it for them? That is a possibility, but I see this as a real world problem. Sometimes programmers don’t know how to solve a problem so they have to call for help. They call friends, IM them, look stuff up on the internet or just find an open source project that does what they want and they take the code and modify it. Thats the world programmers live in. If I do that at an office or at home, who cares. If you’re truly a hack I’ll know fairly quickly. If you do get hired, the team is going to sniff out a problem very quickly and at that point you’ll need to make the decision to keep the person or not.

If the candidate fails to complete the programming challenge, thats an immediate red flag. The task should be easy enough for an experienced programmer to finish in an hour. If the candidate cannot finish within the time allotted either the program challenge is way too hard or the candidate is not suited for the position. If you’r using my Git repos from the links above (or something very similar) then this should not be the case. At this point I advise to stop the interview process for those who cannot complete the task and move onto the next candidate.

For those that do solve the problem correctly I like to review the code and if everything is satisfactory I’ll continue on with the interview. Rarely is this the case. Most of the time I prefer to ask the candidates why they wrote the code the way they did. For example, I might ask someone who completed the Android task why they used the HttpGet in Android over a library like OkHttp or http-request. If the candidate had completed the NodeJS challenge I might ask them why they used the raw http calls instead of using libraries like restler or rest. The goal of such questions are to see how the candidate thinks. It helps expose more of their natural though process. Often you’ll learn a thing or two from candidates as well.

If you don’t find anyone who can solve the problem, repost the job posting to get some new leads. I’ve had to post a job a couple of times to get the correct person for the job.

Step 4: Culture Fit Evaluation (2-4 Hours)

Goal: Evaluate if the candidate is a good fit within your company culture.

At this point the candidate has passed your HR, Tech and Programming screenings and you probably feel fairly certain you want to hire this person already. However, don’t let your excitement be the determining factor – you still need to determine if this is a person you and your team can work with and enjoy being around. At this point I like to bring the candidate into the offices to meet the team and have lunch with them. I usually like to have them come in at a particular time (11am-12pm sometime) and then I’ll schedule a team lunch. We’ll all go to a common spot for the team, such as Chipotle or a similar restaurant that we frequent near the office. Don’t go to a fancy restaurant or some place that the team does not frequent. If you do go somewhere fancy or new the team will not be 100% present and in their normal atmosphere. I want normal, day to day simulation at this point. This will allow us to gauge their personality and hopefully identify any traits that are not so desirable in our team. If we find that someone just doesn’t feel right, we won’t offer them the job. We as a team need to be able to get along with this person and enjoy their company. We’re going to be spending a lot of time together and if we don’t like each other, well, that probably won’t work out too well.

Example – I had someone get through all 3 steps with excellent results. I was excited about this candidate. We took them out for lunch and found that they were very rude, extremely passive aggressive and down right mean at times. We’ve all had that common feeling where we know that we do not click with the person across the table from us. That is the feeling we had and I knew this person was not right for the team and in the end I did not offer that candidate the job.

During this step you should also give the candidate a tour of the office/campus/etc and talk to them about the position to gauge their interest. Ask them general questions about the company to see if they’ve done any research into the company. In short – just get to know the person. Ask yourself a simple question: “Is this someone I’d enjoy being around for an after work drink and/or meal?” If the answers “No”, then you have a red flag you need to evaluate.

After the candidate leaves, chat with the team to see what they think (if this is your first hire, use your gut feeling) and if the candidate seems like a good fit, then offer them the position. If not, move onto the next candidate.

Wrap Up

Finding good talent is hard and saving money while doing so complicates the matter. The four steps above will help you save time while finding you the best programmer for the open position you have. Don’t be afraid to not move forward with a candidate. Its better to wait for the right candidate than to have a bad hire. Remember, Step 3 is the equalizer. This is where the main separation of “can-do” vs. “cannot do” candidates will emerge. I’m always surprised to see how many people never make it past this stage. Best of luck in your hiring.

* I’d love to take full credit for creating the programming challenge on my own, but I cannot. The implementation of this challenge was inspired by a company by the name of Integrum (who no longer does programming) for this method of programming challenge.