Stop Imitating Google: A Better Process To Hire Software Engineers

By Drew Ulmer

Chances are your company is not a high-profile-tech-giant in Silicon Valley that employs the top 0.01% of developers, so why should you model your hiring process after theirs?

I’d like to share a better, simpler process to interview software engineers. Consulting with clients from across the country, in all different stages of growth, has allowed us to hone the art and science of a remote interview process that works for normal people, reflects a typical working environment, and is optimized for hiring great developers over great interviewers.

Below is an outline of the process that we run to hire our talented developers and help our clients build their own internal teams. Hopefully some of these strategies will be helpful to other hiring managers out there too.

Phone Screen

The first stage of the process can be run by HR or the hiring manager and involves a basic phone screen to make sure that the interviewee is a good fit for your culture. You can learn a lot by asking the interviewee what their ideal role looks like, what was good or bad about past projects they completed, and what they are expecting for compensation.

Your objective on this call is to find out if you would want to work with this person and to pitch them on the value of working with your company — the salary and benefits, what your work environment is like, and the meaningful projects they can expect to take on. Presuming that there is mutual interest at the end of the call, set some general expectations about next steps.

Sample Task

After the phone screen and your approval of the interviewee, it’s time for a sample task. This is an essential step because it allows you to evaluate how they approach, collaborate, and execute a task that closely represents the type of work you’re actually hiring them to do. Set things up by sending them a sample task and inviting them to a Slack channel where they can ask you questions.

Our typical sample tasks details an assignment with certain requirements, but also leaves room for interpretation. Be sure to design the task in such a way that the interviewee will need to reach out for clarification at least once. This encourages discussion and feedback, which is where Slack comes in. Slack is how our team typically communicates and we invite the interviewee to collaborate with us there because we want to evaluate how they ask questions and respond to feedback before the task is complete.

Since most software developers already have day jobs, we respect their time and give them a weekend to get the work done. Not only are interviewees applying to the job with different amounts of experience, they are also applying for a certain role with different expectations and duties. That’s why the sample task they are given should reflect both. Here are a few examples:

Interns are often hired either while they are still in college or right after they graduate, so they do not have much experience. The sample task we’d give them is something they can write in an hour or less, and our expectation is that they will need significant on-the-job training.
Junior and mid level applicants receive a standard sample task that asks them to build something and it generally takes under two hours.
Senior level applicants are applying for a role that requires more reviewing/coaching than writing code. As a result, we ask them to do an internal review on sample task to ensure they can recognize performance, maintenance, and architectural problems. This takes about two hours.

Internal Review

After the sample task is submitted, we do an internal review of their work. We run every submission through the same basic checklist.

Does the code run? Ultimately all code written gets “tested” by the end user so make sure they are paying attention to that experience.
Was everything from the task completed correctly? It’s very common for people to miss one or two items. These should be discussed during the technical interview.
Did they incorporate feedback from questions in Slack or email? This is a key point to address during the technical interview and find out their reason for doing it differently. Communication is one of the most biggest factors in project success so being able to articulate why something was done is very important.
Are there any questionable architecture decisions or performance issues? Once again, very important to note and get to during the technical interview.

All of these things provide context for our next conversation. Identify areas that are important for your business and workflow during this process and make sure that the candidate knows you’re looking for performance in those areas. For example, if your developers regularly interact with end users, give your interviewee an example “end user” from your org to interact with. If you place heavy emphasis on coding conventions, let your interviewer know your standards.

As a matter of practice we always extend a technical interview to anybody who takes the time to complete our sample task. Too many red flags make them less appealing - however, everything is relative to their level of experience and the role we’re filling. Try to remember that people can get nervous during interviews which present more pressure than they’d feel working day-to-day, which may account for some simple mistakes.

Technical Interview

The objective of the technical interview is to make sure that the interviewee can actually do what they say they can do. This is your chance to see how the candidate collaborates, to ask them software development questions, and to see whether their skills line up with the salary they are expecting. Before the interview, we always ask that they be ready to screenshare and have their editor open because they will be asked to code. Remember: if you’re hiring someone to write code, you need to see how they write code! Asking how many golf balls can fit in Yankee stadium is a waste of everyone’s time.

We start our technical interview with some general software development questions that aren’t specific to any language, framework, or industry - think Object Oriented Programming concepts or basic programming constructs.

Up next is screensharing and discussion about the sample task project. Have them walk you through their solution so you can see how they approached the problem. If they didn’t do something, made a mistake somewhere, or skipped a certain step, this is a great moment to ask them what they would do if such a scenario came up. If they know what they're doing, they’ll notice their mistake and be able to explain how to fix it. Encourage the candidate to implement a fix or solution right there on the call with you. Encourage them to think aloud as they type or problem solve. You’re not looking for perfection because you don’t hire developers to deliver perfection. You are looking for an idea of how they would solve it.

The next step is to get the candidate writing code and solving problems by having them fix issues from code review or by implementing a new feature. This gives us a chance to observe how the candidate works: how long they deliberate, whether they can articulate their decision making, and whether they can put their ideas into code.

Towards the end of the interview, I ask about their development environment, what technologies they’re excited about, and give them a chance to relax a bit and talk about their passions and interests. Following the interview, I give them my decision (or the client a recommendation) as soon as possible.

If this sounds like a better process to hire but you need a hand with the technical pieces, we can help you find great developers for your team. Reach out to us below to get the conversation started.