Friday, February 26

Change is Good

This is my last day in this company. I was hired for two projects here, both of which were successes (methinks) and now it's time to depart.

I will have to clear my browser cache, my local files (I kept my CV in My Documents and all that), and I will have to make sure I didn't leave any incriminating papers on my desk (err ... not that I'd have anything to hide - I mean).

Seriously though, as strange as it may sound, I will miss the one hour drive to office every morning (I drove with the window open as I came uphill this morning, to catch the morning's fresh air in the small forest).

I will also miss the too-sweet-not-warm-enough-cappuccino made by the machine down the hall and these guys that I've known for three months, and whose jokes I still don't understand (as they speak French among themselves and they speak too fast for me to understand).

Through all that, I have this feeling of change, of new beginnings.

I still have no idea where I'll be Monday morning, but at this point it doesn't matter.

Change is good.

Wednesday, February 17

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).