Recruitment – How we screen candidates

As with a lot of companies that use ColdFusion, we sometimes have to recruit programmers that have no ColdFusion background and train them on to the product once they get here. More and more we are tending to look for higher quality candidates than before, and as that bar has been raised we’ve changed our recruitment process to look for candidates with particular attributes.

I was asked recently to describe how we actually recruit our programmers. I was asked if there was a documented process (no!) so I jotted down the process we use. I thought I’d share that here. It’s no secret, and a lot of stuff we gleaned from Joel Spolsky’s Guerilla Guide to Interviewing with changes to reflect how we do things, and the tools we use. By the way that article is over ten years old now! Most of it is still very relevant. It’s a great read too.

So this is how I’d advise someone else to hire a programmer:

  1. Conduct telephone interviews first with their CV on front of you – you don’t have to drag someone into the office to get an idea of their experience and it gives you a chance to get through a lot of CVs in as small amount of time as possible.
  2. Once you have a short list of candidates from the telephone interviews – send them a technical test first. We’ve found this test to be a great indicator of ability. We ask the candidate to do the test in their own time over the few days. We explain we are looking for quality rather than speed. We generally ask candidates to:
    1. Talk about our site – the technologies they can see used by viewing the source and looking for tell-tail signs using Firebug etc. This allows good candidates to show their knowledge of HTML / CSS and associated good practice (use of JavaScript libraries, seperation of markup and style etc.) as well as performance tricks (e.g. CSS & JS minification, low number of HTTP requests etc.) that we use on the front end. Poor candidates will simply say they can’t tell anything without seeing the (server-side) source code.
    2. Talk about their past and current development environment – this gives good candidates an opportunity to talk about things they should care about. Good candicates will care about version control, and which type. They can talk about proper project management and communication, their favourite IDE and why etc. Poorer candicates will have little to say in this area, but you are looking for good candiates who care about what they do.
    3. We give the candidate a set of SQL table definitions and ask them to do a moderately difficult query. We ask them to use whatever database they wish. This is good one to discuss with them if you call them in for a face-to-face. You can then ask them about what SQL optimisations can be made if the tables get larger etc.
    4. We ask the candidate to write a small program, in ColdFusion (in our case) that indentifies if a given word is a palindrome. There is plenty you can take away from this. For a start, if they are not from a CF background then they’ll need to do a little research, download the server and try it out. They’ll write it as a web page and this can give you a great idea of how the programmer thinks and organises their code. Neatness is important. Sensible comments are also important. There are half a dozen ways to solve this problem so the really good candidates might show that. You can then discuss the different approaches at the face-to-face.
    5. Since we use a lot of JavaScript on our site and we like our candidates to be all-rounders (client and server-side) we also ask the candidate to write a JavaScript program that allows them to demonstrate what they know about the language. Again there are half a dozen way to answer the question but we’ll be looking to see if they can use some of the more sophisticated features (arguments scope and proper JS objects for example) in their answer.
  3. Once we have their test we’ll decide based on that whether to ask them in for an interview. In the interview we’ll discuss their CV again, and really get the feel for the person. We’ll also go through their answers with them. This can be interesting as it allows them to demonstrate they can take constructive criticism. We do code reviews and it helps to be able to talk over your mistakes with others. It also gives them a chance to explain the reasoning behind why they did something thus showing they are a good communicator.
  4. At this point I guarantee you’ll have a very good idea if you want to hire this person and if you do, you’ll be doing so knowing a lot about this candidate as a person and as a programmer.

I hope this helps someone out – we’ll continue to learn from our process, and you should too. Best of luck!

Advertisements
This entry was posted in Uncategorized and tagged , . Bookmark the permalink.

2 Responses to Recruitment – How we screen candidates

  1. jasonrdavey says:

    As a senior engineer / architect, I enjoyed reading a perspective of candidacy from the “recruitment side”. I have hired several engineers and agree with almost everything you’ve said. I particularly like the palindrome question and I may “borrow” that for our next candidate. I also concur with your “care” statement. Too many engineers are sloppy, lazy which translates into poor ROI for the business, manifest by poor quality code and an expensive SDLC because the team now has to fix production bugs – very expensive – rather than focusing on revising the engineering process that causes the production bugs (UML design, unit and functional testing, quality code review by peers, automated code checkers such as var-scoper utility (for CF) etc).

    I will say I’m more forgiving on SQL. I find that my testing benchmark is low here because most engineers rarely do SQL (assuming a DBA is on the staff). Knowledge of CRUD statements, stored procs (why and how), indexes and some basic filtering using JOINS (UNION,LEFT,INNER) are all I ask. Instead I focus on testing their ability to find answers to questions and to evaluate the best solution given a few key parameters such as (must be super fast), or limit to ten records per page and see how their solution changes on the fly. I also ask them about design patterns, Object oriented concepts (polymorphism,inheritance, the diamond of death). I also quiz engineers on race conditions. “What is a race condition?” often sorts out the men from the boys (particularly in the CF domain).

    Another good one (I had this in one interview) is to have the engineer face a white board with marker in hand, and you describe a problem at a high level and ask them to solve it, then you change your mind, adding variances, new features along the way. This is a great exercise to see how they think on their feet and express to you how they accomodate the changes both technically and verbally. Their answer is less interesting in how they cope under pressure to new demands.

    Cheers.

    • ciaranarcher says:

      Thanks for the feedback Jason. It sounds like you have some pretty strict interviewing techniques too! We do discuss design patterns etc. and also explore the candidates’s past the use of frameworks. Ideally we’re looking for some insight into how a framework can stop spaghetti code and help with dev and maintenance.

      I must also mention that the steps I described have only be used for junior development positions. I’d have a lot more to add to a senior position – and I would use some of your ideas (especially with a whiteboard example) if we did that.

      The other thing I often find is that many candidates have no experience of real ‘load’, i.e. 1000s + of clients on your side all at the same time trying to do transactional stuff like payments etc. That kind of experience really is priceless. The same can be said of experience in clustered environments.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s