Alternatives and suggestions for candidates and companies to avoid tests
In part one we covered types of technical tests—their relative costs, and why organizations need to understand the costs to the candidates if they want to attract the right type of candidates, and at what point in the process to test.
We haven’t covered alternatives yet. Larger organizations have the benefit of HR or recruitment divisions to bear the brunt of the early cost of the recruitment process—they can call candidates individually to check out interpersonal skills and to make the candidates feel wanted. Smaller organizations don’t necessarily have this, but they do have the benefit of being more flexible. If the brunt of the recruitment process falls on developers (or tech leads, CTOs, or other people in the technical organization) then obviously these organizations are trying to keep the time costs down—every hour invested in recruitment is an hour not spent on coding the company’s money-making product. But these techies are also in a much better position to be able to judge a candidate, and don’t always need to rely on one channel (the technical test, for example) to perform this judgment. They have other alternatives.
Dissecting the hows, whys, and why nots of screening candidates
Because so many of us have experienced both sides of the interview table, the London Java Community has a slight obsession with discussing approaches to recruitment. The nice thing about these conversations is you see both points of view—the candidates and the techies who are responsible for hiring.
Our most recent conversation was (again) about the value of technical tests during the interview process. I’m not sure there’s another topic that generates such diverse and yet all “correct” points of view. If there’s one thing I’ve learnt from seeing this conversation again and again, it’s that there is no One True Way to test a candidate’s technical ability. If there was, we’d all be doing it.