Hiring Tests For Programmers Are Actively Harmful
The whole process of hiring programmers is fundamentally flawed and broken. I could just stop there, but unless you're in the IT industry it's hard to realize how true this is.
I am looking for another IT job after being out of programming for three years. I applied for a mid-level Java position thinking that would be a good way to ease back into the industry. And then I was sent a link for an online test to take to prove that I was a good candidate for the position and this caught me by surprise. I don't remember the last time I took a programming test. The vast majority of my positions have been by reference where the referring person or contracting company vouched for my technical abilities including Java programming skills and the client accepted it as given fact. Referrals by respected technical people seems to be a powerful way to successfully hire skilled technical folks.
The test in question was a Java 8 syntax test. I last professionally used Java 6, so I knew that Java 8 had some new features and syntax within it, but had not looked into it. I found a reference that told me the new features and showed examples of each. Most of it was inspired by functional programming languages, the rest being much needed improvements to existing Java class libraries. I started the test and found that the test was totally syntax oriented. Lots of examples of slightly different (by a character or two) lines of code and the question asking which one had the right syntax. A few questions in I stopped taking the test and mentally prepared myself for this prospective employer to hire someone else.
I don't regret stopping the test after only a few questions. I was a senior Java programmer and could write code with the best of them. It is my observation, born of more than 20 years experience both writing Java code myself and leading teams of Java programmers, that there is no link between memorizing syntax and being a good programmer. Let me go further, the syntax memorizers are generally worse programmers, so optimizing your hiring pipeline for these candidates is actively hurting your chances of assembling a good team.
I have a bad memory, but between keeping a couple of Java books close at hand and the compiler in my IDE watching me carefully, I get it done. My advantage is that I know what I want to get done, so getting the syntax right is hardly even a speedbump. Even if you hire the candidate with the most perfect syntax memorization, what happens when the Java programming language gets more new features? Will you retest them, or perhaps wished that you'd hired programmers who get it done and for whom syntax is something that can be looked up?
The bigger problem is that technical interviewing, the way it's currently enacted, is fundamentally broken. Much of the process is driven or mandated by the company HR department and many of the managers making final decision on which candidate should be selected have no programming experience, so they rely on proxies like test results, rather than being able to talk to the candidate and determine whether they are genuine or trying to get by on bravado and memorized syntax.
There are ways to fix the interviewing process but I'll write about them another time. I strongly suspect that most corporations will not be changing any time soon, so this will give the smaller IT companies and departments an unfair advantage in the hiring marketplace.
In the short-term, I will create a Java 8 project and code up an example application that does a little of everything and uses as many different parts of the Java programming language as I can fit into it. Then when I'm asked to take a test I'll offer them the choice of "no" or "look at my nice example program" and see which they pick.