Agile India.

1. Agile (as practiced today) is the new Waterfall
2. Naked Agile
3. Biggest Stinkers
4. Goodbye Simplicity; I’m Object Obsessed
5. Want to Pair Program and Concerned about Productivity?
6. Estimation Considered Harmful
7. Refactoring Legacy Projects: Scaffolding Technique
8. Single Responsibility Principle Demystified
9. Primitive Obsession
10. Cannot Evaluate a Candidate just based on their Resume

Its been 7 years since I’ve been actively involved in recruiting software professionals for various companies. In most places I’ve defined or helped refactor the existing recruitment process to increase our throughput without compromising on the quality.

In this post I plan to explain the second step in the recruitment process. The first and the most important step in recruitment of course is sourcing. Sourcing the right candidates is no doubt the most important thing when it comes to making your recruitment process efficient.

A good number of resumes do come in directly (company job portal, conferences, user groups, other community initiatives and so on) or through a consultant. At Directi we have a Puzzles and Case Studies section on our website and look favorably towards candidates who solve the puzzles or complete their case studies and send their solutions with their resumes. Once we get a resume, we need to make a Go or No Go decision.

We evaluate the submission first. Of course we also need to go through the resume and check the quality of projects the candidate has worked on, see if she has relevant experience, decent exposure to technology & methodology and good communication skills. Unfortunately in today’s competitive environment this is not sufficient. Following is a laundry list of steps I follow to make an informed decision:

• Google for the person’s name, see if her blog/website shows up. Its a delight to see if Google suggest shows the name. See what others have to say about the candidate through their blogs, discussions, etc. See if the candidate has any other web presence.
• Is the candidate active in the community (Local and online)? Did the candidate present at user groups and conferences?
• Does the candidate have published articles, experience reports or books?
• Has the candidate authored any products (open source or otherwise)? If yes, is it usable, what is its acceptance, what problem is it really trying to solve, compare it to competing products, etc.
• If the candidate has a blog, check what she writing on her blog. Based on her blog we can gauge her interests, her depth and breath of knowledge, communication skills, exposure, etc. Lot more informative than a resume can provide.
• I’m particularly interested to see if the candidate has solved any issues with tools, frameworks, etc and explained it well to others on her blog or mailing list or any article.
• Social Networking sites are a good source of information. For ex: if the candidate has her profile on LinkedIn, we check if she has any recommendations. LinkedIn gives you a graph of how you are connected to the candidate. This also gives some understanding of who in your connection knows the candidate.
• And so on…

Typically this gives me enough information to make an informed call about the candidate. Now we can move to the next step of our recruitment process. (Typically an intro email requesting 30 mins casual conversation.)

While hiring, personally I look for the candidate’s quality of experience. Quantity (Number of years of experience) does not really matter.

As Conan rightly pointed out:

Watch out for people with “10 years” of experience … it’s sometimes 1 year of experience, repeated 10 times

In fact I would go to the extent of saying that their educational background also does not matter. (Sometimes it actually negatively impacts their impression. Someone with a CS background should at least know theoretically about different computer architectures)

The only time I look at number of years of experience is, when someone claims that they have been doing ‘x’ for ‘y’ years. And during discussions about ‘x’ related topics, its apparent that the person does not have the expected depth on the topic. Then I ask myself, “if this person does not have the required depth after spending ‘y’ years, how good is this person at picking up stuff and internalizing it?”

Of course, we need to give them the benefit of doubt. They might be working in a highly viscous environment.