Interviews are always an interesting topic, and for software engineers the interview process can take many forms. First, there is the standard interview where you are asked questions regarding the technologies that the potential opportunity uses. Those types of questions are always useful because you can find out if someone is lying on their resume or just how much they really know about a given topic. On the other end of the spectrum, there are the puzzle interviews that Microsoft and Google have become famous for, even though Google no longer uses puzzles. Somewhere in between are those interviews where you get a significantly different programming or design question that is meant to take 15 to 30 minutes of the interview.
I have talked about interviews, job searches and hiring before. In once case, I talked about finding a job that fits from the perspective of the job searcher. Those same questions can be asked by the interviewer to determine whether the prospective employee would be a good fit for the organization. As I stated in that post, some people can thrive in the small company atmosphere, while others require the structure of larger companies. However, those organizational questions still do not get to the heart of the problem. Is this person someone we want to hire? Will this person be productive in our environment? One thing I should note, if your company only hires due to specific technology needs, then you do not need to read any further. Those interviews typical focus on specific technical knowledge, and the rest of this post is not about that. This post is more about those weird puzzle questions.
Are puzzle interview questions helpful in hiring developers? This is an interesting question because so many companies still use puzzle questions in their interview process. The idea behind these questions is that you are supposed to get an idea of how the person thinks through a problem. However, many puzzle questions do not require the interviewee to think for very long. They either get the answer right away, or they require a few hints. A good example of a puzzle question is The Rope Bridge. It is one of the more relevant puzzles, but how much does it help you determine whether your interviewee will be a good developer in your organization?
The other side of this are the “fish out of water” questions. What I mean is that you have the interviewee explain a system for something they have not thought about before. These questions are more easily applied to application design. For example, one design question I have seen is the “elevator system”. Unless they worked in embedded systems, it is unlikely that they have run into this type of situation before. This type of question gives you an idea of how they think through an unknown problem domain. The only issue with something like the elevator system is that people may have problems determining the objects and behaviors within the system. Sometimes an unknown domain means that there will be more questions than answers.
Finally, there are the programming questions that people use. The utility of these questions vary greatly as the complexity is typically varied as well. You can start with fairly simple questions like “FizzBuzz“, where you write a function that prints “fizz” when a number is divisible by 3, “buzz” when the number is divisible by 5 and “fizzbuzz” when the number is divisible by both 3 and 5. The solutions is quite simple, but it does tend to stump a lot of people. Personally, I do not like “FizzBuzz” because it does not tell you much about a senior level engineer. The problem with simple questions is that interviewees may think they are harder than they really are. Just a few months ago, I wrote about hiring programmers and one statement is very relevant to this discussion, “Most people tend to get very nervous during an interview which makes even simple programs somewhat difficult to write.”
So, if simple programs do not tell you enough, you need something a little harder. For some companies, if you pass an initial phone screen they may ask you to complete a programming assignment or it could even be the entrance criteria for the interview process. Recently, I saw one of these questions on JavaLobby:
By starting at the top of the triangle and moving to adjacent numbers on the row below, the maximum total from top to bottom is 27.
4 6 8
0 7 1 5
I.e. 5 + 9 + 6 + 7 = 27. Write a program in a language of your choice to find the maximum total from top to bottom in triangle.txt, a text file containing a triangle with 100 rows.
This is an interesting problem although it may not be entirely relevant to your future job. One issue with this type of programming question is that you do not see the thought process of the interviewee, and the problem could be too difficult for a 30-minute segment of an interview. So, you need to find something that could be completed within 30 minutes and give you a solid feeling for how competent a person is. One question I have run into that fits this nicely and does not require any domain knowledge is the following:
You have multiple lists of numbers that may or may not be sorted and need to be sorted into one large list. How do you do this?
In my experience, this problem takes anywhere between 15 and 30 minutes and it requires the person to write some code on a whiteboard. It is an interesting question for a few reasons:
- it is definitely solvable within 30 minutes
- it does not require advanced algorithmic knowledge like AI or machine learning
- it can require code without being too extensive
- it can lead to other talking points like performance and memory consumption.
The key thing to remember is that you need to be comfortable working with this person as well as being comfortable with their level of knowledge. Finding the appropriate level of detail and complexity in interview questions is like a dark art. Some people figure it out after years of study and refuse to tell you their secrets.