I’ve written about performing interviews for developers. There is way too much focus on developers improving their “interviewing skills” and not enough on interviewers doing a better job themselves. One of the problems interviewers have is they ask candidates to solve classic computer science problems.

I did this when i first started interviewing. It made sense because it was what everyone else did. Also if a person’s job is to write software, they should be good at algorithms!

At one company, we hired this developer who was phenomenal by this standard. His solution to our problem blew every other candidate out of the water. It was even much better than what we ourselves had come up with as the solution. His previous work in 3D graphics was also extremely impressive.

How do you think he did on the job?

He wasn’t terrible, but he performed well below what we expected. He was great with algorithms, but very little of the work we did required complex algorithms. We had small teams competing with companies ten times our size. We needed to build things quickly and to design our software in ways that would make it easier to build things quick. We needed our infrastructure to scale to millions of users. And we needed someone who had a breadth of knowledge: front end, back end, databases, networking, etc.

We didn’t ask any interview questions about the things we needed.

This developer was in many ways a great developer, but his best skills were underutilized with us and we did not get great work out of him. This experience taught me that interview questions have to reflect the kind of work the person will actually do. It sounds like it should be obvious, but most interviewers make the same mistakes we did. The range of responsibilities for developer positions at different companies vary greatly.

Whenever I now join the hiring process at a new company, I create questions based on the work that company is doing. Any feature or problem the company has solved is fair game. I don’t have to give away any proprietary information. I just show a feature that users see in the application and ask a candidate how they would implement it.

Because the problem is one the company has solved, any candidate that can come up with a decent solution will be able to do the work the company requires. There is also the added advantage that discussing the problem with a candidate is reflective of how I would work with them. These discussions would be similar to the ones we would have if the candidate was part of the company when we had to solve that problem originally. If the candidate is great to work with in the interview, they will probably be great to work with on the job. (NOTE: I have made one bad call since taking on this strategy)

In some cases, you may find yourself wanting to hire someone who knows something you don’t. How do you test their competency in that area if you yourself don’t have it?

The need to hire this person will stem from a problem you know you have to solve in the future. At this point you should have at least some kind of solution, even a terrible one, that you would go with in case you can’t make the hire in a timely manner. In this case, this problem makes the perfect interview question. If a candidate can’t come up with a better solution than you, then you don’t need them. If they can’t explain the solution in a way you can understand, then you can’t work with them. I’ve only had to do this for three positions in my career, but all three hires were wild successes.

This interview strategy isn’t perfect by any means. The only perfect way to know if a person would work out is to hire them and see what happens after a few months. We perform interviews because that is too expensive to be viable. But asking questions based on the work you need a candidate to actually do will provide much better results than questions based on what you theoretically need.