It's a bad question if you expect a quick, explicit answer. It's somewhat less bad if you're looking to have a conversation about how to solve problems the candidate hasn't seen before.
I've used an arguably "puzzle" question that was presented to me in an interview with some success -- the missionaries and cannibals problem. There are three missionaries and three cannibals that you must get across a river. The boat holds only you and one other person. The cannibals on either bank must never outnumber the missionaries on that bank. It's a good question to see if a candidate understands how to apply some basic computer science concepts. It can easily lead to a 30 minute discussion at the white board, with no need to get working code.
My favorite question is completely different. "What do you like best about your favorite programming language and what would you change about it if you could?" Anyone who doesn't see any flaws in their favorite language, particularly if it's Java, gets politely shown the door.
The problem with using this as a meta-question, is that someone who knows the answer may treat it as such.
That is, the person who comes to realize the canonical way of solving it may truly be brilliant and having been hinted and helped along the way came up with the solution, or he might have already known it and just played a metagame, assuming that's what you wanted.
Basically, you have four possible outcomes:
People who have never heard of it, don't come up with the canonical solution.
People who have heard of it and just blurt out the answer.
People who have never heard of it, but who come to realize it over the course of the interview.
People who have heard of it and who play it as a game, working towards it and then suddenly having an epiphany.
The first is interesting. The second you hopefully dispense with the question as being useful. The third would be a great hire, but is indistinguishable from the fourth, who you've learned nothing about except they know how to play your interview process. Which may or may not be the criteria you're looking for.
I was asked a puzzle question that I hadn't heard before. I answered it directly almost immediately. In a later interview with the CEO he asked if I had heard the problem before because the interviewers were sure I had with such a fast answer. I said I had not and just left it at that. Playing the whole thing back in my head, I think this cost me the job for "lying" to them. I might have been able to convince them on how quickly I got the problem if I had taken this as a questioning of my integrity.
"There are 128 chairs on a ski lift. You get on at the bottom, and ride it all the way to the top. On your trip up, how many do you pass on their way down?"
There may have been some distracting info of distances and speeds in there to make get you going in the wrong direction.
My experience with puzzlers is that average people like to feel superior for knowing the answers to a puzzle that someone else doesn't know. The people who can solve these easily are thrilled to find a puzzle they don't know the answer to. Then there is the group who can make a good puzzle.
Something like happened to me once, someone asked me a riddle (it was: "you have a polynom of coefficients that are positive integers. I can give you the values of this polynom at integer points of your choice. Can you get all the coefficients by asking only two values?"). Somehow I got it very quickly, and was thinking in my head "oh man I didn't know I was that clever", but the guy thought I already knew the answer.
Wouldn't the answer be 127 of them? You're passing the one behind you as you get on at the bottom, and the one in front of you as you get on at the top.
I well my view if you walk to the base of the lift half on the chairs are on the up side leg half on the down you get on the one right at the bottom. so you pass all the chairs on the downward leg
Actually this is a simplification as the chairs slow down and bunch up at the bottom and top to make getting on and of simpler
> Actually this is a simplification as the chairs slow down and bunch up at the bottom and top to make getting on and of simpler
Yeah, this is the problem with the question that I noticed as well.
If you don't know what a ski lift is (grew up in the south and didn't have money for vacations as a kid), you might not even know how ski lifts work. In which case maybe you guess that the chairs are fixed and give the 127 answer. Ironically, you guessed wrong and got the correct answer.
If you do know how ski lifts work and assume the interview does as well, then you just look like an idiot.
I guess the lesson is to state all your assumptions (and also, don't ask these questions).
Disagree: it's a terrible question. The answer (all of them) is something you either see or don't, and neither tells you much more than one bit of information about the candidate.
I'm not convinced; it at least tells you if the interviewee will rush to an answer that appears correct and say "All of them", or if they'll consider it a little more carefully and say "The rest of them". Or if they'll ask for a strict definition of what it means to pass a chair on the way up, to clarify whether or not you count the chair that you're riding on as one that you pass.
Someone having a strong tool preference and thinking their choice of tool is good enough that it has no important downsides for their usage (and being aware of how to steer around pitfalls) is not automatically an incompetent programmer. Maybe it tells you that they chose their tool thoughtfully, it is a good tool for the usage, and they learned the tool well, and are enthusiastic rather than negative about it.
Most people who think they could improve a language don't have any background in programming languages, don't have a good nose for what would actually be an improvement, and would actually screw it up badly. Having declined to shave that yak for years hardly means that someone is incompetent. Are you interviewing people to create new general-purpose programming languages? Do you often build new programming languages as part of projects? If so, you must miss deadlines a lot.
It's incredible to me how interviewing is in the stone age: some guy gets assigned to interview people because it needs to be done, and how hard could it be anyway? Then he Googles questions to ask, which are more or less arbitrary, and grades them more or less arbitrarily. And the same guy who asks is the one who judges the quality of the question, which is tied up with ego and confirmation bias. Over time, he adjusts to his own taste, but is accountable to nothing else. You get a process which, at best, selects people who are like the interviewer, because the interviewer assumes he is good, so other good people have backgrounds and opinions (and demographics) like his.
It's the same process that 10-year-old boys at a skate park might use to judge whether a new boy is a "poseur." It depends as much on whether the judges think the new boy is like them or dresses correctly or whatever as on any meaningful evidence of ability.
> My favorite question is completely different. "What do you like best about your favorite programming language and what would you change about it if you could?" Anyone who doesn't see any flaws in their favorite language, particularly if it's Java, gets politely shown the door.
What about the poor people who've found a language that they actually like, and understand the tradeoffs that were made? I suspect I recently failed an interview for not having a good answer to that question, but really, what am I supposed to say? If I thought there were significant problems with my favourite language, I'd find a better one.
I once voted -1 on someone for not having a good answer to this one a language that he had used for years. I regretted the vote later, as he turned out to be excellent.
Having said that, it does surprise me that people have a hard time with this. Certainly I hope that you like your chosen language and understand the tradeoffs being made, but that is the point of the question really. Surely you can reason about these tradeoffs and have a discussion in this area? If your language is Java and you talk about how you are ok with their decision on erasure because of the legacy concerns, that's a good answer. I may (or may not) agree, but it's still a perfectly good answer. :)
OTOH, it is strange to me that someone would have worked in a language for 10+ years and literally can't come up with anything that they dislike (even understanding the reasons for those limitations). No matter how good something is, it is hard to imagine working with anything (or anyone) for ten years without coming up with a few pain points.
> If your language is Java and you talk about how you are ok with their decision on erasure because of the legacy concerns, that's a good answer. I may (or may not) agree, but it's still a perfectly good answer.
I wouldn't feel comfortable answering "what would you change about X" with something I actually wouldn't change about X (though maybe I should).
(FWIW my language was Scala, and while I've only been using it for ~5 years there's very little I would change. The answer I gave was to use HLists rather than Tuples in the standard library, but that feels like a nitpick more than anything else)
I don't ask for significant problems, just anything about the language that they would change if they could. A common answer when discussing Java is verbosity, for example.
When I interview for data scientist positions I ask your favorite question, but with "programming language" replaced by "statistical analysis package". (There's overlap between the two sets; their intersection includes Python, with the SciPy stack being what it is now.) I honestly don't care what package they name; it's more a way to get them talking about how they use whatever package they respond with, which reveals quite a bit.
Or, at least, I think it does. I'd love to have data on which interview questions actually elicit signal-containing answers...
You must be stating the missionaries and cannibals problem incompletely. If only one person can fit on the boat at a time (which is essentially the case because you didn't say the person operating the boat is a missionary or cannibal, and you are implying that they must be operating the boat), it's provably impossible to solve. Wikipedia says you may have 1 or 2 people on the boat (as opposed to 0 or 1), which makes it relatively easy to solve as soon as you realize you can take people back that have already crossed.
The correct solution requires that you get out of the boat and put two cannibals on it. The statement that the boat holds "only you" and one other person very strongly implies that is not allowed.
I really like the questions about programming languages. What's their favorite, just favorite language, features, etc. If the candidate says they've only ever used one, or they don't have any features they dis/like, that's a flag. If they point out a feature, you can use it to dive into a deeper discussion about something they say they know about.
Wikipedia [1] describes the cannibals and missionaries problem differently than you do. Particularly, there is no "you" who transports them, there are only 3 Cs and 3 Ms.
I don't really have a favourite. I just go with the one that fits in with the team and if we need to choose one, try and find one that is a good match for the problem domain.
I've used an arguably "puzzle" question that was presented to me in an interview with some success -- the missionaries and cannibals problem. There are three missionaries and three cannibals that you must get across a river. The boat holds only you and one other person. The cannibals on either bank must never outnumber the missionaries on that bank. It's a good question to see if a candidate understands how to apply some basic computer science concepts. It can easily lead to a 30 minute discussion at the white board, with no need to get working code.
My favorite question is completely different. "What do you like best about your favorite programming language and what would you change about it if you could?" Anyone who doesn't see any flaws in their favorite language, particularly if it's Java, gets politely shown the door.