I have been recruiting for my company for two years. We had 6 software engineers in 2004 in my department. We now have 45. During the last two years, 2 of the original 6 have left and I have had 3 new hires quit. One of the 45 wasn’t recruited by me. So doing the maths, that’s 43 people that I have hired. Add to that the 10 contractors. 53.

But to hire 53 people, I have interviewed over 100 people. To interview over 100 people, I have seen over 500 candidate submissions. I’m dealing with at least 10 different recruitment agents. Candidates referred by existing staff. Candidates applying via our web site.

And on top of that, I’m managing the development of a major software product. On the support rota. One of the key firefighters on issues that arise. Sorting out office logistics. Buying development servers and software. Recruitment is not my full time role.

I got involved because they needed a technical person involved in the recruitment and ended up running the show. I have it down to a fine art. I can tell with a great degree of accuracy whether or not it’s worth interviewing someone from their initial application. We follow up with a technical test to be sure, then an in-person interview with me and someone else. But I would say at this point, I’d be 75% certain that I could say yes or no from the application and skip the rest.

So what I’m going to set out over the next few weeks is basically going to be how to get me to hire you.

The fundamental problem with all this advice is I can only be sure it applies to me. Every company has it’s own methods of recruitment. My advice might also work with other small to medium software engineering companies that rely on the technical managers to do the recruitment for the technical teams. But it certainly will not map to applying for a major company such as a massive multi-national bank.

So, before I start on anything else, perhaps we ought to look around and see what else is there to help you outside of my field. Because if you aren’t looking for a job in a company like mine, no advice I can give you is going to help. Because it’ll be too specific to working in a company like mine. Hopefully it will be in the right direction, and will help, but there will be some other different stuff.

So where else to go? There are numerous websites around with advice on your application and so on. Google them. There is a lot of information around about how the Google Recruitment process works. A lot of information about the Microsoft process. But, that’s all written from the point of view of giving the applicant generic advice. My advice is to look at it from the other point of view. Find articles about “How to recruit effectively”, written by people who do the recruitment for other recruiters. Find the inside track on how they’re being advised to find people.

When I started recruiting I looked for this kind of advice first and foremost. I started with Joel’s Guerilla Guide to Interviewing. I found this to be essential reading for me. I respect Joel as an expert on software. He’s an engineer leading some great development, and he needs to find more great engineers to provide that development. I’ve taken on some of his core points. I’m looking for Smart People who Get Things Done. I’m ensuring there is at least two people in every interview. If anyone says no, it’s a no.

But I’m not taking it all on board. Some of it doesn’t, and will not, work for my situation. His article on Phone Screening also has good information in it. I don’t phone screen however.

He also has a number of articles on your side of the fence too. I’d start with Getting Your Résumé Read.

Anyway, the point is, figure out what we’re trying to figure out. How do we ensure we find and recruit good engineers. Know your enemy. That’s a starting point.

Popularity: 12% [?]

The intention I set out with was one blog entry a week on my core subject, a real case of developing a new web application from scratch following a very professional approach and documenting it all. Essentially replicating what I do for a living as a hobby project and documenting what’s done en-route to show people what it’s really like to develop an application from scratch, properly, in PHP.

I also thought I’d make the odd post about other technical issues that came up in passing, tools I ran into that were not directly related to what I was doing, and articles I’d read that set me thinking.

Only, in early July work got very hectic. Stress levels up and I was wiped out by the time I got home. My wife thought I was on the computer too much and we had a row about it. So I’ve got no-where since then.

I still intend to carry this on at some point soon. Meanwhile, I’m going to get back into the habit of writing one article a week on development and software engineering as a career.

Right now, at work, I have a team of 45 engineers working for me. I’m recruiting for more. My experience reading CVs and interviewing lots of people has made me realise that people really don’t know how to write a good CV or to handle an interview. My experience running a team of engineers for the last two years has also shown me a lot of stuff about what makes a great programmer and what makes a great team member.

So, I’m going to shift focus and write about that for a while instead. I hope that’s of use and interest to some people.

Popularity: 17% [?]