So, that vast IT disaster you may have caused? Come in, sit down
You won't be forced to dig your own grave
One ex-colleague of mine was fired for putting a screwdriver violently through his system before security took him away, but in reality it’s vanishingly rare that I can say with 100 per cent confidence that you’ve been naughty or nice.
This sometimes very much disappoints a client because they have to make binary decisions, which is tough when the so-called expert writes a three-page report that says in effect: “85 per cent likely it was the sort of blunder any IT pro makes once per career, 10 per cent he is out of his depth, and 5 per cent it happened on purpose”. If you want someone to write 100 per cent on any of those numbers you need someone either much smarter or less honest than me.
Programming is of course the most contentious area, because regardless of what it says in the corporate development standards all major programs contain snippets downloaded from the web, code from previous employers and bits of debug that should have been removed years ago but every time someone tried the system started producing frightening output.
I even occasionally note with grim satisfaction that they have acquired some of my published code. Even with a decent version control system it is hard to say that a given person wrote a particular fragment of code, and you ought to be more surprised than you are how many teams don’t have a good VCS.
That means the interview may have a “why did you write it that way?” section which requires the full limit of my programming experience to follow. Not just obtuse C++ or single letter variable VB but getting through the “yeah, that was a dirty hack, but to get it done on time we called all the other error conditions 'insufficient memory'" quips.
Obviously I can’t talk about my clients, but for various nearly good reasons I got to read the Windows source code and found a lot of those, so don’t for a minute believe that sort of tomfoolery isn’t standard, so that’s what I report. I’m a realist who would actually be suspicious of very clean code.
One thing that non-IT types find hard to grasp is that the scale of the consequences and the cause don’t correlate at all - although RBS management probably gets that idea now.
It’s not my job to say fire or keep you, not because I’m afraid of sticking my neck out (see my other articles), but because very rarely am I given the whole picture, sometimes for good reasons and sometimes not. There’s also a legal issue in that the decision to fire you needs to be taken by your employer as part of a proper process. It is not in their interests to say they delegated it to an outsider.
If you find yourself sitting next to me... you need to stop digging. There is already a hole and lying will just cause my smile to become a little more fixed as I hand you the spade.
Answer the questions, feel free to explain things you think I haven’t understood or been told, but be aware that the more times I have to ask a question the less likely I am to believe the answer. I’m paid for my time and thus quite happy to do a Paxman on you. Possibly the most valuable thing you will get from this is knowing that if you are in the UK or EU and this stuff gets used against you then you have a right to a copy of my report. Advice that I hope you will find is completely useless to you. ®
Dominic Connor used to boss around gangs of quants, developers and sysadmins before moving to a life of headhunting in the City spiced up with consultancy.
Sponsored: Customer Identity and Access Management