The Dark Side ... of Your Resumé

If you were to look at my resumé, youd' see a lot of wonderful things:

It says I have ten years of experience in IT and five years working with C++.

It sais I have a very varied experience, having worked with performance-critical apps, multi-server systems, cryptography, security protocol design and some others.

It's designed to make you feel you know what I'm talking about, after you have read it.

Here's what my resumé won't say:
I also have experience with having to maintain inefficient crap that should have never seen the light of day.

I've maintained over-engineered code, redundant and dead code and generally things that should have been rejected, before seeing the light of source control. To be fair, I've also written that kind of code, mainly in my first two-three years as a software developer.

I have seen obvious mistakes being made in early design that were taken all the way to implementation and maintenance because (probably) someone didn't want to admit their mistakes.

I've seen code that was so ugly that it survived only because those who saw it's ugliness for ugliness were not mad enough to touch it, and the others who were not savvy enough to recognize the ugliness just didn't bother.

I have been asked to stay over the weekend to fix my mistakes, or (in the last years) someone else's mistakes in design (as I tend to learn a bit from mine - as slowly as I sometimes do).

My resumé doesn't say all that, and it will not, because the software engineers who understand that aspect of the job, do not participate much in the hiring process.

Instead you have to impress the others: the ones not savvy enough to understand - either the managers, or the people we tend to talk about over a beer ("I have this guy at work who ...").

Very seldom will you see the hiring decisions being touched by the people that will be actually affected by those decisions, the people that you will be directly working with.

In the last company I worked with, I was interviewed by my would-be manager - the technical guy I was to be dirrectly under, once I passed the interview.

I was lucky that way.

Most of the times, in order to get hired, you need to put on a suit (that you will not wear past the interview) and your best business face, then speak to somebody that evaluates your skills based on your own description and the amount of achronyms on your CV (my CV says I've done OOA/D and maintained a HP/HA server system with a MTBF of a year or so).

In a typical interview you will probably speak to somebody that is interested in the business side only, or that has (at best) seen some code a few years ago. The only apport technical people have in these jobs is (maybe) to advise the management on a test they should give to potential candidates.

In the cases where you have a technical interview it is usually the second (that is, if you pass the non-technical one).

Sadly most companies dismiss the best developers at the interview stage (because if they were able to speak business they'd be business people, not developers).