L’esprit de l’escalier

L’esprit de l’escalier is the inability to respond until it’s too late to bother. Perhaps not until you’ve reached the bottom of a staircase, having had an altercation at the top. You’re most likely to have experienced this if you are at all introverted and have been to a job interview, having only managed to find solutions to simple problems once you find yourself alone on a train full of strangers. The more I ponder the psychology of this phenomenon, the more it fascinates me.

Some programmers dread brain teasers, claiming they are irrelevant to the job. I think this is wrong. In reality, so-called brain teasers are valid tests for application developers because they tend to be questions about programming translated into some other – admittedly, often fanciful – domain. They measure your ability to interpret requirements. I think if you try to assess this in person, the outcome often depends on personality types.

Unwrapping the Riddle

Here’s an odd puzzle with a programming question hiding somewhere inside it.

There are 64 bottles of wine, and one is poisoned. In three days’ time there will be a banquet and you must make sure none of the guests are poisoned. The poison takes between two and two-and-a-half days to kill a man, but you can risk the lives of as many of 32 prisoners as you like to find the poisoned wine bottle. What’s the smallest number of prisoners you can use to find the poisoned bottle?

You may have seen this puzzle before and get out of jail free, and many websites exist to allow people to research these problems for a reason. But, phrased another way, you are actually being asked a simple programming question:

A 64-bit integer has a value equal to a power of two. Find its logarithm in as few steps as possible.

OK! Simple! Only one bit is set, it just needs to be found. The logarithm is the number of zeroes less significant than the bit. The set bit is either in the top half or the bottom half, so test this recursively. We can find the index of the bit by using a sequence of independent bit masks, incrementing a counter differently for each mask which intersects with the value. The code is very simple:


  private static int indexOfFirstBit(long value) {
    int index = 0;
    int temp;
    if ((value & 0xFFFFFFFF00000000L) != 0) { 
      index += 32;
      temp = (int)(value >>> 32);
    } else {
      temp = (int)value;
    }
    if ((temp & 0xFFFF0000) != 0) { 
      index += 16;
      temp >>>= 16;
    }
    if ((temp & 0xFF00) != 0) { 
      index += 8;
      temp >>>= 8;
    }
    if ((temp & 0xF0) != 0) {
      index += 4;
      temp >>>= 4;
    }
    if ((temp & 0xC) != 0) {
      index += 2;
      temp >>>= 2;
    }
    if ((temp & 0x2) != 0) {
      index += 1;
    }
    return index;
  }

The idea is that you keep halving the size of the problem, and add the width of the zero part of each mask that passes (counting from the right). This can be rearranged but the code above is most obvious. You may even recognise that this is equivalent to the x86 instruction TZCNT, which in Java is accessible via the intrinsic Long.numberOfTrailingZeros.

So, going back to la-la land, you only need to risk the lives of six prisoners. All you have to do is ask each of the six prisoners to drink half of the bottles, the first one drinks from the first 32 bottles, the second from the first 16 and the third 16, and so on until the sixth prisoner who drinks from every other bottle. Before three days are up, up to six prisoners will die. If prisoner one dies, you know the poisoned bottle is in the second half. If prisoner two also dies, you know it’s in the third quarter. If the sixth prisoner doesn’t die, you know the poisoned bottle is one of the odd numbers.

Psychology and Interactive Problem Solving

Some people have seen these problems before, others enjoy solving them collaboratively, others instantly recognise solutions. Why does this only come to mind on the train home for some people? Well, it could be stupidity, but I think it’s purely psychological. You may be the sort of person who doesn’t want to solve a problem, even a simple one like this, interactively. Perhaps it feels invasive to reveal your precise thought processes to someone you just met, and aren’t sure you like yet. You might find you take your work with you on walks, or come up with your best ideas in the shower. In short, you may just be an introvert.

There’s a darker side to this psychological cause of failure. You may find that your interviewer is actually an interrogator, is trying to insult your ego, and you’ll feel drawn to defend yourself. The more you defend yourself, the less you can commit to a logical thought process; you become emotional. Your thoughts become jumbled as your emotional defence takes over. You focus on how you are being judged, that you were being judged five seconds ago and still haven’t solved the problem, that you are being judged yet more harshly now. You aren’t actually thinking about the problem at all any more. You aren’t being tested on your ability to solve the problem, but on your ability to solve the problem and defend your self esteem at the same time. Some people fail at this.

I actually think this is fair game in many cases. For instance, if you want to be an Army Officer, you can’t get flustered and be allowed to be thrown off your game like this: people might be shooting at you! For programmers, however, I’m not sure. Most programmers are used to the feeling of being in “flow” – the feeling of being immersed in the task at hand, knowledge instantly accessible. There’s never another person there when you’re in flow. I suppose a programmer in flow is a lot like Schrödinger’s Cat – you destroy it just by interacting with it.

1 Comment

  • Michael H says:

    I just surfed onto this blog after doing an online programming test (HackerRank) for a job interview).

    The test was 90 minutes with three questions. One SQL question, two freestyle coding. None were particularly hard. I finished both coding questions in about 30 minutes total. The rest of the time was spent on the SQL query. In fact, I had the query basically correct after 5 or 10 minutes, but there was one component which I couldn’t get right. This is what I spent the majority of the test time on. I never got it right, though.

    Within minutes of the time expiring, sure as the sun will rise, I realized my obvious mistake. The correct answer was so simple – I needed only to put an ‘and’ after a keyword I had already used in the query. No complicated subquery or obscure aggregate functions needed.

    I’m sure there’s a psychological explanation of why our minds get trapped in a box we can’t think outside of until we’re removed from the situation. I’d be interested in reading if there’s some technique or method to break out of that. It wouldn’t be useful in casual conversation or in the scope of individual interview questions, but it happens a lot with things like testing and debugging.

Leave a Reply

Your email address will not be published. Required fields are marked *