What's with the "programming test"!?

I was having a chat to a mate of mine this morning, who had just returned from a job interview where they had asked him to conduct a programming test. I asked him what the test entailed, and what more importantly was the point of said test. His answer flared up my career colon again, thus the resulting post.

So, the programming test was how to implement a file copy operation. I asked him if the interview process also included an Object Oriented design test, or an algorithms test…nope, just the programming test. Riiiighhht!

Why does this flare up my CC? Well, this goes towards my “Why I’m not surprised that software projects fail” manifesto.

I mean, firstly, I don’t store all the API and SDK objects, functions, method signatures, whatever in my head, that’s what the programmers guide is for. But more importantly, knowing how to implement a file copy function without an understanding of why you would implement a file copy function is where the red ink is set free. I’m appalled that companies still see the “programming test” as a viable way to vet talent. In fact, unless the job you’re going for involves writing software that directly talks to the file system as part of its core capabilities, then the correct response from a candidate should be, “Um, I’d just use a framework”. That’s why development communities far and wide have frameworks; it’s so you don’t have to give a toss about System.IO.File blah blah blah during a job interview!

And then there is the issue of why would someone care if I knew how to write a file copy function, ahead of what the difference between an interface and an abstract class was. Or when would I use encapsulation? Or in my design, how would I choose between polymorphism or inheritance? Or what pattern would I recommend for dealing with a general or specific problem?

It wreaks of a bigger problem, where organisations are focusing on the low level technical capabilities of people, rather than the overall software engineering capacity of people. The reality is, and I assert this to the peanut gallery, that we have people within organisations, such as Directors, Managers, generally non-Software Engineering folk, trying to ascertain whether an engineer is fit for the job. And what’s more, they are focusing on the most basic of tasks as the process for evaluation. Duh, can you program hello world? Duh, can you write me a form with a button? Jheesh, I mean, who cares if you know you’re way around an IDE or a language? Just because I can carve the Sunday roast doesn’t mean I should be applying for surgical positions at my closest hospital.

I’m really getting the feeling that the lunacy of the Software Engineering industry (and I use that term sparingly, as I don’t want to encompass the whole of IT, just the bit that involves designing, developing, deploying and maintaining software) is spiralling out of control. And that I will be forced to encounter more crazy capability and skills estimation tools such as programming tests, and interviews with recruiters (jeez, don’t even get me started on that…”Um, can you tell me what you know about the difference between .NET and Linux??” WTF!!? Um, one is a framework and the other is an OS!!! I should ask them if they can tell me the difference between a Toyota Hilux and the dark side of the moon!).

Am I completely off the dial here people, am I the only one who sees these things as not only completely crazy, but also diabolical! Or maybe I should just keep quiet, and save all my experiences for my own sitcom! Yeah, sitcom!