31 may 2009

Don’t hire someone just because you like him/her: Bad hire means loosing time and money


After some years of losing a lot of time and money selecting new hires I finally developed a good eye for reading resumes and a few tips to get the hires that last. I no longer interview more than a few people for each position and haven’t been terrible mistaken for a while.

This is how we select personnel today (technical and not technical staff), and why:

1. Publish the request for at least 2 weeks, and get as many resumes as possible:
We don’t use paper, only specialized portals or Universities Alumni organizations. People will apply even if they don’t have the required profile or experience, so you will get many resumes that don’t even apply making you lose time. That is why we prefer Alumni Associations that will filter that for you. Specialized portals give an additional help, they force people to include their resume in a template, so the information you receive is normalized, making it easier to compare candidates.

2. Just by reading resumes, we select a group of no more than 10 people:
Only with what is written you can eliminate most of the bad candidates. You should avoid: people that switch jobs too often, recent graduates that insist they have managerial experience, those who state the obvious with many details(*), lack of confidence or excessive confidence in presentation letters or career goals and those that work as a hobby.

3. We do first interviews and check references of those that seem to have an option (no more than 10):
The main objective here is to see if you could work with this person. Its more like a chemistry thing, and here it will depend on the values of your company. For us, we look for people that will speak their mind, will be creative in problem solving, but are disciplined and not a rebel without a cause. From those I like, I check references by phone… You’ll be surprised, but many people lie in their resumes…

4. If it’s a technical position, we include some technical test or code examples:
Some will be excluded form the selection if their test show no understanding of important concepts, and if code is not 100% complete. We recently started asking candidates to send code a few days after the interview. It helped me see who will go the extra mile for the job, and most important, will keep his/her word in when the work was going to be sent.

5. We select 3 or 4 people per position we need to fill, and then, let someone else choose:

we hire an expert in Human Resources do some character and values tests. Technical knowledge can be taught, but honesty, commitment or discipline can not. As a sub product of this stage, we also get a profile of the candidate, giving us tips on how to get the best of each person, if hired.

Only then, after this 5 step process, we decide who to hire… Its not a infallible system, but has lower our bad hires to almost zero. I am quite confident with it.

(*) This was sent to me by diegus9, and I do agree with it… might help the programmers improve their resume:
http://improvingsoftware.com/2009/04/17/the-programmers-guide-to-getting-hired-your-resume-its-the-little-things-that-hurt/
And these I found also in the same page:
http://improvingsoftware.com/2009/04/10/the-programmers-guide-to-getting-hired-the-code-sample/

11 may 2009

A lame excuse

“The written requirements said the system must held 1500 concurrent users, instead of the 7000 we are getting.”

Monday last week, a new governmental web application was deployed: the RUNT (www.runt.com.co). The application, built by a group of Colombian IT firms headed by Heinsohn, will held information of all transport vehicles in the country. All owners of cars and motorcycles have to register to update information regarding the vehicle and owner. A fine up to two minimum monthly wages (about US$430) will be imposed among those that register late.


Monday noon last week, the system was down. The number of users exceeded the capacity of the system and it took all week for the technical team to catch up. Friday, both the software building firms and the Transport Ministry gave a press conference, to explain what happened. Too many people try to enter at once, and they didn’t expected it.

Lame excuse cause the dynamics of building software has changed (like 20 years ago). Technical staff is responsible for validating requirements given by the client, not just follow them blindly. We, the developers, are responsible for the system having the appropriate functional and non functional requirements, for the client knows his/her business, not how to calculate expected concurrent users.

Analysts should go a mile forward, other wise, how can organizations trust software companies to build exactly what they need?