If you’re hiring someone whose job requires technical skills, assess those skills as directly as you can. Test them. As mentioned in the beginning of Chapter 5, testing technical skills for a technical job is in fact a behavioral interview, focusing on technical behaviors.
Do the testing in a separate interview. Don’t make the classic mistake of having every technical person spend 20 to 40% of his or her interview time making some insufficient attempt to verify a candidate’s technical skills. At the end of that interview, they won’t know enough about the candidate’s technical skills and they won’t know enough about other behaviors addressed in the behavioral interviews.
So one of your interviews on the final interview day addresses nothing but technical skills. The outcome of this interview is a hire/not hire recommendation based on the technical skills assessed.
Based on the types of problems you assign, do you need to provide 5 minutes for this problem, 15 for that to fill up 60 or 90 minutes?
Some examples of problems and questions: If you’re hiring someone who needs to be an expert in MS Excel, give a test to see whether he can create a pivot table. Give him a dataset—rows and columns of data in Excel—on a laptop, and give him 30 minutes to create it. (If you think this is trivial, you only have to assign it one time to have people fail, all of whom described themselves as MS Office experts.)
If you’re hiring a mechanical engineer, ask her to work out a simple heat transfer problem. You have an energy source, emitting radiation of X kilojoules, and a black body. With these equations and the data shown, determine the rate of absorption of the black body.
If you’re hiring a software developer, give him a recursive word break problem. Or some code in a language that your firm uses (and remaining candidates likely know) with a bug in it, and ask him to debug it. Or give her a function to solve that would legitimately be part of your internal applications, and ask her to use pseudo-code to create the function.
If you’re hiring a structural engineer, give him a series of problems one of which might be, “Here’s a diagram of some loads on a beam. What’s the deflection mid-span, and what’s the reaction at the connection point?”
If the candidates are going to have to write (versus type) their answers, have them do so at a white board. If the problem requires computer entry, connect a laptop to a large monitor. When we conduct a “normal” behavioral interview, we are “observing” behaviors by listening to their answers. In a technical interview, you get to observe the skills in real time.
Don’t be afraid to probe people’s efforts as they work through a problem. You interject here just as you would in other behavioral interviews. For instance, “Sorry to interrupt here, why that choice? Why not wait to do that calculation later?” or “Excuse me, help me understand that. What if you didn’t have access to that array?”
If you want more guidance on hiring software developers, I highly recommend one of the best professional books I’ve ever read: Smart and Gets Things Done by Stack Exchange Co-Founder Joel Spolsky.