It’s been a couple of years since I got involved in lead talent recruitment. Being a programmer, I have also been involved in external processes which have helped me find excellent ways of creating selection processes for any area.
I have long been collaborating with a recruitment agency called Multiplica Talent. In comparison with other recruitment agencies, its specialty lies in evaluating the candidates in a technical way before they are introduced to the clients. My role in this company focuses on having a modern and effective selection process for the talents we seek.
Given that the selection process for the programmer positions was relatively new, I found a not very optimal method: it consisted in sending a regular test to the candidate in which we could measure his knowledge of certain languages. The candidate had to invest around 5 hours. Many of those candidates did not send their test on time or they just did not answer.
What I first identified was that the type of test wasn’t attractive at all. Computer programming tests could be so boring that at the end of the day they also reflect the company’s culture. If a test is tedious, doesn’t require creativity and has a suspicious difficulty, the candidate’s motivation and interest will be at rock bottom.
Let’s also talk about time: unless a candidate is searching actively, which means he can invest plenty of time in all the processes of the different companies he is applying for, it will be difficult for him to find 5 free hours on weekdays and even on weekends.
Once I had this information, I started designing a selection process for programming candidates. It consists on 3 filters which assure us that we can get to know and evaluate the applicant in an optimal manner, yet keeping a balance with the time invested. The new process lasts 2 hours: 15 minutes in a quick screening test, 1 hour for the specialized programming test and 45 minutes for the interviews.
In this article I will discuss the first filter: the quick 15-minute filter. It consists of a test that helps us screen job applicants who are interested in the vacancy we are offering but also have programming and problem-solving skills.
Many programmers, if not the majority, know that there is a filtration test called Fizz Buzz. This test consists in writing a small program that prints out numbers from 1 to 100. When the number is a multiple of 3 it must print “Buzz”, for multiples of 5 it must print “Buzz” and finally when the number is multiple of 3 and 5 it must print “FizzBuzz”.
This procedure has been applied in many companies as a baseline to start the selection process since it put to the test the applicant’s coding and problem-solving skills. It also shows if they know to program because, as incredible as it might sound, many of them who start the selection process do not know how to do it. It finally enables them to show some other skills about code structures and good practices, among others.
This programming exercise has become very famous, and in my opinion, it’s been used too many times. It’s even already taught at school. I personally find it old fashioned to apply it nowadays.
Many organizations apply exercises about automation and code application tests. However, I’ve seen they use highly complex problems which are not related to the kind of work a candidate would have at work and sometimes they also use it as the only test to “measure” the candidate’s skills.
I believe a company’s selection processes must be human and consider the candidate as so. I believe that they are not a code monkey and that an algorithm test won’t validate their code production skills either. If the job requires algorithm creation then it may be put to the test. Otherwise, it’s a waste of time.
The selection process exercises must be as close as possible to the real duties that are going to be performed, if they need to be validated. I’ve never heard a Back-End developer say that he has to invert a binary tree or to write a searching algorithm from out of the blue.
I decided to implement a first Fizz Buzz-like filtering exercise without the Fizz, though. A first step on the selection process which enables the candidates to show their programming skills in a natural way without leaving them up against the wall. And at the same time to be fun not boring.
I thought this exercise would not necessarily have to be aligned to the type of work—I mean the programming language or the type of application, and it wouldn’t have to have the unnecessary complexity for them to demonstrate their capacity to write complicated algorithms that are barely used.
For the creation of this first filter I established the following rules to do the exercises.
Based on the previously mentioned, I was able to create two exercises: there are two so they could be assigned randomly, and consequently be able to measure each one’s sucess, in case it was necessary to be modified.
Each of the exercises comes with an input, which is the exercise’s data. That data must be used in order to process them according to the problem and subsequently get a final answer. This final answer is a number, so it doesn’t matter if the clue that was created to get to the answer is “nice” or “unlikeable”, the matter here is to get to that final answer.
It is worth noting that those two exercises were already applied to over 100 candidates worldwide.
The input of the exercise could be dynamically generated, that is to say, every time an exercise is created this will have a single correct answer.
The next code block is the data generator that is needed in the first exercise “Winning the lottery”.
input = (0..1000).map do |i|
"#{["+", "-"].sample}#{rand(1...100)}"
end.join("\n")And the code to get the answer could be written as follows.
input.split("\n").map(&:to_i).sumFor the second exercise “The strongbox”, the generator looks like this.
input = (0..10000).map do |i|
[*('a'..'z'), *(1..100)].sample
end.joinAnd the code to get the answer might be as simple as this.
input.delete("^a-zA-Z").sizeThe code to generate the answers looks pretty simple, since it is part of the flexibility and simplicity of these exercises. For programmers this could be counter-intuitive. We are used to doing more complicated exercises or to do exercises that represent a bigger challenge.
This is absolutely intentional. The idea is to leave room for creativity in the code.
Candidates have answered in many ways. I’ve come across complete and excellent answers, others quite complex, and some others unnecessarily complex. Any programmer that could send their exercise is because they came up with the right answer.
The following scripts are a sample of what the applicants answered.
The strongbox in Javascript:
var totalLetters = 0
inputArr.forEach(function(element) {
var letters = /^[a-zA-Z]+$/
if (letters.test(element)) {
totalLetters++
}
})
console.log(totalLetters)In PHP:
$input = str_replace('1', '', $input);
$input = str_replace('2', '', $input);
$input = str_replace('3', '', $input);
$input = str_replace('4', '', $input);
$input = str_replace('5', '', $input);
$input = str_replace('6', '', $input);
$input = str_replace('7', '', $input);
$input = str_replace('8', '', $input);
$input = str_replace('9', '', $input);
$total = 0;
foreach (count_chars($input, 1) as $i => $val) {
echo "<p>hubo $val instancias(s) de \"" , chr($i) , "\" en la palabra.</p>";
$total+=$val;
}
echo "<p>valor final = $total</p>";And finally, in Python:
clave = 0
for caracter in mensaje:
if caracter.isalpha():
clave=clave+1
print("La suma total de los caracteres es: ", clave)Then, Winning the lottery in Javascript:
AdjustFrequency (array) {
let lotteryNumber = 0;
array.forEach( (element) => {
lotteryNumber += element;
});
return lotteryNumber;
}In PHP:
foreach($lista as $string){
if($string[0]=='+'){
$frecuencia=$frecuencia+(int)(str_replace(['+','-'],'',$string));
} else {
$frecuencia=$frecuencia-(int)(str_replace(['+','-'],'',$string));
}
}
echo $frecuencia;And finally, in Python:
def frecuencia(input):
resultado = 0
with open(input) as frec:
for linea in frec:
if linea[:1] == '+':
resultado += int(linea[1:])
elif linea[:1] == '-':
resultado -= int(linea[1:])
return resultado
print(frecuencia('input.txt'))Each of these scripts has its interesting side, something that reveals who the talent is, how he read the exercise and how he solved it through code. It also reveals what he sought to demonstrate: if he intended to show the simplicity of his solution or his skills, he’s got to solve it in a more elegant way. In some cases, it reveals what the talent knows about the language he chose to code in.
After all, what we want is to know the candidate: the way he moves, how he thinks, his aims and ambitions. This 15-minute test let the programmers show their skills their own way, and as it is the starting point of the process, we managed to show that our process would be fun, different and modern.
This certainly helped identify talents with a more complete focus than Fizz Buzz. It gave us a tool so we could filter candidates with problem solving skills in order to demonstrate interest on the rest of the selection process. More important, it showed us part of the personality and perhaps the talent’s skill level.
The conclusion of the whole story is that Fizz Buzz has been used too many times and the talents usually learn it in the basic steps, these kinds of exercises are tools that help identify talents in selection and recruitment processes. That they don’t need to be boring or complicated to give the programmer the chance of expressing his ideas, allowing for understanding and creativity when it comes to developing solutions.
I feel this last point is important to talk about. Why should programming stop being fun and creative? At the end of the day, most programmers code with passion and heart. But also, will it be possible to have a similar test for other professional disciplines?