I went for a job interview recently. Not that I was particularly looking to move from contracting back into full-time work, but I came upon the role completely by accident and thought: "Wow, that's right up my street, I'll have a bash".

The employer was very similar to one I used to be involved with, and the role was to look after infrastructure, systems and support, managing a team of a dozen assorted techies.

The head of IT's previous role, it appears, was a senior IT post in an NHS trust. I'll try my hardest not to involve stereotypes, but two things he said were: "I'm not very technical" and "PRINCE2".

Now, bear in mind that I'd had a telephone interview last week with this chap. During this chat, he asked me (among many other things) what I knew about best practice, and whether I was familiar with terms such as PRINCE2 or ITIL (which weren't, by the way, mentioned in the job spec). I told him, perfectly honestly, that I didn't have any PRINCE2 or ITIL certifications, and that for the projects I've worked on and/or managed, common sense has been sufficient, and when I've documented stuff I've done so in a language that any reader has a chance of understanding.

Anyway, the first 15 minutes were spent with him asking intriguing questions. A typical one was: "What's involved in the concept of system management?". Sadly, the stuff I know about system management (obviously, having been doing it for 17 years I'm merely a beginner) didn't seem to match what he wanted me to say. Then I started to realise that actually it did, except he wanted me to say the specific words he had on his screen, not the words I use in real life. I lost count of the number of times he said: "Ah, so the term you're actually looking for is X?". No, the term YOU'RE looking for is X; I just said the same thing, but people would understand my version.

Then we got into the tricky ones, which is where everything went pear-shaped. "What do you think is meant by continuous improvement?" came the question. "Isn't that evident from the name?" I inquired. "Well, what do you think it means?". I was caught completely off-guard by this person who seemed to be trying to tell me that continuous improvement involves something other than an ongoing ("continuous") regime of always trying to find better ways to do stuff ("improvement"). Apparently, to "improve", you need to know that something you're doing could be done better, and so you need to measure and evaluate performance and then prioritise areas of improvement based on their relative merits and costs. No shit, Sherlock.

Then there was the argument about the quantitative measurement of system performance - or, more accurately, the fact that I didn't seem to think it was important. Daylight dawned eventually, and I realised that the way I was talking made him think that I would measure application response time in terms of "Oh, that seems a bit slow" - put simply, I'd assumed it was bleedin' obvious that you can't specify and monitor a service level without using real measurements - that "Too slow" meant the response time went outside defined criteria. Perhaps he thought that I thought "fullish" was an acceptable measure of disk space, or "a bit tardy" a good way of evaluating your network round trip time. Or that I interrogated my system stats with SQL queries like: "SELECT COUNT(*) FROM event WHERE response_time >= NOT VERY SPEEDY".

Then the discussion of how to motivate techies. We disagreed a bit, because he was adamant that they need goals, whereas I reckon your average techie needs more than that, in the shape of the occasional visible result. It's one thing being able to say: "OK, that GIS library I've written is now complete and fully tested" - that's a goal in his language. What really makes a techie happy, though, is when (say) the spanking new Web site that uses that GIS library actually goes live. If a techie can say to his girlfriend (and yes, some of them do have girlfriends): "See? John and I did that bit there - isn't it neat?", he's a happier man.

On the subject of "How would you communicate with your team?", I was again thrown slightly. Generally I like to just talk to people, and to write stuff down (either electronically or on dead trees) if it needs to be permanently recorded or made available for reference. The interviewer didn't look too impressed - perhaps he was wanting me to talk about telepathy or carrier pigeons.

Then there was the "definitions" game. "What's the difference between a project and a task?". Turned out he wanted the difference according to the PRINCE2 definitions (a vain hope, given what I've told you I told him right from the start). Turns out that a project has a start date and and end date, but a task doesn't - though I'm going to go and get the book and check this, since a task without at least an end date is, one would imagine, a task that doesn't need to be done.

But I think I know where it all went wrong. It was when he came out with a phrase that brought a chill to my heart. Before you read the next line, sit down and get the Valium out of the desk drawer.

"Let's play buzzword bingo".

Yes, an interviewer really did say that to me. And yes, it took a few moments to realise that I was really was hearing what I thought I was hearing. The idea was that he would tell me a subject, and I had to think of as many buzzwords as I could relating to that subject. I'm somewhat ashamed to say that I did pretty well - I only missed one - but in my defence I would insist that my buzzword knowledge has arisen due to me being a cynical bastard who hates the things but comes across them all the time, rather than someone who's proud to know them.

Believe me, dear reader: the one thing to really put the kybosh on a job interview is being seen to lose the will to live.

Perhaps they decided they wouldn't bother with the rest of the interview once I'd proved that I didn't know about the things I'd told them I didn't know, and which weren't asked for in the job spec. Whatever the case, it's perhaps worth mentioning that at no point did anyone ask me about any of my technical abilities. Perhaps they believed everything I said on my CV. Or perhaps technical knowledge isn't really required for the guy who is to be in charge of the entire technical infrastructure and support effort of the company.

No surprises, they turned me down.

If you're thinking this blog rant is just sour grapes, you're partly right - but only partly. It can't be denied that I didn't put on a particularly good performance, since I simply didn't go in expecting to be asked questions about something I'd told them I didn't know about (and which wasn't in the spec). And I'll admit that I could have researched the company a bit better and been a bit more conversant about its publications. And it certainly can't have helped that I went in with the attitude of "I don't need this job, as I've already got a nice-car-and-several-holidays-a-year consulting income, but it does sound tremendously interesting".

What gets me is this, though. I used to work for a company about this size, in a similar industry. The IT department, which had about the right staff levels, made up about 6% of the workforce, including the in-house people and external resources they could call on. Contrast it with this company, which has a head of IT with three senior managers under him; one of these has a team of 12 support people, and the other two presumably have teams working under them. So if you estimate (conservatively, I think) that there are half a dozen people in each of these other teams, that makes the IT department some 25% of the workforce! And no, I don't believe they have vast amounts of really clever systems for them all to build and look after (their Web site doesn't even render properly in IE7 - something I'd like to have noticed before the interview!).

I've been told by a seemingly reliable source that they have a lack of processes and controls. I suspect this is why they've taken on a new head of IT who has a penchant for formal process control and documentation standards. That's actually not a bad thing, and if he's good at it, good luck to him (let's face it, it must be better than his previous life in NHS IT). Trouble is, though, from where I'm sitting, their problem isn't that they have a lack of process; that's just the symptom. The problem, I reckon, is that they have a surplus of people. So they're putting in a whole new layer of management to manage these people. They're emphasising the people- and project-management aspects of this layer of management, and from my experience they're not really concerned about the technical knowledge of these people. Thus, they're going to end up with a bunch of managers writing incomprehensible processes that mean nothing to normal mortals in the building, and supervising people whose jobs they don't understand - thus rendering them unable to know that the job that just took Bill five days was actually a half-hour task.

I hope it doesn't all end in tears. But what I think I see is the process of: (1) Discover a one-off need for a lot of staff to deal with a big job; (2) Take on loads of staff; (3) Realise you've got all these staff that are employed rather chaotically under a single IT head; (5) Take on an additional layer of management to ease the supervisory/admin load; (6) Add still more staff to deal with the extra load of staff management and process definition/implementation; (7) Go back to (5), and repeat.

I was hoping that (5) would be "Take on a heavy techie manager to get rid of all the bullshit and kick the team into shape, booting where necessary", thus alleviating the need for (6) and (7). Cos that's what I'm good at. Sadly it wasn't to be.