It's perfectly reasonable for a job interview to include questions that require you to use your skills to solve a problem. Each of this book's chapters contains exercises that might make good interview questions—at least if the candidate is well-versed in algorithms. However, many of those questions would be quite difficult if you hadn't recently been reading about the relevant algorithms.
Not long ago, companies such as Microsoft and Google included certain kinds of puzzles while interviewing job applicants. Some tech companies have discontinued the practice, but you might still find some companies using them.
The puzzles are intended to measure a candidate's creativity and critical-thinking ability. Unfortunately, these sorts of puzzles come with a large set of assumptions that may not be true. Most business situations, even in programming, are not phrased as puzzles involving balance scales, marbles, rickety bridges, and goats. They usually don't involve a clever trick or an amazing insight that is blindingly obvious after you hear it but that is practically impossible to figure out in a 10-minute interview.
It's true that finding the best solution to a real-world problem often requires creativity, but many of these kinds of puzzles don't measure creativity. Instead, they measure whether you've scoured the Internet long enough to find the problem that the interviewer is asking about.
For example, consider the following questions:
Take a moment (but only a moment) to think about these questions. Here are the answers, with some comments:
The Journal of Applied Psychology article “Why Are Manhole Covers Round? A Laboratory Study of Reactions to Puzzle Interviews” questions the usefulness of these kinds of interview questions. The article says this kind of question is not a very effective method for gauging an applicant's reasoning ability. Applicants may also feel that these questions are unfair or arbitrary, and that may cause them to become uncooperative or to turn down the job if it is offered.
Does that mean these questions are worthless in interviews? They certainly are if you use them incorrectly.
The next two sections discuss how to handle these sorts of questions as an interviewer and as an interviewee.
The preceding section gave some examples of bad interview puzzles. They rely on knowledge of trivia or, at best, the ability to work backward from a solution to a problem. Working backward does take creativity, but you can certainly be creative without that ability.
More than anything else, those problems tell you how well the candidate combed the Internet, looking for potential interview puzzles. There's some benefit in knowing that the candidate prepared thoroughly for the interview, but it doesn't really tell you much about his or her creativity or problem-solving ability.
To get useful information from a puzzle, you need a question that the candidate hasn't seen before. On the other hand, the puzzle can't be so impossibly hard that the candidate panics. It shouldn't rely on a trick or point of trivia that only measures whether the candidate happened to see a particular issue of some obscure magazine.
Unfortunately, that rules out a lot of puzzles. Those that remain include puzzles that ask the user to perform a calculation, make an estimate, or otherwise do something that may be straightforward but that gives the candidate room to explore possible approaches.
For example, one popular interview question has a form similar to this: “How many baseballs fit inside a school bus?” The candidate is highly unlikely to have memorized that fact, so this question is really asking the user to come up with an estimate. A good answer will list the assumptions that go into the estimate and perform a calculation. (Suppose a school bus is 36 feet long, the interior is 7 feet high, a baseball is 3 inches in diameter, and so on.) It doesn't really matter whether the assumptions are correct, as long as the process makes sense.
This question determines whether the candidate can perform back-of-the-envelope calculations, which is relevant to software engineering.
Another kind of calculation puzzle comes in a form similar to this: “If I'm three times as old as my brother, and in two years I'll be twice as old as he is, how old am I now?” (See “Appendix B: Solutions to Exercises,” Chapter 19, Exercise 6, for the answer to this question.) This is mainly an exercise in translating a word problem into a set of equations. That skill is certainly useful, but many people don't like word problems, and most real-world programming problems don't take this form anyway.
Clock puzzles have this form: “How many times do the hour and minute hands on a clock cross each other between noon and midnight?” (See “Appendix B: Solutions to Exercises,” Chapter 19, Exercise 7, for the answer to this question.) This puzzle and other clock puzzles usually can be solved by using a table and plugging in some values. That approach doesn't really showcase the candidate's creativity, but it does show that the candidate can be organized.
Chapter Another way that you can get some use out of puzzles is to discuss the puzzle afterward. For example, you could use a relatively simple puzzle that you're pretty sure the candidate can solve. Afterward you can discuss why the solution works, how the candidate found the solution, what other approaches might have been worth trying even if they wouldn't work, and so on.
Alternatively, you could give candidates a very hard puzzle, give them time to think about it so that you're sure they understand the constraints, and then discuss the solution. Now you can talk about different approaches that you might take to reach that solution.
Probably a better approach than a simple puzzle is to describe a situation that resembles one that you might actually encounter in your business. For example, you might say, “Let's design a database to store vacation plans for aliens from other planets.” This problem is big enough to give the candidate plenty of room to show his or her database design skills and creativity, but it is silly enough so that the candidate probably won't panic. If you like, you can work through the problem together to see how the candidate interacts with others. You can propose strange twists and ask the candidate what might go wrong under different circumstances to see how creatively he or she handles unexpected problems. This kind of interactive challenge is harder to control, and different candidates may come up with very different solutions, so it may be hard to judge among them. However, this challenge can teach you a lot more than a simple puzzle.
Puzzles can be interesting and entertaining, but they're probably not the best way to measure the qualities that you want in your job candidates.
The preceding section argued that puzzle questions don't really measure the characteristics that an employer wants in a job applicant. Instead of measuring your creativity and critical-thinking ability, they measure your ability to memorize trivia and scour the Internet to find these sorts of problems.
Just because these puzzles don't measure the qualities that they seem to doesn't mean you won't see them in an interview. Some interviewers may use them to see how you handle pressure, respond to unreasonable demands, and cope with impossible problems. These sorts of puzzles may not measure creative thinking ability, but they may provide information about your psychological makeup.
So how should you respond to this kind of puzzle question? First and foremost, don't panic. Whether the interviewer expects you to solve the problem or just wants to see how you react, panicking won't help. Freaking out will make it nearly impossible to solve the problem and will create a bad impression.
Instead, focus on the problem. Once you start working on the problem, you won't have as much time to panic.
Many puzzles at technical interviews are related to programming. They may ask you to reverse the characters in a string, sort objects in an unusual way, copy a data structure, or perform some other straightforward but confusing task. In those cases, think about the algorithmic techniques that you know. Here are some techniques that you should consider:
If you get stuck, you can also try some of the following general problem-solving tips:
Failing to solve an interview puzzle doesn't necessarily mean that you failed the interview. If you try hard, exhaust all of the approaches that you can think of, and are clearly getting nowhere, it may be better to ask whether you should stop. You might say something like, “It seems like a recursive approach would be promising, but I think I'm missing something. Do you want me to keep working on this?” If the interviewer wants you to continue, he or she can say so.
Even if you fail to solve the problem, the interviewer probably will learn something from your attempt. If you talk as you work, the interviewer probably will learn about some of the approaches that you know and something about how you think about problems. The interviewer also will see what you do to understand the problem before trying to solve it and how long you work before giving up.
One thing that you should never do is try to pick apart the interviewer's questions to prove how stupid they are. While looking for websites that contain puzzle-style interview questions, I came across an article in which the author gave a series of “snappy comebacks” to the interview question “How would you design a routine to copy a file?” The article had the applicant ask all kinds of questions about what kind of file it is, whether the file's permissions should be copied, whether the file should be encrypted, whether it should be marked for backup, and other detailed questions until the fictional interviewer was frustrated to the point of saying, “Look, just copy the damn file.”
The article's point was that this is a stupid question, because no one writes his or her own routines to copy files. That's true in most cases, although I've worked on projects where copying files was particularly tricky due to file locking issues. In fact, the biggest bottleneck in that customer's whole operation involved copying tens of thousands of files per day multiple times across a series of computers that performed various operations on them. Even a small mistake in copying files resulted in lost files or a backlog of hundreds of thousands of files. Even if a question seems pointless, you can't be sure of that until you know background behind the question.
Proving how smart you are and how stupid the question is won't land you the job. At best, you'll show impatience and a lack of interest when confronted with a problem. At worst, you'll alienate the interviewer, imply that you cannot solve the puzzle, and give the impression that you don't care about the employer's problems.
A much better approach is to inquire why the interviewer is asking the question so that you can understand his or her point of view and come up with an appropriate response.
Interviewers sometimes use puzzle questions in an attempt to measure a candidate's creativity and critical-thinking skills. Those puzzles don't do a very good job of that, although they may provide some insight into how a candidate deals with frustrating situations.
If you're an interviewer, avoid puzzles that rely on trivia, require the candidate to work backward from a solution to a problem, or are so difficult that the candidate would have to be exceptionally lucky to solve them. Puzzles that make the candidate perform back-of-the-envelope calculations are better and more relevant.
Better still are questions that are similar to those that the candidate may actually encounter at work. You also can use exercises similar to the ones included in this book or other books about algorithms and programming in general. You should be careful not to pick questions that are too difficult, however. Only someone who has studied algorithms extensively or fairly recently will remember the finer points of balanced-tree rotations or how to show that optimization reporting (or even know what that means).
You can usually learn more about what the candidate knows by asking questions and discussing problem-solving approaches than you can by posing a single puzzle that may happen to fall outside of the candidate's realm of experience.
If you're a candidate, try not to panic or be offended by puzzle questions. Make sure that you understand the problem and give it your best shot. Remember, failing to solve a problem doesn't necessarily mean you've also failed the interview.
You can find a huge number of puzzle questions online by searching for “interview puzzle questions.” Read a bunch and get a feel for the kinds of things interviewers ask and the kinds of approaches required to solve them. Even if you don't face these sorts of puzzles in an interview, they can be interesting and fun, so you won't have wasted your time.
However, don't forget to work on the other parts of your interview skills. Brush up on your algorithms, database design, architecture, project management, and other relevant skills. Last but not least, don't forget to get a good book or two about how to prepare for interviews more generally.
See the following links for some sites that provide particularly interesting puzzles, puzzles that have been used by companies such as Microsoft and Google, and information about puzzle questions:
https://www.newyorker.com/tech/annals-of-technology/why-brainteasers-dont-belong-in-job-interviews
http://www.mytechinterviews.com/10-google-interview-questions
http://www.mytechinterviews.com/10-famous-microsoft-interview-puzzles
https://online.wsj.com/article/SB10001424052970204552304577112522982505222.html
http://www.techinterview.org
https://www.facebook.com/interviewpuzzles
http://www-cs-students.stanford.edu/~hdwang/puzzle.html
http://dailybrainteaser.blogspot.com/2010/08/top-5-microsoft-interview-questions.html
http://www.a2zinterviews.com/Puzzles/logical-puzzles
http://www.coolinterview.com/type.asp?iType=619
https://www.careercup.com
http://www.moems.org
Many books also cover these sorts of puzzles. Look for them in your favorite bookstore.
The following exercises are brief examples of some common types of interview puzzles.