Strategies for recruiting top notch developers in a flooded job market

Hiring experienced and competent developers in India is a very, very difficult job. Not because developers are hard to come by - but because there are just so many of them that filtering out the wheat from the chaff is a herculean task.

This post includes an explanation of why this problem exists, forces in the environment which exacerbate the situation and a description of how ThoughtWorks' recruitment practices attempt to solve at least some portions of the problem.

Understanding the root of the problem
Let's start at the beginning. Why is the Indian job market currently flooded with developers? The answer to this question is fairly simple - lack of opportunity.

For nearly fifty years after independence, the only opportunity for a kid from a middle-class family in India to make it big involved studying engineering or medicine and then moving to America. Interest or inclination had little to do with career choices - one had to be pragmatic in order to be able to support oneself. While this situation has improved over the last decade or so, engineering and medicine are still the only courses which guarantee some form of employment.

Sometime during the mid-nineties, a new field of engineering surfaced in mainstream Indian colleges - computers. Here was an engineering discipline which didn't need lakhs of rupees in investment to create lab infrastructure. Buy a dozen desktops and hire a few teachers and you're ready to roll. Soon, newer colleges which only offered courses in computers started appearing. These 'IT' colleges as they were called were a great success, with as many as a dozen new ones opening every year.

Then came the outsourced services boom and suddenly there was a huge market for these skills, with far less competition than was needed to go abroad. You no longer needed to crack the incredibly difficult IIT-JEE entrance exam (probably one of the most difficult in the world for a bachelor's degree) and make it into the IITs to achieve a good standard of living - an IT job guaranteed a salary far above what was normal at the time for fresh graduates and a standard of living to match. Of course, the cream still went abroad - the advantages of more than a hundred television channels, social security and spray paint in cans (something unheard of in India even today) were undeniable.

That trend has continued to grow to the point where today, roughly 10,000 students graduate every year with some degree in computers. A very small percentage of them actually enjoy writing code and learning new stuff in the field - both very necessary prerequisites for a successful programmer. This has resulted in a dramatic drop in the overall quality of talent available at the entry level. Some companies have simply stopped looking for knowledge of computers and now hire anyone with a BE in any field. The logic behind this decision is that the knowledge of computers one can expect from someone with a BE in, say, chemical engineering is much the same as someone with a BE in computers. The company doing the hiring looks for a base level of aptitude (indicated by the fact that the candidate has earned a BE) and proposes to train them themselves. The degree to which this affects the job market is clearly visible in the number of applications the bigger services firms receive. According to this article in the Economist, Infosys alone receives approximately 1.3 million applications every year, most of them unsuitable.

One must also keep in mind that this is equally hard on the all the people forced into software because (unlike in the first world) one does not get employment simply because one is educated in a certain area. I have several friends who graduated as engineers in various disciplines who have been forced into software jobs simply because there was no other alternative. If this is the case with engineers, it is easy to imagine what the situation is in fine arts, nursing or any other field where demand is driven from within the country rather than from without. But that rant is worthy of an entire post and I'll get around to it some other time.

One complicating factor is that demand from the software industry has also grown proportionately. The leading services firms like Wipro and Infosys routinely hire 20,000 people every year. A simple Google search for the keywords Infosys and hires brings a wealth of information to light. This makes for a very competitive market, where demand actually outstrips by a substantial margin.

Another is the way in which the career of a developer progresses in the majority of Indian firms. It is taken for granted that everyone eventually wants to become a manager, since that's where the money is. Whether he likes it or not, but his second or third year a developer is a team lead and by his seventh a project manager. Each step up the ladder means less hands-on coding - which most don't really miss anyway. The leveraged model followed in these firms result in developers being treated very poorly, with all the benefits accruing to managers. At the time of writing, the average developer with two years of experience could expect to earn approximately four lakh rupees a year before tax while his project manager took home that same amount simply in bonuses, with his entire package amounting to five times that. Finding a developer with ten years of experience is practically impossible. All you'll find are people with ten years experience who are managers and who used to be developers five years ago.

ThoughtWorks' recruitment process
There are two basic principles

1. Leave assessing the capabilities of developers to other developers
2. Don't hire developers without seeing their code
   

I'll get to these in a bit; we first need to do some filtering. Unfortunately, I have no earth shaking revelations here. The process is quite simple.

1. Recruitment receives a CV
2. They give it a once over to check that there is alignment in technologies (at the moment, this would include Java, C#, Ruby and Python)
3. They look at the project work the candidate has been involved in. This is especially important for fresh graduates as little importance is attached to pure academic performance. The question is: Is the candidate interested in coding?
4. They call the candidate in and administer a written test consisting of a dozen logic based questions - hardly rocket science.

Once the candidate clears this, we move onto the next level - writing code. Like Joel Spolsky says so succinctly in point 11 of 'The Joel Test', 'Would you hire a magician without asking them to show you some magic tricks? Of course not.' I personally feel it's pretty unrealistic to hire a developer without having him write code. Indeed, we feel so strongly about this that we get them to write code not once, but twice. The reason we actually have that logic test I mentioned is simply to ensure that ThoughtWorks' developers don't get flooded with too many code reviews and interviews. It isn't the best way to filter by any means, but it'll have to do until we come up with a better way.

So once a candidate clears the logic test, we send him a coding problem and ask him to solve it in (at the time of writing) either Java or C#. If the candidate prefers to do, say, C++, Ruby or Python, that too is acceptable. Once the candidate solves the problem, he emails it to us and it is assigned to a developer for review.

The objective of the review is to see if the style of writing code is up to the standard that we expect on our projects. This standard would of course vary from organization to organization depending on the kind of work they do - a company which specialises in kernel code in C may be completely indifferent to the candidate's Object Oriented Programming skills. In our case, the focus is very much on OO - for example, we occasionally receive code badged as C++ but which don't have a single class and is purely procedural. Such a submission would not be accepted because it doesn't make sense given the kind of work we do. The reviewer does base his expectations upon the number of years of work experience - you can't realistically expect a college grad to write unit tests, say. If they do, that's awesome, but if they don't - no big deal.

Once the candidate's code clears the code review, we enter the final stage of the process. The candidate is asked to come into one of our offices for a round of 'pairing' on his code. Here, he works with a ThoughtWorks developer to modify his code submission to handle the same problem but with more complex requirements. There are several takeaways. First, people who fudged on the code submission will never make it through this round. Second, the ThoughtWorker doing the pairing can fairly accurately assess the level of competence of the candidate, his openness to new ideas and his general exposure to programming concepts in general.

The pairing is followed by two rounds of interviews, with a couple of ThoughtWorks developers on the panel in each. I'm not going to go into the style of interviewing in detail - personally, besides technical competence, I look for two things:

1. Does the candidate have opinions on technical subjects?
   
2. Is writing code one of the top three things the candidate does in his or her spare time

Here I don't look for a 'right' opinion or a 'wrong' opinion; it's just a way of assessing the candidate's interest in technology in general (and I make it very clear to the candidate that contradicting the interviewer's opinion is not at all a bad thing :-)). Any opinion is a good thing and I make sure that the topics covered by the question are not something with very clear-cut positives or negatives. The ambiguity makes for good conversation.

These three rounds are followed by all the ThoughtWorks developers involved getting together for a chat and figuring out whether the candidate should be hired. If there is any area where there are still unanswered questions, the candidate may have to face a third panel. The final consensus of these developers is what decides if the candidate is hired or not.

Summary
The Indian job market is flooded with developers. Identifying good developers isn't easy and at a bare minimum, candidates must be asked to demonstrate their competence by writing code and must also clearly prove their inclination toward coding for fun.