Dealing with Growing Pains

Just recently I've been heavily involved in recruiting two new developers. Although I've helped out in the past with technical interviews, this is the first time I've actually been involved the whole way through the recruitment process. And it is remarkable just how much work it is.

First of all you have to realise you need someone. This could be blindingly obvious, for example if someone has just left and needs replacing, but sometimes is more tricky with many factors involved. Perhaps a new contract has been awarded leading to an upcoming block of work, using a new technology needs someone with relevant experience, or organic growth has allowed a bigger headcount to tackle that backlog of features. In turn, the reasons why you need someone often influences the next two factors - what skills require, and when do you need them by. This can be quite complex, especially when you realise quite how disruptive taking on a new developer and integrating them into a team can actually be. In fact whole books and many Patterns have been written on how to cope, for example Sacrificial Lamb, where you dedicate a team member to get the new people up to speed so that in the short term you only lose their productivity and the rest of the team can continue to develop without being distracted. So you need to balance getting the right skills in the right order with the disruption that can cause. Sometimes the answer can be quite simple, but often you're looking for such a range of skills that it is impossible for a single person to have them all, and so you end up juggling possible subsets to find more realistic roles, eg C++ and unix scripting; html, css and javascript. Depending on upcoming work, there may be obvious roles and a natural order so it that makes sense hiring one at a time to avoid taking a big hit.

Now we know what sort of things we need, we can write a job specification. These usually involve what level of experience in essential skills, and desirable or optional skills, and an idea of what sort of remuneration would be appropriate. You do have to be careful here as employment law changed a few years ago, and some common practices are now illegal, eg asking for a number of years of experience. Your HR department will be involved at this stage, but make sure you get a final check on the wording - I've heard stories of the skills part being edited so that they made no technical sense at all, which is hardly going to encourage people to want to work for you! This last point is too often overlooked - a large part of the recruitment process is selling the company and the role to the candidate. So make sure there are no spelling mistakes.

Next we have to get that job spec out to get applications. But where? Depending on the job, different avenues can be excellent or a waste of time. So for example, I'd probably not bother with Job Centres for a C++ job, and perhaps not even the local papers even in a hi-tech area such as Cambridge. The reasons are that you're potentially looking further afield and for someone who is probably already in a job. A good agency can be an excellent route, but the problem here is that sadly many are not very good at all. But if they do their job properly and learn what you're really looking for and care about, and what their candidates are really interested in, then they do a fantastic job of matching up very suitable people and jobs. There is one particular agency I know that always stood out as the CVs they sent were always worth reading through, in stark contrast to other agencies where they always sending completely unsuitable CVs - eg just last week I got sent a CV for a RF Engineer CV. We're a web services company - that's a no then. Job web pages seem pretty mixed - some seem to work, but some are just too big and unfocused. In my area we have a good 'networking' site and jobs email that has been very useful over the years. And of course, targeted mailing lists such as accu-contacts are good at getting to a lot of very good people (although they therefore tend to be well looked after and settled in their current job...)

Now we get the CVs flooding in. Sadly they will be of variable quality, and you need to filter them so you don't waste too much time. Some will be badly written and full of typos which could be taken as an indicator of sloppiness - it is their most important document after all, and everyone should get someone to proof read it or at least run a spell checker over it. In this age of the internet and international mobility, you can often get CVs from many parts of the world. Interestingly different cultures seem to have different approaches to CV writing - some seem to list every tiny detail of the technologies they've used (or just heard about!), others are remarkably terse and shy away from 'selling' themselves. Whatever the style, what you're actually trying to do is get an idea of the person behind the CV, what their abilities actually are and can they do the job and contribute to the team. This is a non-trivial exercise, and at this stage you should really be just be cutting down the numbers of applicants to a manageable amount.

From here on, it is very important to do several things. One is to try very hard to be fair to each applicant so they have an opportunity to be seen in their best possible light. This includes things such as having interview 'scripts' so we ask roughly similar questions, have multiple people involved at each stage, and have the same people involved for each of the candidates. This tries hard to achieve consistency between candidates. It is also important to keep notes, partly so that you can remember what people said, as when you're doing five interviews, it easy to lose track of who said what. It's also important as it leaves a paper trail of what happened so your decisions can be justified.

