Test for Technical Competence? Sure You Can!

Interviews, alone, are an incomplete and unreliable way of judging a candidate’s technical competency. There are two reasons for this.

The first is that practices are so different when it comes to the process of completing an engagement. You might want a staffer to complete Steps A, B, C, D, and E before giving the project to you for review. Your candidate might work for someone in another practice who feels that Steps A, B, C, and D are sufficient. So, when you talk with the candidate in general (and sometimes euphemistic) terms about the process, you may not have the same ground of understanding.

The second is that candidates naturally put their best foot forward during an interview. This is human nature and doesn’t mean they lie. But it does mean that they will almost always choose—or shade—an answer so that it shines the best light on their capabilities.

You should always test for technical competence. One approach, depending on the experience level of your candidate, is to test for Excel skills. You can find many off-the-shelf options, or you can devise a simple one yourself that tests for particular applications your candidate will encounter at your practice. Another approach is to use real-world work product, asking your candidate to take the work product from Step C to Step D, for example. Use something from a past project so you can easily judge whether your candidate can do the work you expect. Change any client names to protect confidentiality.

Hiring means relying on assumptions you make about your candidate. Testing for technical competence can help you filter out those assumptions that can result in a bad—and expensive—hire.