Coding Exercises for Software Developer Interviews-Useful or Detrimental to Your Hiring Process?

By John Maniscalco

There are certain tests we all prepare for in life, such as driving or the SATs. Yet when it comes to hiring developer and software engineering positions, testing a candidate’s coding abilities in specific languages is a common part of the interview process for many organizations. When a company hires a developer, they need to see more than a resume and portfolio to know if the candidate can do the job. Expect coding exercises to take place at some point during the interview process.

Each organization has different ways of determining how these tests should be administered and when to conduct them during the interview process. Organizations also vary how they use the results when deciding to pass or make an offer to a candidate. Springing coding exercises on candidates or requiring a candidate to code, before even phone screening, without their knowledge from the start can back fire on the organization and turn the candidate off the opportunity.

There are several variations of coding exercises that employers administer. Whiteboard Tests, during an onsite interview; Coding Challenges, administered prior to an interview or during an onsite; and Pair Programming, a newer variation we are seeing used more often. There are several reasons why hiring managers choose these tests to give prospective candidates for evaluation, but is it benefiting your hiring process or detrimental to your process in competing for technical talent in this tight candidate marketplace?

Whiteboarding:

This is a very common exercise provided to candidates during an onsite interview. Some are very short in nature, and others can be detailed, long and stressful to a candidate. Keep in mind what insight you’re trying to gain from the exercise to ensure it’s not overkill or a turn-off to a candidate. Usually a hiring manager is administering whiteboard tests as an evaluation of how the candidate thinks, communicates and problem solves.

Not only do candidates have to demonstrate their skills live and usually in front of an audience, but they must answer questions to explain their process, either during or after working through the scenario. This can be very stressful to some candidates and may not be the best indicator for future performance.

It’s not a good idea to give the candidates any code tests that could benefit your company. The candidate might take it as giving free labor for those hours it took to solve the problem. Always ask the candidate if they have any work they can give you ahead of time that shows their coding skills, which can help speed up the interview process.

Coding Challenges:

More often we see this as the most popular option for hiring managers, but most frustrating for the candidate-all dependent on when and how it’s done. Typically administered during an onsite interview, it’s also common to see this implemented as a take home exercise, allowing a candidate to not rush through and provide you with their best work. Often hiring managers use this to truly evaluate the candidate’s elegant code and problem-solving abilities.

Most candidates today are working and can be extremely busy. It’s best to give the coding exercise after the first interview, whether as a take home test or as part of the next onsite interview. And remember, asking candidates to do this before even requesting an initial phone interview is a big ask and met with the most resistance of passive candidates. Try to stay clear of methods involving administering coding challenges that are meant for a candidate to struggle. It won’t show their best work and they could pass this knowledge to friends in their industry.

Pair programming:

This is a new kind of test that’s catching on. Companies take one of their employees and pair them with the candidate to shadow and work together on a real-life coding problem. This test can evaluate their skill but takes the pressure off the candidate by having someone alongside them. These exercises provide a more realistic testing environment and give the candidate a real glimpse into what their daily work life would be. While also allowing the team members to evaluate the candidate’s code, thought process, communication, team fit etc.

Although it’s common to not want to have candidates see your proprietary code in an interview-you can always implement a non-disclosure agreement or set up similar test environments to keep the code safe. Some candidates will feel like they are providing free labor by working on your actual product, which could be sensitive to some, but benefits the candidate just as much by allowing them to see exactly what they’ll be working on and how the teams work to ensure it’s the right fit for themselves as well.

The technical interview process can be long and daunting; when choosing which method is best for your evaluation keep in mind that these developers are in such high demand and you don’t want to miss out on great talent by asking for too much of them and complicating the interview process. If you require any of the above variations of testing, consider cutting out other steps of your interview process to keep candidates engaged and to not lose to your competitor who shortened their process and made an offer sooner. Don’t let it become a detriment to your interview process.

Lastly, it’s important to work with your vendors that represent some of these in demand candidates and explain your interview process clearly. Trust the experts, like Micro Tech Staffing, to help shorten the process and keep the candidate engaged in your organization’s opportunity. The technical challenges in the interview process work best when everyone is as prepared as possible for what to expect.