Monday, October 31, 2005

Will Solve Brainteasers For Food

Are "brainteaser" questions useful in an interview?

For those of you who like brainteaser questions, let's solve this one.

Brainteaser #1: If a candidate is asked a brainteaser question and answers it correctly, what have we learned about the candidate?

Possible options are-

  • The candidate loves brainteasers and has heard it before

  • The candidate has interviewed at a lot of companies that use brainteaser questions, and has heard it before

  • The candidate got lucky

  • The candidate has the kind of mind that is good at solving brainteaser questions


It is difficult to a priori determine which of the above options applies to a specific candidate. I'm not aware of any empirical data that could provide a distribution of probabilities, so it is not even possible to apply a factor to a group of candidates. Given this, it would appear that I haven't learned much useful from a given candidate providing a correct answer to a brainteaser.

"Ah, but I'm smarter than that!" you say. "I make up my own brainteaser questions, and they don't have a 'correct' answer per se. They force the candidate to elaborate on 'how' they might solve the problem, so they can clearly be used to assess the candidates thinking skills. Options 1 thru 3 above don't apply to *my* questions."

Congratulations, you must be very proud. So let's assume that this is true, and you can clearly categorize the candidate as falling into option 4, having the kind of mind that is good at solving brainteaser questions.

Brainteaser #2: Is this a useful skill for the job for which you are interviewing?

Let's take a side tour to explore this question. I'd like to relate an anecdote regarding two software engineers, Pete and Repete. One day, we identified the need to introduce a memory cache at the server for some rarely updated but complex data in order to boost performance. Because we were working in a distributed server architecture, we knew we also needed some cross server way to invalidate all the caches if the data in one of them changed. There were a few more requirements, but that was the gist.

Pete was excited - this was exactly the kind of software problem he liked to solve in school, and immediately went off and started designing an elegant solution. Repete left the meeting and thought "I bet we're not the first people to have this problem."

The next morning, we met again to discuss the options for solving the problem. Pete had been up most of the night, which we could tell because he came in with a haggard look and a Grande Supremo Espresso (as well as wearing the same clothes as yesterday, but this wasn't uncommon for Pete and we had to use other clues to tell he hadn't gotten much sleep). But nevertheless, Pete looked triumphant, waving around some papers, saying "wait till you guys see this design - it is sweeeeeet!" He immediately launched into a 45 minute spew of whiteboard mania. While we found a few questionable areas, the design looked decent, although it was probably going to take about 4-5 weeks of work to get the first cut.

At the end of this, Repete spoke up to state that he had done some Googling yesterday and had found a couple of open source solutions that did most of what we wanted. He had downloaded two of the most popular, and had gotten one of them working. "Anyone want to see a demo?" Repete proceeded to fire up two servers and demonstrate that the new caching mechanism both gave us a 60% reduction in request response times (after initial caching), and that the cross server invalidation worked. "I'm thinking we can tweak the open source code a bit to make the invalidation a little smarter so we don't need to completely rebuild the cache, but it's pretty much there."

Pete looked like he was going to cry. He spent a little while explaining that his solution was more elegant, and was already smarter about cache invalidation. But as the decision maker, I went with Repete.

Now, Pete has always loved brainteasers. He uses them regularly in his interviews. In fact, Pete had recommended against hiring Repete because he didn't get one of Pete's brainteasers in his interview. I'm glad I have both Pete and Repete. Pete can solve some interesting problems, particularly some complex bugs that arise. While this is only about once every 3-4 months, it is definitely useful on those occasions.

Repete, however, is my most productive developer. He reguarly comes up with emminently practical solutions to most of our development challenges, putting out working code in usually half the time we estimate.

Brainteaser #3: If you had to choose, who would you pick for your team?

Oh, wait. We haven't solved Brainteaser #2 above yet, which was "is demonstrating an ability to solve brainteaser questions a useful skill for a software developer?"

A random sampling of opinions tend to come down in these categories:
  • Yes

  • No

  • Sure, but only one of a number of useful skills a developer must demonstrate.


I don't have any empirical data regarding the distribution of opinions across these options, either. However, given that 2 out of 3 indicate that a lack of correct answer to a brainteaser is *not* a disqualifying event in an interview, it might be worthwhile to spend the significant portion of the interview on some other qualifying questions, rather than brainteasers.

0 Comments:

Post a Comment

<< Home