Great hiring is an important part of maintaining and growing any company. For a software development firm, it’s critical to have a process for identifying the best developers out there and finding those that are not only technical standouts, but that also fit your organization’s culture. We’ve been trying to perfect this process for years and what we’re doing now really works.

Build the Pipeline

If your firm is like ours, you have a recruitment program that continuously builds your talent pipeline. We utilize a variety of means to identify as many potential candidates as possible, such as:

• Job postings and ads
• Recruitment events at universities, hackathons, and bootcamps
• Social networking on platforms like LinkedIn
• Word of mouth
• Employee referrals

Screen and Filter

The job of talent acquisition doesn’t end there. Once you’ve identified a potential candidate, they need to go through a screening process. The goal of the screening should be to filter the raw list of candidates for cultural and technical fit within your organization. Not every qualified candidate is right for your organization. Screening should look at:

• Is there a “cultural” fit? How does the candidate align with your core values? Hopefully, your organization has defined a set of core values. We utilize our core values at multiple touchpoints with all team members and that starts with recruitment. If there is not alignment with the core values, this candidate just isn’t going to be a good fit in your company.
• Are they experienced in your technology stack? It’s usually not enough that a candidate lists your technologies on a CV or resume. How extensively have they worked in that stack? If they have experience in multiple technologies, which do they prefer to work in?
• Do they have a passion for their craft? This may be one of the most important questions to answer. A passionate developer is more likely to remain abreast of current trends and technologies, to pay more attention to the details of their craft, and to contribute to a learning culture within your company. When comparing similar candidates, I will always take the one with greater passion and lesser experience over someone with more experience but lacking passion.
• Do they have any recreational coding activities or projects? I tend to value developers that have personal projects or hackathon experience to share and it’s another great way to gauge passion. Look for developers that code recreationally. If they have a GitHub account to share, that’s even better.
• How well are they able to communicate? We don’t require developers to be great public speakers or orators, but it is important that they are comfortable participating in group discussions. We also provide training for team members to help improve communication skills, but if the candidate can hit the ground running, that’s a bonus. I will look for a comfortable speaking tone and pace. In the technical screening, I also assess their ability to use jargon appropriate to their technology stack.

Test

Now that your recruiting department has provided a list of screened and qualified candidates, it’s time for the technical screening. There are all kinds of approaches and I think we’ve probably tried them all. The goal of the technical screening is to gain insight into the candidate’s actual level of proficiency. This can be tricky. I think most hiring managers have, at one time or another, completed a tech screening where the candidate could speak the language, answer the technical questions, and display a general competency for the position only to find out after hiring them that the technical screening failed to accurately assess their skills. Our solution is to include a coding project test in the process.

Once a candidate passes the initial interview screening, the recruiter provides them with access to a code repository along with a set of instructions to follow in advance of the technical screening. The specifics of the project are up to you but, in general, here’s how we do it:

• Make it simple. Our sample includes a web-based front-end, an API, a database and unit tests. The whole thing is based on a limited number of tables (ideally, one or two) with the corresponding REST API endpoints and front-end screens for basic CRUD operations.
• Provide the code. The code is in a cloud-based repo (we use GitHub) and it builds without errors. It could be a valid part of the exercise to include build errors to see if the candidate can find and overcome them. We have tried versions that come with build errors but generally find we get better engagement when the initial solution builds.
• Include opportunities for improvement. We intentionally provide code that would not pass a code review, and we don’t tell anyone. What the candidate notices and/or chooses to address will tell you a lot. The unit test project includes only a single unit test and omits the rest. Naming conventions for JavaScript variables and CSS classes are intentionally inconsistent. There is no error handling built into any of the API endpoints.
• Give them some tasks. The solution we provide has a largely unstyled front-end. We include a basic design document with desktop, tablet and mobile views and a task to apply the styles and to make the site mobile responsive. We have the candidate add a new field to a database table and make sure the API and front-end are updated to include it. There are a few more tasks included as well, but you get the general idea.
• Test what is meaningful to you. Make sure the project provides an opportunity to focus on the kinds of things that are most important to you. Identify things within your technologies that you would like to assess and include opportunities for the candidate to code to them (and to later speak to them).

Chances are that the candidate will have questions before they start and as they work through the tasks. The kinds of questions they have will be your first data point in the evaluation process. And it’s also OK if a certain portion of candidates just opt out. You want people that are open to being challenged and that are not above the process. The kinds of people that embrace the process will make better collaborators and teammates.

Assess

The final step in the process is to hold the actual tech screening. For this we focus almost entirely on the coding project and will follow this general agenda:

• Code review. In advance of the screening, I will do a complete review of the code and identify items that should be discussed in the screening. This can include questions about architectural decisions or just general implementation details and strategies.
• Demo. The first thing we do is have the candidate run a live demo of their solution. Here we get a glimpse into how well they handle interactions with clients and communicate under pressure. Where they focus and how they run through the user flows will also be informative.
• Code walk-through. After the demo, I have them show off their code. We usually start from the database and work our way back through the API and finally to the front-end. They are first asked to explain the code, how it works, what changes were made from the original, and why changes were (or perhaps were not) made. This is where I will also talk about the things I found during code review. Here, I’m looking to make sure they understand the code they were provided as well as the code they wrote. If they got help or if they just use a little Google-fu to find and paste some code, we will learn that here.
• Live coding. I try to have at least one or two things that would be good features to change and have them walk through making the changes in real time. Some examples might include having them add paging or sorting to a list view (which will require changes in the API and front-end) or have them add a missing unit test. If they don’t know how to do what is being asked, that could be really useful, especially if it is an entry level developer. It’s important that a developer knows how to admit when they don’t know something. It also offers an opportunity to assess how well they take instruction and how capable they are of grasping new concepts.

We have been using this process for a while now and it’s proven to be incredibly effective. Since making the change we find that new hires are a better cultural fit, have aptitudes that are in greater alignment with the expectations for the position, are more inclined to be collaborators, and bring a greater passion for learning and for their craft. The next challenge is how to retain and nurture the great new team members you’ve found, you can read about our process here.