Your feeling about 'brainteaser'-based interviews

Question

...either as interviewer and/or interviewee!

I know lots of people are against them. I'm quite fond of brainteasers (math/CS-based, and I certainly prefer those which don't require any specialized knowledge).

In my line of work, 'problem solving' is quite an important requirement when looking for new hires and I think brainteasers can be a good tool. However, there are a few problems with them:

• it's hard to find an original brainteaser (there's no point reusing over and over again the same brainteasers, as candidates will just get the 'list');
• it's hard to find a brainteaser which is quite 'open', from which a conversation can start with a candidate (I really dislike those which have a 'trick', and much prefer those which have different solutions, extensions,...);
• using one (or more) brainteasers in an interview process tends to take (a lot of) time;
• some people are so much stressed during a job interview that they sometimes even lack the self-confidence needed to just 'have a go'.

As an interviewee, I have to say that being given brainteasers that I found interesting during the interview process is one of the reasons I chose my current employer!

So, what are your thoughts/advice on the use of brainteasers?

Answer 1

These type of questions help test how people think about problems in programming but in a more abstract way. They maybe useful therefore to help understand a candidate's approach to problem solving without any knowledge of any particular aspect of technology.

Answer 2

I'm pretty much against the "why are manhole covers round" or "how many gas stations are there in greater Los Angeles" type of questions, both as an interviewer and interviewee.

I've done a good deal of interviewing and what I've found to be most useful are the kinds of questions where you are digging in to things they've done in the past and ask them to explain and/or challenge them on all of their decisions.

Even if the person did not make the decision, ask them what they would have done and then challenge them on those answers.

You can ask them why they chose to use a certain language, ASMX or Remoting, usage of stored procs or not, hosting a service as a windows service or within IIS, what were some of the reasons they chose to upgrade (or not) to a particular Sql Server, etc. I realize much of that has a Microsoft flavor, but I work in a Microsoft shop. But really, you can do that kind of "investigative interrogation" to go down any path.

It does take a little more preparation on the part of the interviewer sometimes to be able to ask some good questions to ferret out some decision points, but I have found it to be very rewarding.

The reason that I do a decent portion of my interviews this way is because when I was interviewed, some of my best most intriguing interviews went this way. It gives me a chance to explain my thought processes for technology and to show that I'm not dumb because I chose (or would choose) technology X... I have many thought-out reasons for it. This also gives you a chance to see how someone reacts when their ideas are challenged. We don't need anyone on our team to be so proud that they cannot bear to be questioned.

Answer 3

These types of interview questions are more useful if the puzzle lends itself to having the interviewee talk thru their solution. It makes no difference whether they get it right or not, just how they approach solving the problem. Gives great insight as to how they work and whether they will fit well into your organization.

Answer 4

One of the questions I got while interviewing for an internship I found to be really stimulating. The interviewer asked me to list as many algorithms I could think of for finding the first common ancestor of two arbitrary items in a binary tree. He wanted me to think aloud, explain using pseudo-code, and find the time- and space-complexity for each approach. At the end of the interview he asked me to write an implementation in C for an algorithm of his choice.

This kind of question really tests the candidate's problem solving ability, and a bit of theoretical knowledge (big O-notation). It also shows that the candidate can follow through and do the actual coding.

Brainteasers in the normal sense do not appeal to me. There is nothing to learn about a candidate who can solve "rearrange three matches to create four squares"-puzzles.

Take a real problem, and let the candidate follow the problem all the way through, from deciding the best way to solve the problem, to writing a bit of code that solves the problem. Have them think out loud so you can see their thought process, and help them out with subtle hints if necessary.

Answer 5

There are a number of kinds of brainteaser. Having done much interviewing (as the interviewer) at a previous job, Ill tell some of my experiences.

I dislike brain-teasers with 'gotchas'. The '0 because you dont bury survivors' ones. They are disengenious in their phrasing. I'm very doubtful that answering these questions is going to provide any insight into the persons ability to fill the position.

I rarely like asking brainteasers which imply only one correct answer. Very rarely does one have a job in which there is only one way to accomplish something. Software development, for one, has too many shades of grey.

Most often giving the candidate a scenario - something they might expect to encounter in their job - seems to provide the best insight into their ability. If they describe what information they'd need to know, where they might look for it, and what their solution is going to look like, it opens up many avenues for additional questions.

Just on their approach to starting their solution, applicants vary considerably. Ive had numerous approaches including these detailed to me:

• Implement potential solution first, then talk to others in more of a 'give me feedback' stance.
• Ask a lot of questions regarding preferred implementation or solution. (could one assume these people need to have a senior babysit them?)
• Question the particulars of the scenario first (ie: "why is this project written in C in the first place? Shouldnt it be written in ?")

