Exploring Technical Tests in the Software Industry

Technical tests are a staple of the tech industry interview process; they are used to assess the candidate’s communication, knowledge and problem-solving skills. This article will delve into the most commonly used ones.

Take Home Assignment

This type renounces on interaction and communication skills, which will have to be measured in a follow-up session, to allow for a longer time allowance to solve a problem. The advantage of this style is the ability to create a more complex set of requirements, allowing the candidate to choose where to focus their time and solve only part of them. If your company has an API third parties can use, consider using it in your tech test to create a test that will showcase your company’s tech offering. It will give you an edge in creating a personalised tech test, allowing the candidate to get comfortable with the domain. You can use it to ask them questions about your documentation, what they liked about it and the API itself, and see how they have integrated it into their software design.

Snippets-Based

This test required the candidate to analyse a piece of code and provide an answer on what it does, what’s wrong with it or what could be improved. It can be done both live or via a website or even email.

Asynchronous

It is generally used to see where each person focuses on when describing problems and possible solutions to the provided snippet. The candidate can be asked to improve, refactor, explain the code to a junior developer or conduct a pull request style review.

Live

It allows you to check their immediate response and thought process and how they arrive at their conclusion. It is the least realistic of the two since no one writes code like this. Developers rely on tests and IDEs with advanced debuggers to avoid keeping the entire program in the brain since it is, at best, a faulty version of what the computer already knows how to do.

Algorithm-Based

These types of problems are the most divisive. They are a time-effective way of checking a candidate’s communication and thought process, but they can be conducted while focussing on the wrong aspects. Please don’t treat them like a 100% guaranteed test of data structure and algorithm knowledge; use them to set a common ground that will allow you to test a candidate. Give the candidate time to prepare and tell them which structures will be used and which won’t to let them brush up and gain confidence. Have a set of problems that you will use repeatedly, and pick problems that can be solved without specific rules not applicable to other similar problems of the same type.

Pair Programming

This is the most open-ended one. Any problem can be solved in a pair programming setting. The emphasis here is all on communication and collaboration. For this test, define a few problems that respect the following characteristics:

1. Find a problem that is quick to grasp

The core of the problem should be simple and allow for multiple ways to implement a solution. This is because you want to facilitate a discussion on the pros and cons and ask the candidate to elaborate on a possible plan of action.

2. That can be extended

Especially in a pairing session, getting quick victories will do wonders for the candidate’s morale. Ensuring that the test is divided into multiple steps is useful for progressively adding complexity to a project and giving multiple stop points during the interview. Not all the steps must be completed; they are there to give an idea of what the full project will do and see how each developer will use that information while writing their solution.

3. That doesn’t require too much specific domain knowledge

It is hard to create a solution while understanding new concepts. If there is specific information that you want them to use, explain it well and be ready to facilitate their understanding and comprehension of it.

Questions about programming languages and frameworks/libraries

This type expects the candidate to answer specific topics, usually regarding a tech stack used by the company. When creating your list of questions, consider how easily a candidate could find the answer in a typical work environment. A good question should provide a starting point for an in-depth discussion about when, why and how to use that tech stack, framework or software design. Allow the candidate to explain it and ask follow-up questions by asking them to provide analogies and past examples of when they’ve implemented it, if applicable. Don’t waste their time by asking trick questions or a framework’s specific inner implementations; they are easily searchable online and won’t allow you to discover the candidate’s strengths and passion.

Conclusion

All these approaches are helpful to judge a software engineer’s skill set; decide which road you want to take, if focused more on technical solutions or more communication, and see which one will help you get a more exhaustive answer in your interviews.