After all the years I’ve spent working with databases, I am continually shocked by how little I know. The power and facilities of relational databases have increased enormously, and we struggle to keep up. One has, of necessity, to spend an increasing portion of the working day in retraining. To a hard-pressed project manager, time spent on familiarising oneself with current ideas and practices looks like wasted time because it can’t be fitted logically into the chart. He therefore discourages it. In consequence, one can waste time creating a procedure that can be done much simpler with a new feature or third-party product, simply because one hasn’t had the time to check it out.

It is the knowledge about my lack of knowledge that gives me a terror of Technical Tests.

I was recently persuaded, against my better judgement, to apply for a well-paid job as a DBA/Developer. (They pronounce it as deebeeaye stroke developer, which sounds like a closet office liaison). I was sat down in a room, given a brief synopsis of the company, and then given a technical test.

My initial horror, which stems from the fact that the more one knows about SQL Server and relational Databases, the more aware you are of your ignorance, turned to delight. I was back in primary school. What is Normalisation. What is the use of an index? How would you pass output variables via ODBC? What is a transaction? Eh?

It was like waking up after a knock on the head, and the doctor asking you the name of the president of the United States to check that you are Compos Mentis. After rattling through the answers, I asked the interviewer what sort of creature wouldn’t know the answers to this sort of question. Bleakly, he replied that they’d already interviewed five candidates for this specialist role and two of them hadn’t even known what the normalisation process was. I was the only candidate so far who had even understood all the questions, let alone answered them all correctly (which I had, I hasten to add).

So, it seems that agencies are putting forward candidates for important roles who profess to having database skills yet are entirely ignorant of the basics.

I then sat a second, practical, test, using a sample database, that involved writing a stored procedure or two and a few SQL expressions. This was harder, but only because there was a fundamental mistake with the design of the database that confused the quantity of items purchased with the amount of money charged. After I completed the tasks I’d been given, I pointed it out to the interviewer. He was amazed. It turned out that none of the other candidates had got far enough with the task to trip over the error.

After the tests, the interviewer filled me in on the nature of the role. He was a chap of extraordinary charm and tact, who put a fine spin on the problems they had, but it was immediately obvious that the company was in considerable peril from a database that was being operated recklessly and in breach of all financial and procedural guidelines. Could nothing be done? Sorry, our hands are tied. All we can do is to support and maintain what exists. Like the legendary reporter, I made my excuses and left. I’d rather be poor, but sleep at night.

As I stumbled back out into the light of the car-park, I wondered, for the life of me, how the IT industry had got in such a mess that unqualified and untrained people were in responsible positions within organisations all over the country, managing the databases that are the lifeblood of the enterprise. What would happen if the same state of affairs infected Surgery, so that there was a chance of being operated on by someone whose only qualification was that he’d cut open his teddy bear as a child, using his ‘My little Doctor’ kit, but managed to bullshit his way into a job armed with a bogus CV and a string of false references.