With the current upturn in the IT industry, recruiting software engineers is a hot business... again! There are numerous posts throughout the Internet talking about companies' strategies and candidates' adventures (good and bad). I have found this post from Reg Braithwaite particularly interesting, both from the story he tells and the links he shares at the bottom of the entry.
Let me explain how we do software engineers recruitment at Agile Partner. Like everybody else, we look for smart people who can solve problems but, because we are a small IT consultancy, we do not do generic recruiting, like Amazon or Google might do. We look for particular profiles (junior, senior, architects) on particular technologies (.NET, Java), then we tune the “smart people who can solve problems” filter for this particular job offer.
As purveyor of software and services for enterprises and governmental agencies, we look for people able to develop enterprise software (I am so scared to use this expression because of one terrifying post from Alex Papadimoulis), which I reckon is the case for the vast majority of the companies similar to us. What does this imply in term of recruiting?
Most of our software engineers daily job will consist in wiring building blocks together in order to create back-office systems that will solve the business problems of our clients.
This job is not exactly formal Computer Science as almost no algorithm knowledge is required (with the exception of proper XSL-T writing, which involves a lot of recursion. I tend to consider a good XSL-T developer as talented developer). Hence high CS grades are not something we do care for very much.
But this job is about curiosity, instinct and quality.
This is why we look for people:
who are eager to learn and able to do it fast in order to find their way out in open source project code bases or application server stack fest,
who know the secret of good middleware development and can conceptualize the intimates of a multi-threaded application,
who have high work ethics and work hard on themselves to stick to these standards.
If we feel that we share this set of core values and other common reference points (like gurus we worship or RSS feeds we read), we will then try to estimate the actual scope of technical knowledge of the candidate, considering that lacks are gaps to fill, not show-stoppers.
We will carefully avoid tricky questions because they show nothing, except a good memory or the reading of an interview preparation guide. We are much more interested by a candidate who knows where to find the information she needs instead of one who can write the code of an algorithm on a white board or rule out if an obscure piece of code can compile (if you can not decide what a piece of code does by reading it, it smells like it is in great need of refactoring).
Then we ensure that the actual coding practices of the candidate match with her assertions. In case the person is a committer on an open source project, this task is greatly simplified: the code review can be done with a simple browser, as most of the code repositories are accessible via HTTP. Else, we will ask the candidate to realize a simple program, with somewhat incomplete specifications (as in real life) and with no time constraints (the exercise being done at home).
All this can sound pretty lax but, believe me, very few go through this process until the end.
Which is ok because, at the end of the day, they will end up with the keys of the company. Something only possible with people you can trust.
