I cannot even count how many technical interviews I’ve done. No less than 500. There were phases in my career where I continuously did 4-6 a week for weeks on end. At least half of those were done the wrong way. Luckily it was the first half. From this, I have learned how to do a better technical interview.
I’ve noticed when a lot of people do technical interviews, they fall into the same trap I first fell into. They focus on whether the candidate knows the same technical trivia the interviewer knows.
On a software team, most of the people have been through some common training, read common books (often recommended by the training) and code with common standards and design patterns. We use common libraries, frameworks and third party tools. We have code reviews and design sessions to reinforce these commonalities. Don’t get me wrong, this is all good. Software teams that allow any developer to open up almost any code block and not ask themselves “what were they thinking?” is a good thing.
But, how many times has a candidate come in we ask them what training they have been through, books they read, third party tools they use, design patterns they follow and so on. The trap is we begin thinking “if you have been doing things like us, you must be smart. If you haven’t, then you are not smart.”
I can say that if your standard of technical prowess is “you know the same technical trivia I know”, you are missing the mark and potentially letting some really smart people go.
When I changed my technical interview style and questions many years ago, the quality of people I let into my organizations became much higher. Instead of hiring people who just happened to have read the same book I had, I began hiring very good problems solvers who could make valuable contributions. Question I started asking began to be like these:
- Here is a different model. Have the candidate pick a recent project. Tell them to explain the business purpose of it and how it benefited the users?
- Tell me about the architecture. The DB, the business rules, the UI, the web services. How data was passed though. Everything else.
- Why was it architected that way what? What was their role in the architecture? How would you have architected it differently now?
- What third party tools, framework or libraries did you use? Why did you use those? Would you have chosen something else?
When it was all said and done, I was able to determine if the individual was able to understand their environment and could think of ways to improve it. Is it not better to have a good problem solver added to your organization as opposed to someone who read a book because his former project leader made them read?