On online programming tests
Well put.
These are real-world skills that programmers need to have, and yet codility (and similar things) don’t test for them. Codility concentrates on things which can be automatically tested, but which are really only useful skills, not necessary ones.
The other thing it tests for is the ability to resolve a concrete problem from an abstract representation. By and large, this is a task which is accomplished long before a single line of code is ever written.
Sure, they’re useful skills; and sure, programmers benefit from having them. But they’re largely academic in a real world setting, and not (in my humble opinion) what employers should be looking for from new candidates.
In full:
With that Codility test, you had to determine how many disks fit into a well. it was more of a logic exercise than anything. I think I did OK, but I only got 67%.
My approach was to drop each disk into the well until it couldn’t move any further, mark that position, and repeat. Thinking about it now, I can vaguely visualize a better solution, but I can’t really get it down because I’m worn out.
Sorry but I just need to interject with why I think Codility (and similar tests) are a complete waste of time, money and energy.
When was the last time anybody, and I mean anybody, worked on a programming problem like this for their job? I mean, unless your job is writing the software for machines that drop disks into wells (disks and wells that, I might note, break the laws of physics in several hundred ways).
As an employer, I would want to know how good you are at solving real-world problems, problems which involve things like:
- looking up API documentation: I’d want to know if the programmer knew where to find the correct version’s API documentation online as well as how to navigate it and retrieve the information they need
- debugging something: I once heard of an idea where recruits were given real-life bugs to fix from the source code, and were paid for fixing the bug even if they weren’t hired (so long as the patch they submitted actually fixed the bug). I wouldn’t go that far, but I would like to see them use debugging tools to locate and then fix a bug, as well as see how they handle version-control software
- writing something quick-and-dirty using a toolkit/platform they’ve never used before. This is the least important component, and is more for my considerations about the longevity of the position than anything; I want to know that if I’m hiring someone for 20 years, they aren’t going to drag the company into a rut by insisting on using outdated software simply because they’re incapable (or unwilling) to use new toolkits and platforms. It’s their reaction to the test that is the real tell; even if they make hundreds of mistakes, I’m really just looking for candidates who are eager and willing to try things that are outside their comfort zone, rather than candidates who are ‘good’ at operating outside their comfort zone.
- willingness and ability to conform to a style guide (this one is pretty important, but quite hard to evaluate based on a short interview - seeing a code portfolio on something like github is invaluable)
There are a few other things, too.
These are real-world skills that programmers need to have, and yet codility (and similar things) don’t test for them. Codility concentrates on things which can be automatically tested, but which are really only useful skills, not necessary ones. Writing bug-free code under time constraints isn’t something that many programmers are even capable of, let alone good at. Neither is it a particularly worthwhile skill - bugs can be fixed, and time constraints can be moved in the real world. The other thing it tests for is the ability to resolve a concrete problem from an abstract representation. By and large, this is a task which is accomplished long before a single line of code is ever written. You sit down with the client and discuss the problem, take notes and then later formulate a solution. You can ask for more information, refining your solutions as you go, and a dialogue exists between you and the client throughout the project. It’s useful to be able to work from less information, but it’s not vital that every single programmer on your team has this skill.
Sure, they’re useful skills; and sure, programmers benefit from having them. But they’re largely academic in a real world setting, and not (in my humble opinion) what employers should be looking for from new candidates.