Technical tests
In March 2014 I was made redundant (business unit closing).
I needed to get a job and I participated in loads of selection processes. Sometimes I received feedback, sometimes not. But I remember two specific processes because I received completely different feedback from “technical tests” in a matter of days
- Process A. Thanks for taking the time to complete our online testing. Unfortunately, your score did not meet the requirements of this role.
- Process B. Thanks for taking the time to take the test. I’m delighted to say that your solutions were all excellent
They were ver similar positions in two different companies. And the kind of tests were very different indeed.
- Process A is what I name as “certification test”. You don’t need to know how to develop. You just need the proper answers to the specific questions. You study, you pass, no matter your experience.
- Process B, was a typical codility test, but without the limitation in time. Codility tests are programming tasks around algorithms. I aced it, because I had been doing some courses and tests on algorithms not long before, to prepare for interviews. Besides, I remember getting stuck in one of the subtests, but with no time limitation, it was a matter of be calm and find a way.
Codility is a step forward from those text-based-pretend-you-can-develop-because-you-know-some-tricky-question tests. If you are recruiting for a developer, at least let her develop. However, I think it is too focused on algorithms. But knowing how to implement an algorithm doesn’t make you a good developer and/or a good fit for the company.
Problem is technical knowledge or competence is not he best indicator of fitting in the company.
Sure. You need some kind of test, to assess if she really knows how to program. But it doesn’t have to be too fancy. Fizzbuzz would do. Because most of us are paid to solve users’ problems.
However, I keep feeling there is no easy process to hire people. At all.
First published here