Written by Peg Bogema, President at Stout Systems
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!
Nowadays when it comes to hiring a software developer, every hiring manager takes a different approach to qualifying candidates.
Here are a few of the more common approaches:
- The Quiz Show: In which the technical team members ask the candidate a variety of questions.
- The Ramble: “Tell me about your last project,” in which the candidate tries to describe one of their projects in the just perfect amount of detail.
- The S.A.T.: In which the candidate is given an old-fashioned written test.
- The Coding Challenge: In which the candidate solves one or more coding exercises that are more like puzzles than real code.
- The Coding Exercise: In which the candidate is given a project and asked to implement a new feature or algorithm—or complete one that has been partially implemented.
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. Likewise, they may favor recent college graduates who have just studied the fundamentals of their subject. Veterans may not have their basics right at their fingertips—which doesn’t necessarily mean they don’t operate on them every day.
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 cleverly conceived coding challenge may reveal a great algorithm developer.
When it comes to selecting a software developer, we favor a form of paired programming activity.
It starts with a project that uses the technology elements that the candidate will use should they 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. We like to have the candidate create an implementation plan and estimate each step of the implementation plan. This gives great insight into several aspects of their 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. If a task would take a senior person 15 minutes and a junior person one hour, the candidate’s estimate can be very informative. They are 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. And the interviewer observes the candidate as they work.
While the candidate is doing the implementation, the interviewer 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 their 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. Typically an hour or two is plenty of time. When that time is up, you’ll understand a great deal about both the technical ability and the soft skills of your candidate.
Happy hiring!
This is a technical/business article catered to developers, hiring/project managers, and other technical staff looking to improve their skills. Sign up to receive "The Informatizer" in your email inbox.
If you're looking for a job in the tech industry, visit our job board to see if you qualify for some of our positions. If you're looking to hire technical talent for your company, please contact us.
Stout Systems is the software consulting and staffing company Fueled by the Most Powerful Technology Available: Human Intelligence®. We were founded in 1993 and are based in Ann Arbor, Michigan. We have clients across the U.S. in domains including engineering, scientific, manufacturing, education, marketing, entertainment, small business and robotics. We provide expert level software, Web and embedded systems development consulting and staffing services along with direct-hire technical recruiting and placements.
Top comments (0)