On Hiring and Trivia Questions

I’ve talked about FizzBuzz. I’ve talked about years of experience. But there’s another topic to cover which hits almost every developer interviewing for a position: trivia questions.

Everyone's favourite game of pointless knowledge.

I need to define what I mean by trivia question. A trivia question is a question that has a definitive answer that can easily be searched on Google. These include things like, “What is a singleton?” And, “What’s the difference between a thread and a process?”

Don’t get me wrong, these are questions where experienced developers should know the answer. But, anyone can learn and memorize the answers to these questions. More than that, if someone has the capacity for learning — as all developers should — then these are things people should be able to learn and grasp in a day.

I went to an interview ten years ago for a junior developer position. I thought the interview went pretty well. The interviewers were impressed with my experience from some projects I’d been involved in, but then they asked me to list off design patterns. I thought it was an odd question — I’d never heard of design patterns. Surely, they continued, I must have at least heard of a singleton. Nope.

The thing is, I was using various design patterns. I just didn’t know the terminology. A coworker of mine today told me a very similar story. He had brought in examples of code he’d written, but he didn’t know what a singleton was, so they weren’t interested. He told me that his code actually contained a singleton, but they wouldn’t give it the time of day.

Another coworker told me that during an interview he was asked to give examples of .NET interfaces. I can’t imagine many people who work in .NET would have trouble with this question, but I also can’t see any value in it. It is so easy to learn the names of interfaces that it surely doesn’t tell you whether a candidate can actually write any code.

What’s the number one goal of an interview when you want to hire a developer? Figuring out if the candidate can actually write code that you want to maintain. If the candidate can’t write any code then there’s no point in even going further. Trivia questions do not tell you that a candidate can code, they don’t really tell you anything at all. They do give candidates good stories to tell in the future that might discourage others from applying for positions in your company.

Here’s what I would suggest: when there’s an area you really want the candidate to know about, like design patterns or interfaces, ask the question. If the candidate tells you that they don’t know but they can learn, great! Ask them to prove it by taking a week to code a small demo application that shows off the point in question. Then have another interviewer where they can teach you about the topic.

This shows that the candidate has passion, initiative, and the drive and capacity to learn new things. It will also show you that the developer can code — or show you that they can’t. The reason you ask them to teach you about the topic is so that you know they didn’t just farm out the work or copy it from Stack Overflow without actually learning.

When I’m being interviewed, this is a key tool now. If I don’t understand something or feel I got something incorrect after the interview is done, I will correct myself and write some code to demonstrate. Then I email it to the interviewer. It can only help.

(And for those who are curious, I have learned about design patterns since that interview.)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s