Ah for the good old days when you hired typists by sitting them down at a typewriter and giving them a typing test. 50 words per minute and no mistakes? Great! You are hired!
What test do you rely on when you are hiring a software developer? The truth is that every hiring manager answers that question differently.
Consider some of the different techniques:
While any of these techniques might provide insight into the candidate, they all have shortcomings.
Some people are great at answering technical questions in a memorized-the-answers fashion. They have a great ability to remember facts that they read in books, but may not be quite as adept at putting the theory into practice.
Some people are very poor public speakers. While it’s true a software developer has to interact with people, he or she doesn’t necessarily have to do it in front of a group.
Some people are uncomfortable bragging about themselves, so they fall short when characterizing the history of their contributions to projects.
And so it goes.
Each approach has its merits, too, and in certain cases may be the superior interviewing technique. For instance, a prospect for an architect’s role reveals a great deal during a white boarding exercise.
But when it comes to selecting a software developer, none of the above actually show you how the candidate approaches the actual task he or she will be charged with. A typing test for a typist reveals the candidates skills better than tell me about your last job or asking questions about the candidate’s knowledge of IBM Selectric Typewriters, doesn’t it?
So why not a software development test?
Here is an approach that I like. It starts with a project that uses the technology elements that the candidate will use should he or she get the job. To be clear, if you are hiring a C# programmer, you have a C# project that is already underway that can be used in this type of assessment.
Set up a specific, relatively straightforward element that needs to be implemented in the project. It can be defined and described easily—so easily that the candidate would probably be able to understand the requirements without anything written down. But the requirements should be written down anyway. You could require the candidate to implement something that is completely new. You could require the candidate to complete something that is partially implemented. Either will work. The key is that the element has to be relatively straightforward so that the candidate can grasp the requirements with ease.
The next step in the process depends upon you. I like to have the candidate create an implementation plan and estimate each step of the implementation plan. This gives you great insight into several aspects of his or her skills. Can the candidate plan an implementation? Many people cannot envision how they will tackle a task, and as a result they cannot break it down into an implementation plan. This is valuable data about the candidate. By looking at the candidate’s estimates for each line item in the implementation plan, you get a sense of how junior or senior the candidate is (or conceives him- or herself to be). If a task would take a senior person 15 minutes and a junior person one hour, the candidate’s estimate can be very informative. He or she is basically self-assessing for you. On the back end of the work, you get to see how accurate the candidate’s estimates are.
Then the candidate does the implementation. It’s done completely open book, open note, open Internet.
While the candidate is doing the implementation, the hiring manager or another technical leader can introduce a variety of curves: ask the candidate why certain decisions were made, require the person to change on a dime and do things differently, change the requirements, and so forth.
How the candidate grasps the requirements, plans, estimates, codes and handles change give a great insight into what the candidate will be like in action. And that’s what I like about this style of interview.
If your team suffers from change, then throwing change at the candidate and seeing how it’s handled is valuable data.
If your team is full of opinionated people—and you prefer to hire people who can stick by their guns—then seeing how someone handles a challenge to his or her approach is important.
And just plain watching the person write code can be tremendously valuable.
It takes a while to refine the projects you use. And you want to keep the duration of such an activity relatively short. Unless, that is, you don’t mind paying people for a day of interviewing—which many companies are now doing.
