What length of Resume will get you in the door

orron — Sat, 09 Oct 2004 08:16:00 GMT

I am a big fan of Heather's "Marketing at Microsoft" Blog. She has an interesting view on recruiting issues, and also seems to care a whole lot about the people behind the resumes. It's refreshing to see someone who deals with so many applications still being able to see the person, and not just a document. Her post on Why the one page resume doesn't work anymore may be an eye-opener for people applying for a new job.

My point of view is somewhat different- but I am not a recruiter. My job was to make the final decision about candidates, for both technical and managerial positions.

I can't rememebr how many people I have interviewed over the past 5 years. It's all a blur... I had days with 5-10 interviews, and some quiet periods with only 2 or 3 a day. That's a lot of people to talk to, and plenty of resumes to see. I can tell you one thing- I have a great deal of appreciation for Heather's ability to still be intersted in the story "behind the scenes".

I like to have a conversation face-to-face with a candidate or applicant. The resume is a place to start, but I can't rely on the candidates' writing skills to get a good view of their abilities- especially when all technical resumes look exactly the same, with the same buzzwords and the same structure.

That's why I feel that a short resume is better- it only needs to get you through the door, for an interview with the right person.

I also think that the best way in, is to have someone you know deliver the resume to "the right person". Your chances of getting an interview that way are higher- and you will probably meet a more sympathetic interviewer.

The Monthly Twilight Zone- How the IT Guy Beat Me To It

orron — Wed, 06 Oct 2004 02:00:00 GMT

This is a new section I intend to write each month- to shine a light on some of the more peculiar events I encounter. This month it's the story of "The Contract, The Customer and Windows Server 2003"

Part of my job is to solve problems on very-large-scale projects around the world. Usually I get called before a milestone is due, and there is some technical problem that if not solved immediately, will prevent the project management from collecting payment for the work done so far. Of course, everyone on the project team had a go at it, and their friends and relatives have also already had a go at it. At this point, there's no time left and everyone is ready to pay and do whatever it takes to solve the problem.

In this case, it was a project which relies heavily on web-services. The project management signed a contract that did not specify which operating systems the product will be deployed to. The system was designed to work on Windows server 2000. Now the games began…

The customer, after carefully examining the contract and the glaring loophole, decided to demand that the system be deployed to Windows Server 2003. The system was not developed for windows server 2003, was not tested on windows server 2003 and, surprisingly, refused to work on windows server 2003.

On Wednesday, with the milestone due for Monday, I began working on the problem.

After several hours, I narrowed it down to a problem with the way the web-services behaved, or rather misbehaved. Data was not streaming properly to the presentation layer, and that resulted in frequent termination of the user's session. In short- the user was logged on for about 10 seconds, and then kicked out.

A day later I was not getting closer to a solution. As the hours ticked away, things were getting a bit tense. Nothing I tried worked- changing the confing files, changing settings in IIS, changing the actual code for the web-services.

During a coffee break, with my reputation as a problem solver at stake already, an IT guy from another project called. During that five minute conversation, he heard about the problem and suggested we change a setting in IIS which makes Windows Server 2003 support Windows 2000 services. We did. It worked, without any other changes to the code or configuration. There was drinking and dancing and joyful shouting for most of the evening later on.

This story has all the elements of a predictable failure:

A contract that doesn't limit the customer's options and a system that was not tested correctly before it was deployed. It also has a happy ending- but only due to unseen powers, residing in the IT department, where people can effortlessly solve problems that leave developers bewildered.

Do you have any stories that belong in the Twilight Zone?

Or Ron's Weblog

What length of Resume will get you in the door

The Monthly Twilight Zone- How the IT Guy Beat Me To It