At this stage there are many different techniques for finding out more about the applicants. We sometimes send them a quick programming question or two for them to answer. The idea is that it should be nothing very onerous, and is more about finding out their attitude and understanding rather than syntax details. An example we've used is a simple string class with poor resource handling, and get them to comment on it. This is mostly useful for weeding out those people who aren't really serious about their applications - the sort who use a scatter-gun approach to sending out CVs.

Then we have a quick 10-15 minute telephone chat. This shouldn't go into much detail, but allows us to explain what the company does, what sort of thing we're looking for and find out a bit more about the person, perhaps by getting them to talk about something on their CV. This last can really show whether they truly understand what they've done, and can communicate it to someone else (after all, I say that a large part of software development is communication, whether it's finding out requirements, writing a good bug report, or expressing a design in code). At the end of this you know whether the applicant is still interested in the role and whether it's worth going ahead.

At this point we sometimes set a quick home programming task (or get them in if they haven't the facilities at home). This should be self-contained, take no more than a few hours, and yet be complex enough that they have to make some interesting design decisions and use various language and library facilities. This is remarkably hard to set well, so make sure you get feedback from them about it, and try it yourself. When you get the results, get several people to go over them to make comments on the coding style, bugs, alternative approaches etc. This can very very revealing about the person's background and programming habits, for example whether they learnt C++ in the 90s before techniques such as RAII and exception-safety were widely understood. Unless the code is really bad, we then get them in for a face-to-face interview.

This usually lasts a couple of hours - more then that and people tend to get too tired (including the interviewer - it is quite hard work listening carefully and taking notes), so if you want to do more, a second interview may be the best option. In this we have various parts, with a general chat with someone from HR, a development manager to talk about methodologies, some technical discussions, and a session discussing their programming test to find out the 'why' of their decisions, what their attitudes are, and what sort of things they thought about but rejected. It's very important here to not treat this as an opportunity to catch the candidate out, or to show off your own technical knowledge - you're here to find out about them.

Once that's done, it's a good idea to have a quick meeting immediately with the people who have been involved in the interviewing. Collect people's opinions, and see if there's a consensus. It's usual pretty obvious if it's a Yes or a No, but sometimes there will be a split. If there's even a single strong No vote then that is probably a good reason to reject - a bad hire can be extremely costly, so better to reject the occasional good candidate. But if it's more nuanced, then perhaps a further interview may clarify - a good question to ask is what else people would like to find out and what questions would help. If people can't answer that, it can show that there may not be any point going further.

Finally, after HR has negotiated on salary and an offer been made and accepted, you must then make sure that there's the right equipment and a place to sit. I strongly recommend having a rethink of everyone's locations at this stage, to make sure they will be near the people that they will talk to most, and can help them get up to speed. Again, this is an issue of arranging your team so that you foster the desired communications channels, as per Conway's Law [ Conway ]. And make sure you've decided on a suitable project to help them find their feet and become productive as soon as possible, ideally something small enough that they don't have to understand too much too soon.

This whole procedure takes up a lot of effort. I'd estimate to fill each post it took about a third of my time over a three week period, and a couple of days input each from the rest of the development team (and we're a small company where we can make decisions pretty quickly as we don't need to get input from lots of people.) But because of that effort we now have two good new team members working productively - well worth it in my eyes.

The C++0x Standard draft

In a major piece of news, the final committee draft for the upcoming C++0x has been accepted. This has taken longer than originally hoped, and has only been achieved by taking out some controversial features and a lot of effort. What remains now is a few months of review and minor fixes, voting by national bodies, and the final text should be voted on next March. It will be interesting to see how fast compilers start to implement the new features. For full details, see Herb Sutter's blog and the links from there [ Sutter ].

References

[Conway] http://www.melconway.com/law/index.html

[Sutter] http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/