Now as you can see, those sorts of answers lead to many unexpected avenues of discussion. I try not to follow a prescribed interview plan too particularly - if you're getting sidetracked, and the candidate is doing most of the talking, s/he is probably covering an area of interest. The truth can be hard to find in interview situations :)

Answer 6

Here's a joke I heard about this kind of question:

A pilot got lost in the fog while trying to land in Seattle.

He sees an office building and flies by, shouting to someone in the building, "Where am I?"

The guy looks up with a puzzled expression and shouts back, "You're in an airplane!"

The pilot then flies right to the airport and lands. The copilot was amazed, and asked how he did it.

"Easy... I asked a simple question and got a 100% correct but 100% useless answer. So I knew we were right over Microsoft HQ!"

Answer 7

People who enjoy brainteasers think they are a sign of intelligence or real-world problem-solving ability. They are not. Selecting people based upon their aptitude for this activity makes as much sense as hiring people based upon their golf handicaps or number of novels they've read.

Answer 8

all you need to check is the attitude and aptitude ... does he have the attitude to drill down a problem .. does he have the instinct to go after the problem ... if you are interviewing for a dev position ... ask the candidate on debugging .. and how he would solve/find a memory leak etc etc ... shows whether he has hands on or just theoretical knowledge ...

Answer 9

Well, here's one way of looking at it: a large portion of the population hates questions like "how many gas stations are there in the USA?" with the heat of a thousand suns. Is that really the point at which you want to start off your relationship with your prospective co-worker?

The brain-exercise questions that I ask in interviews tend to cluster in two categories:

1. I describe in a rough sketch what we do in our department and which part is the focus of our software development in our team (and sometimes that's as far as we get...). I describe some of the computational problems that we face and ask "given what I've described here, how would you approach this problem?"

2. I always have a marked-up copy of their resume in front of me (see? I've read your resume) and there's usually a school or work project that they can speak to in some detail. As they're describing it to me, there's almost always a point at which I can say "it sounds like you made a mistake there - what about this other case that you haven't explained to me?"

My goal in both of these situations is to start a real substantive discussion. Yes, I'm putting them on the spot but, frankly, they were already there. They're interviewing for a job after all. In fairness, I do guide the discussion if I think things are beginning to stumble - the goal is to talk to each other, not stare mutely waiting for them to guess where the other place on the earth is that you can walk one mile south, one mile west and one mile north and get back to your starting point. Gag.

We both get a chance to talk technically and in detail but we also have a chance to decide "is this a person that I can work with?" and "how do they handle themselves is a somewhat confrontational situation?"

Answer 10

I really dislike them, having said that if you must, it's ok to ask as long as you don't base your decision on the "correct" answer. Meaning, if you are just looking for the thought-process. Also, here's my question therefore: what are you trying to prove?

Answer 11

As others have pointed out, some people enjoy brain teasers and others do not. So, while it might be useful as an indicator of how the candidate would fit culturally, it's less useful to test general engineering capabilities.

Definitely avoid the type with a single "insight" or "twist" -- if the candidate likes teasers then they may very well have coincidentally known the answer before arriving, or even have been given the answer by a fellow aficionado.

I've seen others use the "very complex problem" questions where the candidate can talk out loud (or give them paper & pencil to begin). The problem needs to have a definite solution or particular approach, though. And that seems harder with software than other engineering disciplines, unless you constrain it well.

-

Incidentally, one technique I used successfully for guiding the interviews was:

• Present them with a list of technologies, languages, etc. that we used,
• Asked them to rate their skill in each category.
• Grill them on the top skills.

If they give themselves a "1" in a category you can presume they don't know that skill, unless it's one they know but despise!

Answer 12

I have to say that either a "brain-teaser" or "what is the syntax for" interviews that the most important thing has always been the chemistry created, and if the candidate was fun, excited and willing to help make the place even more fun and proud of the work we build as a team. Are they passionate and active in the community... and do they make me feel more passionate about development and design. If the answer is "Yes" then I don't care how they are interviewed.

To be honest I would turn down an "uber-nerd" developer that has no social skills in a heartbeat over someone who gets us excited about projects and brings passion about organizing and displaying information...

Answer 13

Software building is about coding discipline. It's about teamwork. It's about pro-active attitude.

If brainteaser questions reflects our real life problem, then that's fine, however most of them don't.

I've seen a guy, who is very good in answering brainteaser, writes lousy code. I've also met a girl, who is also good at it, always ask people in the office to play mind games with her :) I am not her supervisor, so I don't know how good she is in programming skills.

It may help, but it shouldn't play a major role in determine competency level of one person.

Speaking of problem solving skills. I would say, for example, communication skill is quite important though. If you know different languages, it's even better, because you can ask your questions in different forums, in different languages (Japanese, Chinese, Russian etc). Those are all problem solving skills. The most important thing is can-do attitude. :) He might not be as smart as some so-called genius, but he will try his best to solve the problems (spend extra time to learn new skills, post questions, etc).