I had an interesting conversation with a recruiter recently about the difficulty of the ThoughtWorks recruitment process. It’s true that the majority of applicants don’t make it through, but then that it is true of most recruitment processes. The ThoughtWorks one is perhaps more drawn out and longer so you feel that more effort was invested if you don’t go through.
One thing that is quite interesting is that being really smart is not the only criteria if you want to work at ThoughtWorks. Candidates who fail the process often go on to join other very prestigious companies. Why did you turn down this person who went to this other company?
In most cases the answer is that the company they ended up joining was not a consultancy. Consultancy is, unfortunately perhaps, not just about raw smarts and programming ability. Unlike a lot of companies ThoughtWorks doesn’t really have a codebase, the job is mostly about working with and helping people improve their own codebases.
Coaching, persuading and analysing code is quite different from writing good code. My favourite example of this is a code submission that solved all three of our problems in probably one of the shortest sets of solutions I’ve seen. The candidate correctly identified each underlying abstraction and applied the standard solutions in a concise powerful way.
An automatic hire then? No, sadly not, because while the candidate had the time to solve all three problems they didn’t bother to write a single test. If you look at what they did they really just proved their own superiority and left nothing that helped explain, maintain or develop their code base. You could already see that this person wanted to be the hero of the piece, not the collaborator.
In the three years I’ve been at ThoughtWorks there have been several times when I could have produced a much better solution to problems than what was actually created in collaboration with my clients. I would like to think that instead of the best solution we were able to produce something that our client teams understood better than what they had previously, was more productive that what they had previously and was more reliable that what they had previously.
All these things are more valuable than an individual being a better coder than their peers.