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:
- The Quiz Show: In which the top technical person or people in the team bombard the candidate with technical questions.
- The Ramble: “Tell me about your last project,” in which the candidate flounders about trying to describe a project in the just perfect amount of detail.
- The Lecture: In which the candidate stands up in front of the team and gives a technical presentation about something of questionable interest, likely in an unpolished style of public speaking.
- The Diagram: The whiteboard exercise, in which the candidate solves a problem or designs a system on a white board.
- The Survey: A written questionnaire, in which the candidate answers questions about past experience with this, that and the other thing.
- The Puzzle: In which the candidate is given brain teasers or logic puzzles to solve on the theory that, well actually I’m not sure what the theory is, but I guess it tells you if the candidate is easily annoyed by logic puzzles and trick questions!
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.