Interviewing Programmers

As anyone who reads this blog knows, a few months ago I went through the process of finding a new job.  That of course included a number of interviews.  Which got ‘interviewing’ on my mind and encouraged me to write this article.  Now, months later, I finally got around to it.

I’ve interviewed my fair share of programmers over the years, and I find personally that how you interview a ‘junior’ versus ‘intermediate’ versus a ‘senior’ programmer needs to change.  Specifically in regards to one topic.

What’s that topic?   It’s giving a coding test (as well as just whether you ask coding questions in the interview)

I personally find that asking a coding test of junior programmers is a GREAT tool for helping to evaluate them.  Typically just a very simple test, a basic CRUD application.   Looking at what they create not only gives you insight into how they think and code (did they do MVC?  a simple single .php file?  handle web security? etc).  It also gives you a great starting point to begin discussions with them in person, asking them about why they did (or didn’t) do certain things.

It’s also worthwhile to go into great depth with junior folks just to make sure that they understand some basics of programming.  Recursion?  Object Oriented? etc.

That starts changing somewhat when you start interviewing folks who are more at an intermediate level.  At the that level, asking for the coding test is fine, but I like to offer for them to instead just provide some code they’ve written before if they wish.  From looking at their code, you may come up with a few directions that you want to guide the discussion with them in an interview to understand certain parts of their knowledge.

This completely switches over in my mind when it comes to interviewing a senior person.  Someone who is ‘senior enough’ (use your own definition) should have their experience speak for them enough that there is no reason to ask for a code sample, let alone giving them a coding test.  Typically looking at their experience and asking them a number of probing questions about their experience should rapidly inform you if they know what they are talking about.

Now that’s not to say, that if after doing an initial interview, if something seems fishy, or if you are concerned about their experience, then go ahead and ask for a sample/test after the fact to dig deeper.

But my point is this, when interviewing for senior candidates, you should be spending time researching their experience, their history, what they’ve publicly done, presentations/articles/etc they’ve done and more.   You should take the effort to learn enough about the candidate that it should make most questions about their ‘coding skills’ a moot point, and leave you instead asking more about bigger picture questions, and to see how well they fit within your team.

Also I highly suggest that any coding test you give be a ‘take home’ test.   Let them take their time to do the problem in their own environment.   Asking someone to do a live coding test in front of you is asking for failure.  Are you going to be standing over them watching their every keystroke when they are working for you?  no?  Then why would you test them in that environment?  It doesn’t give a good indication at all as to how well they code (and the style in which they code) when given the freedom to do so.