Brainteaser questions like those found on www.techinterview.org are things that I tend not to be very good at. I’m probably better than the average population, but certainly many people will wipe the floor with me when it comes to solving these things.
Techinterview is an excellent resource for such puzzles, but I have to admit that some of the solutions simply leave me cold, my eyes glazed over and frankly, I tend to try to recover with Pizza. Often, I’ve not even put that much thought in before cheating and looking at someone else’s solution (and still the eyes do the glaze-over thing).
So why would I consider these puzzle to be a Bad Thing to have in an interview… other than a quite plainly bitter streak that states that if I can’t do it, no-one else should be able to. (See my list of ‘Top Stuff I Always Wanted to be Able to Do‘ which may give you an idea why). OK, so I accept that I might be biased on this because of my own limitations, but I am going to try and argue this one.
Before I go on I should probably also say that I was asked a similar style of question in an interview once, regarding moving a chess knight around a chessboard, visiting each square once and only once). I was assures that it is possible to do this with a full board, but is it possible to do this if you were to remove two squares from the board, from diagonally opposite corners? (see this Dominoes puzzle for an incredibly similar problem). I have to admit, I had to be lead right through before I had the ‘Aha!’ moment. Now, Techinterview rates this problem as mid-range on the ‘Aha’ scale (which probably means they do not use it themselves in interviews as too much ‘Aha’ is bad to see someone work a problem through.
But remember, these are questions used in interviews for knowledge-based jobs, and in the context of this article, for programmers. So what are these problems targeted at? Well, my suspicion is that many of them originate from the very early days of computing… somewhere between Babbage and say, 1985. What am I on about?
Well, some of the puzzles limit your ‘storage’ capacity to, like, two BITS (see the ‘switches’ problem on the site linked to above – link to the discuss site for a discussion of possible solutions) or other arbitrary limitation of information. e.g. Another switch problem:” Three light switches in one room, linked to three tungsten lights in another: With just one visit in each room, how can you tell which light switch activates which bulb?” So here the limitation is the single visit between rooms.
* Warning – A Spoiler for the light bulb problem is in the following text *
I am not denying that there may be some real-world applications that require problem solving like this. But I would think that they are in the minority and honestly, I just think these problems originate from the days where memory was such a limited resource that clever use of storage space etc was a requirement for programming – especially assembler et al. The general consensus now seems to be – if it is easier and ‘safer’ to use more memory-type resources, do it. And hey, you’re probably all right if you use a few extra clock-cycles too. If you can, let the operating system figure out memory swaps and so on (and if you want to program assembler, you made your own bed). The latter switch problem above might leave you with burnt fingers to get a result… ergo, it is safer – and probably quicker – to visit the switch and light room two or more times… so this analogy fits quite well to my mind.
And then there are the probability questions. Well, it might be useful for your team to have a good knowledge of probability, or Game Theory (click for a really interesting site)… even if your work is not specifically about probability, but I suggest this only because (I believe that) the better someone understands probability, the more likely they are to be logical, and hence able to ‘understand’ a computer. Click on the thumbnail below to see a stereotypical comparison:
Bread and Butter
Now, I have to admit, that the programming I have done in the past is not what I would call ‘Rocket Science’. In certain respects, I could even say that much of my professional programming career did not even provide interesting problems. Or rather, they were interesting to me, just not something I will brag about… as mostly they were back-office, behind the scenes, overnight processes (load this file, get that system to talk to that one, and so on, without pretty windows bells and whistles etc.) But what I would assert is that the majority of good programming is about logic, and knowing some of the pitfalls of the task you are working with (like off-by-one errors, possible misunderstanding with the words ‘may be’ in a spec etc)… and often quite complex logic (this or that but not that unless x on Sunday and y the rest of the week). I believe that these problems are the norm where data has to be processed… and you know for sure that most of your time is going to be spent handling those little spec details that start ‘…except when’.
Coding examples may help you understand if the candidate can do some things, but again, the average example may not provide the examples of that complex list of ands and ors.
Perhaps the environments I have worked in have never been that good? I have learnt a lot recently that explains why I found it difficult to code in the several of the offices I worked in. Maybe my coding colleagues were not the best. Maybe I don’t have a good reference point. But, my experience has been that most problems to be faced in the real world are simple if you let them be, and if you acknowledge and document the things where you know that, at 2am, the ‘what the hell does this do’ is not going to be readily apparent.
Speaking only for myself though, I think that the ‘impossible problem’ concept is quite interesting; as long as it is made clear directly or indirectly that it is an impossible problem for which there is no ‘right’ answer, and which you will never be asked to actually implement. First, it should tell you if people are likely to run away at the first sign of a large problem. Second, the sheer impracticality allows for some real brainstorming and I think possibly leads to lateral solutions. It also allows you to check – will the candidate ask me for more specification details?
If there is the slightest hint of ‘reality’ about it, I fear that I for one would be saying or feeling that I didn’t want to work on that project!
Believe me. Programmers are fundamentally lazy. Try getting them to fill in a time sheet. Pointless (I exaggerate). Ask them a stupid question to see if they can solve it. Well, they just might do it, because it’s an interview or hell they’re smart and they love all that stuff. But I reckon most programmers are enthused by those very same problems when, and only when, it is a requirement of the end-product.
Real World Problems
Wouldn’t it be better to ask your candidate questions that focus on your real-world company business? For me, and my history, this is so very different from anything like the standard interview questions as suggested by the average book or web page. I’ll talk about a problem I experienced once in the next article.