A friend of mine who owns a consulting company gave me a great bit of advice about hiring for communication ability. Phone screen all candidates before ever meeting them in person. If they can't communicate well over the phone, their resume goes in the trash.

I would lie and say my favorite soda is Moxie and assuming the state is California I would bullshit some really small number because Moxie isn't availible on the west coast as far as I know.

Hmmm... *searches what puzzle questions are*

Having spent some time working in a hospital I remember being told (many times) the importance of communication and talking to patients (even though I actually interacted with patients only rarely), it's not just the software world, communication is important in almost any career.

I program because I enjoy sitting in front of a computer for 8-16 hours a day relating to abstract problems. Many interviews apparently wanted me to be extremely personable. Did you forget what you're hiring me to do?

It's no wonder that the interview process at many jobs has often given me coworker techies that were good snake oil sales men with little coding skill and coworker salesmen that were good only at selling themselves.

Make the interviewee show you that they can really do the job you're hiring for. More importantly though, use a competent group of interviewers. This would solve most bad hires. You need a small team who can ask the right things and evaluate the responses correctly. People who think they know how to interview just because they're good at a job is the same as people who think they can manage just because they're good at a job.

The silver bullet is not communication. The silver bullet is not puzzle-solving. The silver bullet is not X, Y or Z. Communication is important, but there is no requirement to be a master communicator. Middle-of-the-road will suffice perfectly well. Ditto problem solving. Ditto your particular flavour of language/environment. Ditto everything you want your employees to do. If there's one thing I take from myriad tales of "X was a great at Y, but he was so bad at Z that he was a nightmare to work with", it's that it's breadth of skill that makes a good team member, and that team skills are more important than programming skills*.

Someone with 5s across the board will achieve more than someone a mix of 1s and 10s in a team environment. Sure, you might surge ahead in one area with the unbalanced guy, but your team leader will spend too much time leading the people and too little leading the project, which will inevitably suffer.

*barring, of course, all the ridiculous extremes that the bad team-members are just about to throw out in knee-jerk self-defence :)

"I know, of course, the answer to your hardest question, Mr Interviewer, but I shall give it to you in the form of a riddle:

My first is in stupid, and also in interview..."

There is no silver bullet, a good combo of some of the above will get you on the right track. The best way to hire someone is not to know everything about how to hire a person, but what to AVOID in hiring a person. By eliminating the most mistakes, you'll guarantee a better quality fill rate of personnel.

> although I'm pretty sure that you can't B.S. your way through a technical presentation to a handful of your peers if you truly have no idea what you're talking about. (And if you can, you should be CEO of a startup by now.)

Please don't encourage those with no technical skills to start his/her own startup. I don't like being able to relate to every single Dilbert cartoon...

Good post though!

I ask similar 'impossible' questions to interviewee's because I want to know "what are you going to do now that you dont know the answer?"

Are you going to look more closely at the question?
or give up?
or lean on google for an answer?
what if you google cant find one for you?

I agree that communication ability is a key component,
but so is being able to work your way around problems for which you have no answers.

Is there an answer to the hat question where there's four people and one door on some steps and they can't see their own or each others hats or turn around? I got asked that by some jerk who didn't want to give me a "hard" question.

the correct response to the 'hardest interview puzzle question ever' is, of course, to strangle the sadist who asked it.

One of my favorite questions to ask is "Did you notice anything in particular about our facility when you came in?" (not applicable for phone interviews of course). Its not a pass/fail question, but it gives a little insight into how they think. Out of the 20 or so interviewees for the last opening here, the ones that didn't notice anything also didn't have any programming skills; the ones that said something vague (that parking was a problem) had basic skills; but the ones that pointed out specific things (like the ashtray 50 feet after the no smoking sign) had some l33t skilz. Maybe it's the attention to detail.
The guy who got the job mentioned the ashtray, a car with a flat tire in the parking lot, and the ninja behind the bush.

Regarding the pirate puzzle, the answer is, of course, 42 ;-)

"How much of your favorite brand of soda is consumed in this state? "

It's 7, obviously. I can't believe anyone needs to ask. Sheesh.

Also, I'm not sure the communication issue is the major reason for the difference in nursing quality (it is likely to be a symptom though). Interestingly, the Dreyfus model was developed to explain exactly that skill disparity ie why some nurses are better than others:

https://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition

Look at the novice level and see if it fits those nurses who "ended up feeling like rigid, inflexible proceduralists who didn't care or constantly had to appeal to authority.". Your comment is almost a quote :-)

A better discussion of this is in "Pragmatic Thinking and Learning", which I would recommend to anyone, if only for the chapter on skills aquisition.

Despite the fact that core competency of programmer is ability to stare at monitor for 8-12 hours and produce great code communication is extremely important. Unless you are a lone star in ivory tower, of course.

Programmer does not have to be an uberpresenter, but he has to be able to express his ideas and concerns in consumable form. No matter how great a developer he is if his ideas will buried in his mind forever.

Besides communication is not only about talking. It is also about listening. Ability to talk effectively does not come without ability to listen effectively. And most successful programmers can communicate good enough to present what they have to say and learn from others.

The answers to the pirate thing is easy:

100 prisoners and 3 pirates locked in a room... Anyone else see a numbers problem? Revolt.

I like your interviewing technique. Talking for 10 minutes about something I have worked on, no problem. SONET network from New Orleans to Houston, via oil rigs in the Gulf of Mexico...

Back-in-the-day we used the acronym BONSOP, back of napkin, seat of pants.

I think the answer to the puzzle is that you did not ask a question.

Is that what they are looking for, or did you just come up with something ludicrous?

Jeff I think you're missing a fundamental element of the response to such "puzzle questions". The way in which the interviewee processes and solves the question is important, but the way in which they convey their thinking is the revealing factor!

I've given technical question to interviewees before, and whether they know the answer or not is second to how they go about describing their thought processes, or how they interact with the questioner (me). That's communication, and it's going to come out just as well (and in a more relevant manner) with boilerplate interview questions as with puzzle questions.

Oh. And I don't like soda. Terrible for your health. The number of soda drinkers is probably directly related to the cancer and diabetes rate.

Just FYI :)

This is simple - I don't drink cola (It gives me migraines since I am mildly allergic to the carbonation). So the answer would be "None".

Also, StackOverflow user profile is also a good way to judge talent. Not really but amount of points, but the posts you make and how you answer questions tell a lot about the candidate.

Jeff,a lot of the questions you are complaining about aren't puzzle questions:

How much of your favorite brand of soda is consumed in this state?
how many optometrists are there in Seattle?

These are estimation questions -- they require no trick or special knowledge. They have no 'right' answer since they are process questions. Because of that, I think they are much better than puzzle questions. And I think one or two questions in an interview assessing the estimation skill of an engineer.

That being said, I completely agree with your general point about puzzle questions

Mecki was the first, but I agree: of course, the answer is 42!

Prisoners/Pirates answer: The monkeys are invisible.

42

The culture of puzzle questions at Microsoft has to a large extent faded away. I talk to a fair number of interviewers here and I have not even _heard_ of anyone who uses puzzle questions since the 1990's. I read Poundstone's book when it was published and it seemed terribly dated even then.

Puzzle questions test your ability to answer puzzle questions, which is not a skill that drives Microsoft shareholder value. It might be _correlated_ to skills that do, but why test for a correlate when we can test directly for the skills that do matter? Like ability to design, implement, test, analyze, debug, maintain and document high quality software.

And, of course, communication is key to all of those things, none of them being done solo.

What you have to remember, Jeff, is that nurses may not want to explain to you what they are doing. You the the right to refuse treatment, which is not necessarily in their (and the hospital's) best interest. You are under the impression they are looking out for your wants. They aren't. They are looking out for their employeer's wants, and that is to keep you from causing problems and sueing them. Most hospitals would prefer that you don't ask questions and let them do what they think is in your best interest. Communication with you is not key for them to do their job.

I read this before my morning coffee, and I saw:

>have the candidate give a 10 minute watercolor presentation to
>your team on something they've worked on

Which lead to an entire series of amusing mental pictures of geeks with giant paintbrushes and pastel paints, filling the walls of a conference room with watercolors on those giant Post-It notes, then describing the pictures in haiku for the interviewer.

Like the puzzles, it would certainly be amusing, but not very productive.

It seems to me that every company wants to hire the best, the smartest, the ones with communicative skills, la cr?me de la cr?me. Nobody wants to get down to the dirty business of educating his employees.

But where do these smart communicative guys come from, then? Do you have to be born that way? Or is a smart company not the one that hires the cool guys, but that hires the potentials and makes them the cool guys?

That said, I don't like skill tests in job interviews at all. Test for honesty and attentiveness and everything else can be worked out.

Was it just me or did that insanely difficult puzzle question example fail to include an actual problem? It just describes the situation and asks for a solution, without even specifying the intended result and that's ... well that's something you'd want a PR person to be able to solve. Programmers deal with defined problems.

Personally, if I were asked that puzzle, I'd give the most convoluted possible answer that, likewise, would not contain an actual answer to anything. They would surely hire me for seeing through their stupid game.

Do I fail if I ask what a "watercooler presentation" is?

You solve any puzzle my unzipping and squirting cum on it.

Switzec, If you'd follow the link you'd see that the quoted article starts with "Here is a parody puzzle question..."

Basically problem solving is making the problem go away, and I assure your that if you take my advice and unzip and blow a load at the problem it will go away

I tend to agree that random, arbitrary stuff is kind of annoying, but I have come to understand the point a little more. To an extent, exercises like that just show how creative one can be with limited resources. The interviewer may be more concerned with your approach to solving the problem than how accurate your answer is.

That is correct mr Seth, and nothing shows creativity more than unzipping an blowing a load on the problem

I think i lost a little part of my brain when the monkeys started using prime numbers. :(

Agreed. A 10 minute water cooler presentation would be a great way to assess technical knowledge of an interviewee. Nice write up...

It might be better to have the candidate give a presentation on something he's worked on.

Matthew: "These are estimation questions -- they require no trick or special knowledge. They have no 'right' answer since they are process questions. Because of that, I think they are much better than puzzle questions. And I think one or two questions in an interview assessing the estimation skill of an engineer."

There's a fundamental problem with this viewpoint, though: These questions do, in fact, have a clear and well-defined right answer. There is, in fact, a single number for the amount of $COLA_BRAND soda drunk in $STATE, and a single number for how many optometrists there are in Seattle for appropriate definitions of optometrists and Seattle (e.g., do you count the greater metropolitan area?) However, the interviewer hardly ever knows it, and hardly ever cares whether the answer that the interviewee gives is in fact anywhere close to it, so long as it sounds plausible.

And the thing is, in programming, that it's not enough to have an estimation process that sounds plausible and comes up with a number. Being able to do that is in fact dangerous if the numbers are completely off-base. You'd also like to come up with a reasonably accurate number, and with a good estimate of the uncertainty in that answer.

@Swizec: Please, tell me you're not the Swizec who authored an article called something like "there's no such thing as a stupid user"?

@Will:

Actually, my favorite soda *is* Moxie (look it up, boys & girls), so unless the interview is taking place in New England, the answer is "statistically close to zero".

Come to think of it...that answer might apply in New England, too.

I remember figuring out over a coffee break how many coffee swizel sticks we're likely consumed on a daily basis in Canada.

We figured it was about a cubic meter's worth.

"How much of your favorite brand of soda is consumed in this state?"

I don't drink store-bought, so my favorite "brand" would have to be "the stuff I brew in my kitchen". In the past year, I've made 2 5-gallon batches, so I'd have to say: 10 gallons. Pretty good margin of error on that figure, too. :-)

I once didn't get my "dream" job because they had some mental maths thing that we all had to pass.

I hadn't done the "four fifths of 22 means it's Tuesday" stuff in 20 years and couldn't do it without a lot of practice. If they'd asked me to do a presentation, or some questions about programming and project management I'd have had a fighting chance. I can do most of the programming problems without any prep - been doing it 22 years.

It was also very ageist, I don't do those kind of puzzles. I got my degree (1987) when most of the people in the room weren't even zygotes, if I'd had this kind of quiz *then* I would probably have aced it. I got a very high mark on the Java Certification exam, but that was because I studied for it. There was no way to practice for this kind of thing. In retrospect I'm glad I "failed", because they must be idiots if they think it makes any difference.

Just a lazy way for the Human Resources (erm - I'm a person, hello??) to sieve people and be ageist without appearing to be. If they ask questions like that it's because they have nothing useful to do. Plus it cost me a train ticket to London, and they ain't cheap.

https://www.xckd.com/554/

What i generally dislike about puzzle questions is the ambiguity, some element that you're not told and that you have to assume. It's like being asked 100 questions at the same time.

Assumptions are critical and it's the first thing you try to work out, so being told to assume without consequence... i think it's a little pointless.

How well can you judge someone's thought process given that their assumptions are arbitrary? How much can you take from it?

Good Communication != Good Nurse

I get what you're saying with your recent nursing experience. I also agree that you cannot be an exception nurse (or programmer) without good communication skills.

Having said that, I would much rather have a nurse with sound medical skills helping my when I'm going into cardiac arrest then one who is friendly but cheated through nursing school. Likewise, I would much rather have a programmer with exceptional programming skills design the airbag system in my car and tells the worst water cooler story ever.

In conclusion, "the worst nurses were invariably the worst communicators!" only means that they are bad communicators. Maybe you can conclude that they are not exceptional nurses...

Now, hopefully, I communicated my point well :-)

10 bottles of possibly poisoned wine? Clearly the prisoners are all ninjas.

3 PIRATES VS. 100 NINJAS! All other data is irrelevant.

You could potentially take a shit right there in the interview chair. Maybe just when you get a question you know you can't ace you turn around and pull down your pants and spray them with shit. You know you can get a nice spray if you drink a lot of coffee.

You may think they'll get angry but the people they set to do these things are practically dead inside so they will not react normally they'll break a chuckle.

Try it, interviews is all about showing character and creativity. Stand out!

It's nearly ubiquitous to force PhD level applicants for academic/science positions to do a "job talk" -- a one hour presentation/seminar on the subject of their thesis. After all, the applicant is someone who has just spent years working on one topic, and they ought to have something interesting to say about it.

Having been to many, I can safely say that ten minutes would probably be enough to judge their abilities, but it would be unfair to them to force 5 years of work to be summarized down to such a short presentation.

I guess academics do something right, then, even if they are long-winded about it. :)

Ok ok now I have it. The ultimate combo.

1. Ace the interview
2. Turn around spray shit
3. While turned around prepare dick
4. Turn back revealing the erect dick
5. Spray load
6. Watch jaws drop

If that doesn't make you stand out nothing will.

As someone who poses interview questions a lot (and answers them rarely if ever) I must tell you, they are really important. Until we are allowed to give candidates IQ tests they are the best / only way we have to form an estimate of how smart people are, in the sense of how they think. And the interaction of working through a puzzle together gives you a chance to see how they think, how they problem solve, and how they handle stressful situations.

I like programming related puzzles (how would you model a pool table) and abstract questions (how many pathologists are there in the U.S.). They have to be solvable, by the way; questions which are too hard don't tell you anything. And questions which involve some kind of trick don't tell you much either.

Cheers...

Agree completely about how useful this style of interview question is. I can sort of see why they might be considered useful in allowing candidates to demonstrate their reasoning skills, but it must surely be much more relevant to give them an actual computing problem. Showing a spec and asking how to go about implementing it would demonstrate the same skill sets in a way that would be far more revealing.

But I don?t agree with the 10 minute talk either. Even if you consider communication skills to be the most important trait of a programmer, surely the interview itself will tell you all you need to know about the candidate?s relevant ability. A presentation is an entirely different type of communication, and one most programmers do not need.

They are good for engineering jobs.
The 'trick' ones about telling the color of your own hat or the two guards in front of doors are useless - everybody has heard them.

But the how much does Mt Fuji weigh questions are good. I expect a civil engineer to be able to estimate rock mass and I expect a software engineer to be able to estimate I/O rates or how many clients a server can handle

"Until we are allowed to give candidates IQ tests they are the best / only way we have to form an estimate of how smart people are"

@Ole
My question is do you really think an IQ test would realy show how a person thinks, or how qualified they are for a position.

I think asking questions that are related to the scope of work would give you a better indicator to what skills they have to do the job.

I agree that comunications skills are very important when you hire architect

The answer is Blue. NO! Yellow.

I have a genius-level IQ and I hate with a passion stupid interview questions of the type that Jeff is mocking.

They don't get you anyone except those that are interested in mental masturbation, which is the type of people that they are also given by. But what they DON'T do is further the bottom line.

People that think these questions are good are exactly the type of people that spend weeks investigating a problem instead of just saying, "Oh, well, Microsoft has a bug but we can work around it by adding a </table> tag." And for everyone that just cringed when I said that, realize that your employer usually doesn't care if your website validates as long as it works on the 2 latest versions of IE and Firefox. And he WOULD RATHER that you not spend $10000 of his money figuring out how Microsoft screwed up and making a blog posting about it. He would rather you rolled the website out yesterday so that he can make more money.

A few people (including Jeff) have it right. Computer knowledge is always changing, so why bother testing people on that? What you want to know is:

1. Are they a good person and a good communicator?

No matter how smart or how good a coder someone is, if they are an island that can't communicate, you will end up rewriting their code when they are gone and they will cause friction in the office, because people will always be wary of them and their motives because of the lack of communication (as Jeff pointed out regarding the nurses). Also, you don't want harrassment lawsuits or theft, so try to make sure the person you are hiring has some morals.

2. Can they learn?

This career is all about learning. There are new things coming out all the time. I was actually turned down in a job because I didn't know something that was still in Beta in Visual Studio. That's dumb. It's not that I can't learn the latest Microsoft technology, it's that I haven't been exposed to it yet because it hasn't even come out yet. I've been busy adding value to my employer with solutions that work and are maintainable, not bleeding edge beta stuff that isn't even licensed for production code yet.

3. Past success is absolutely an indicator of future success

Make sure that the person can describe successes and failures in detail. Make sure they know WHY they failed and what steps they have taken since to prevent a reoccurrance. That goes back to learning. Also, listen to how passionate they were about their successes and make sure to find ones where they were involved.

For a technical question, stick to a broad topic not a specific command line option. Command line options can be looked up in 1 minute. Instead, ask them to describe the dangers of SQL Injection and how to avoid it or some other topic that good developers absolutely should know.

And ultimately, hire them on a trial basis of at least 30 days. If they aren't working out (for instance, a person with a Masters in programming asking what comma-delimited is), don't be afraid to let them go quickly, before they waste too much of your company's money.

And before you assume that I don't know what I am talking about, I helped hire most of the best people for a consulting company that has survived multiple recessions and wrote award-winning websites for the nationally-known industry leader in a certain vertical.

And we never used puzzle/IQ questions to do it.

I am a full-time programmer and I find most people who aren't programmers have a tough time communicating with programmers. I'm not a sociable person, but I communicate just fine. Programmers actually tend to be highly effective communicators... to the degree that talking is usually the worst medium to communicate in.

Programming isn't a social practice. It's not a party where people hang out and get to know eachother. That's for college kids and sales people. Programming is a technical field and the best programmers want to be taken seriously as engineers, scientists, and craftspeople. This generally requires a lot of mental effort and discipline in maintaining mental focus.

I find that just employing a few rules and systems to manage communications is the best policy. It lets the technical people work without distractions and it lets non-technical people work with them without having to deal with their eccentricities.

For example, in my work place as policy I make sure that all technical issues are handled by our issue tracker. Nobody is allowed to walk up to my desk or anyone elses and discuss technical issues in face-to-face conversation. Firstly, it's distracting to have someone approach you and force you away from your thought processes on a whim. Second, technical issues are difficult to communicate in person either by misunderstanding or by failure to transcribe every nuanced or implied detail. By using an issue tracker we avoid as many of those problems as possible. The programmers stay happy and the sales/biz people stay happy.

It's a pain for people to get used to (especially the non-technical people), but things work more like a well-greased machine than a series of fumbles and kitchen fires. It's a middle-ground solution that keeps things moving.

Don't expect programmers to be sociable people. Just lay down a good system and a few rules and things will just happen regardless of anyone's social skills.

I have a retard-level IQ and I love with a passion clever interview questions of the type that Jeff is mocking.

Heres one.

You are in an unlit room and placed in front of you are 100 coins. 40 is A side up and 60 is B side up(this is known to you). How can you split the 100 coins into two piles with equal amount of A side up?

allowed actions:
1. picking coins
2. flipping coins

Correct answer is:

Pick out 40 coins and flip them(turn coin upside down).

You probably not smart enough to arrive at that simply shit, so just follow my previous advice!

I interviewed at (and subsequently got an offer from) Microsoft last year and did not have to answer one puzzle question. YMMV.

Congratulation on your new child!!!

"For example, in my work place as policy I make sure that all technical issues are handled by our issue tracker. Nobody is allowed to walk up to my desk or anyone elses and discuss technical issues in face-to-face conversation. Firstly, it's distracting to have someone approach you and force you away from your thought processes on a whim. Second, technical issues are difficult to communicate in person either by misunderstanding or by failure to transcribe every nuanced or implied detail. By using an issue tracker we avoid as many of those problems as possible. The programmers stay happy and the sales/biz people stay happy."

Doesn't sound like a happy place. Of course when I started (late 60's) people managed fine without so many technical appendages. We also had the common sense not to interrupt our fellow programmers when they were concentrating. There were people I worked for (CNO, members of the US House of Representatives) that would've told you what to do with your issue tracker on the way out the door.

Hey Solutionman,
You forgot to split the pile...

Guess you lose.

I love it when arrogance loses...

You have to explain to me how you pick X items from a pile with Y items and don't get two piles; The X you picked and the Y-X you picked from.

I'm no genius I said I had retard level IQ. Perhaps you get 3 piles? Sometimes your intuition is wrong you know.

Reminds me of the famous interview question "why are manhole covers round?". Aside from the obvious responses such as "because it has to fit into a round hole", and "so it has no sharp corners" and "becasue it's easier to fit (does need much lining up)" etc, there's one REALLY good answer. Anyone know what it is?

"Don't expect programmers to be sociable people. Just lay down a good system and a few rules and things will just happen regardless of anyone's social skills."

In my first real job, we had a co-worker that was kinda arogant in a church lady kinda way, inconsiderate of her coworkers, and yes, a lousy communicator. Everyone put up with her though because Michelle was "just being Michelle." Likewise, I have a friend who occasionally invites me to play poker, but I no longer accept because he also invites another friend who is loud, boisterous, negative, and insulting as a rule of thumb. Again, everyone put up with it because that just who he is.

As someone who has always tried real hard to break out of the stereotypical molds that have been placed around me due to my decisions and circumstances, I always find it amazing how many people are willing to not only forgive but encourage socially inappropriate behavoir simply to perpetuate a stereotype.

so it won't fall in the hole, like it could for other shapes.

You're hired.

One of my coworkers was also arrogant. I just anal raped him and said "every time you act that smug, it's up the ass. Got it buddy?" works every time I tell ya.

Fuck this. I'm not going to bother trolling here when Jeff doesn't even bother cleaning up.

Actually, rather than being polite and commenting on the article, I found myself distracted by liking the pirate/monkey problem. After taking it apart for a little while I think it's possible to say it isn't parody (as the link says) and find it solvable. The key, in my opinion, is to dispense with the chaos and recognize that the last statement defines (in a somewhat reverse order) what we may have solved (as preconditions) for us in the problems above. Not having some of the math makes it tricky (should I see significance in reversible primes?), but we're allowed to state our assumptions, right? Assume enough away and it's possible to frame anything.

For example, I might look at how one interprets the actual number of pirates per prisoner, which helps me answer why the rum's gone. This is important to establish, with pirates. More seriously, may as well as recognize that some of the issues are independent (mass/liquid displacement to find poison and coin, river monkeys, and primes with an even leading digit can be separated), and rely on the final case statement to show that IF we assume the required conditions are met for, e.g., "has everyone flipped the switch now," this resolves into what left as the actual puzzle. I.e., I don't always need to know that the monkeys lie, just that it's a precondition for part of another condition.

In the end, I became curious about who's walking the plank. Since I don't know if everyone's a pirate, how many there are, and if this is part of a puzzle I haven't seen, I came up with the need to knock everyone out (then we don't care who's prisoner/pirate/plankworthy) and effect the release. We'll just solve what we can. Bribe the captors with the real coins, get each person catatonic on at least two bottles of that good, clean wine, wake up in the morgue, then (having already rigged the room switches for "party strobe") give the party hats, fake coin, and bad wine to the primates...because there's something "not quite right" about these monkeys and there are WAY too many of them trying to use our escape canoe.

mov loc, mntFuji; ?

I think maybe the reason interviewers like to ask these puzzle-type questions is because they can't handle the technical stuff. :)

Ouch! :)

More useless dribble posted by Jeff.

@Glenn: Don't fall for that "so it doesn't fall in" thing. The answer is "pseudo-anthropic principle". If they weren't round, you wouldn't be able to sensibly ask me that question. Therefore, they are round because they MUST be round in any universe in which you're asking me that question. Big picture, man.

@Jeff: The surgeon is the patient's mother.

Haven't you blogged about this several times? Actually, I think there probably are about 4 topics you've been repeating a lot lately and they all seem to border along the lines of either anti-intellectualism or something about how programming is irrelevant and how all this other jibber jabber is the real fruit.

Dang! WaterCOOLER presentation - I misread that as waterCOLOUR presentation....which I think would be FAR more interesting!!!

Assuming a few points:
- monkeys cannot operate a canoe
- pirates lie

Then:

- Pirates will make all the prisoners walk the plank, that is in their nature.
- First 2 monkeys will sink the canoe, the rest will be angry.
- Pirates will be stuck on the wrong side of the river, and eventually will die from either the poisoned wine or at the hands of the irate monkeys.
- The monkeys will go off looking for bananas.
- In time, the counterfeit coins will be worth something because they will be antique counterfeits, and probably rarer than the real thing.

The most profitable solution is to ignore the pirates, the prisoners and the monkeys, take a GPS position, collect the coins when it's all over.

But I don't want to work for anyone so preoccupied with pirates and monkeys.

I have sat in on many interviews, and given my fair number, and it is a bitch to find out much about people. I tried a technical test, with a list of questions (like "What id the difference between for, do..while and while..do"), but this showed mostly that people studies, not that they did.

The last time I interviewed C++ programmers, I asked them to (gasp) write code and (bigger gasp) design a system. I was amazed how hard people crashed. You may not be able to BS your way through a technical presentation, but you definitely can't BS your way through writing real code!

There were only three questions, which required about half a page of answer each. One required real code, one required some sort of design and one required discussion. I am happy with the ONE person out of 5 that actually could give me answers, and he has turned out to be pretty much what we expected from the interview.

(Note. One interviewee, who was applying for a C++ job, asked if he could write the simple program in Pearl.....)

The hardest interview problems often have the easiest solution:

"Thank you for your time. Goodbye."

The other kind of interview questions that always bugs me is "Give me some examples of how you resolve conflicts in a team". I always struggle to recall the last time I actually had a conflict with my team mates. It is usually implied that if you fail to provide examples, then you are either not experienced in teamwork or you are hiding something that may not be to your favor. In any case, having no particular answer to this question seems to be perceived as something negative.

But on the other hand, can't it be interpreted in a positive way? Maybe I have no answer because I do not create conflicts and I am good at actually _avoiding_ conflict with others? Or if I am a team leader, maybe I just built the team in such a way that possible conflicts are mitigated? Or I am just lucky to work with really nice people?

I responded to a question on this topic on stack overflow a couple of months ago.
What algorithms should every developer know?
https://stackoverflow.com/questions/445425/what-algorithms-should-every-developer-know/445589#445589

Fortunately I have since never had to have a job interview.
But if someone were to give me such a problem/question now,
I would probably come back politely asking the interviewers to
if we could discuss instead, in what ever detail they desire, my qualifications,
and what I know I can do for their company.
And if we could discuss the corpus of my work, my designs for real programming problems
I have solved, and my passion for programming.

How would that go over?
Is that the type of response the presentation of this type of puzzle question is supposed to elicit?
Otherwise, frankly, I'd be insulted.

I just finished a discrete math class, which I was taking for the second time (run #2 was considerably more reasonable). The first time I took it, some of the questions on the final looked a lot like that one.

I have to agree with Kevin's simple answer, "Good bye."

I no longer accept interviews with companies that don't ask for a phone screen first. By the end of the phone screen I try to determine whether I gave the company interviewing me enough information to justify hiring me and that of course I want to take the job. If I can't make those two qualifications I won't accept an interview. This ensures the interview is on point and hopefully nothing more than a rehash of the phone interview, with a show and tell of how I could bring value to the position added on. This enables me to avoid the stupid where do you see yourself in 10 years and other mindless brain teaser questions.

It's not worth working for a company that spends its limited interviewing resources asking you mindless brain teasers instead of verifying how you will bring value to it's bottom line. Those 401k packages and profit sharing plans will be short lived when they haven't hired anyone who can write actual code.

Finding a great job is not about learning how to job through the next set of hoops that HR creates. It is about ensuring that the company you are interviewing with can identify what skills it needs and making sure you have those skills. Last time I checked, knowing the number of gas stations in the country is not valuable to Microsoft writing a valuable OS. Perhaps that's why they ditched the practice.

A site I found years ago "www.asktheheadhunter.com" is excellent at separating sane hiring practices from questionable. I'd suggest anyone with a true interest in how to hire quality people or how to find a job for life to take a look. You'll never try to move Mount Fuji again.

Lehman Brothers asked me a really hard puzzle question about three men in hats standing one behind the other. I didn't get it. The asian lady interviewing me got frustrated, and ended our 30 minute interview session after 4 minutes. What a dumb cunt. I hope she sucks dick for money now.

The moment I read that question about soda I rushed into the comments with "Zero! I don't like any soda, so the exactly right answer is "zero"! And, naturally, there was a lot of answers like that already, and now my day is ruined...

Here's a good answer to the Mt. Fuji question: https://angryaussie.wordpress.com/2007/11/01/pointless-interview-questions/

I hate puzzle questions too. At one point it became fashionable where I worked to post puzzles on the noticeboards outside your office. For awhile mine was:

e = 3
n = 343285878569830523580893306575740679545716377525420211495576158140025012622859413021647155097925923099079654737612551765675135751782966645477917450112996148903046399471329621073404375189573596145890193897131117904297828564750320319869151402870808599048010941214722131794764777262241425485454033215718530614228813758504306332175182979866223717215916077166925474873898665494945011465406284336639379003976926567214638530673609657120918076383271664162748888007869256029022847210403172118608204190004229661711963779213375751149595015660496318629472654736425230817703675159067350235072835405670403867435136222247715891504953098444893330963408780769325993978054193414473774418426312986080998886874132604721569516239658645730216315981931951673538129741677294786724229246543668009806769282382806899640048243540370141631496589794092432378969070697794223625082216889573837986230015937764716512289357860158816175578297352334460428151262720373431465319777741603199066554187639792933441952154134189948544473456738316249934191318148092777710386387734317720754565453220777092120190516609628049092636019759882816133231666365286193266863360627356763035447762803504507772355471058595487027908143562401451718062464362679456127531813407833033625423278394497538243720583531147711992606381334677687969597030983391307710987

What is p and q?

(Oh, and I doctored other people's puzzles to make them unsolveable. At least mine's solveable).

... and I've just messed up the formatting on Jeff's page (sorry :-). In compensation I'll give my response to the Moving Mt.Fuji question, which is (a) how far do you want to move it, (b) how quickly do you want it moved, and (c) how much lithium-6 deuteride can I use in the process?

I hate guessing questions. As a military officer I was trained to never guess. In one of the briefings I was present at, one of the officers asked a bunch of us cadets how deep we thought a stream was in the middle of the map. He listened to a half dozen people and then had us vote on how deep we thought the stream was. Everyone that had guessed a specific depth without any facts was then forced into a front leaning rest position and screamed at by a half dozen officers how they had just killed their entire unit because they f*ing guessed. Lessons like that stick.

Reading some of the comments here, I?m starting to think these questions may have a use in screening. Anyone who reacts like some here to a problem they don?t like is probably not going to have the maturity to handle the problems they are likely to encounter in the company.

About the prisoner/pirate/monkey puzzle; what is the puzzle? there is no actual question in there. Anywhooo... I guess my answer would be between -1 and the size of the collection of (non inclusive)

Solutionman, I think you should start writing articles...
hehhehehehe
But, what jeff says is true and false..
This article isnt going to convince people from not asking the puzzle questions..
becoz some how everyone thinks that those who can solve puzzles can code..

I'd like to think I'd have the balls to say "if you can explain the relevance of that question, sure, I'll have a go at it".

My 1980's programming course interview questions were:

How many piano tuners are there in London?

then

How many of them are blind?

then

Is the Pope catholic?

then

Do bears shit in the woods?

And.. I got the place!

ps I made up two of the above questions.

Thankfully, back when I was applying for jobs potential employers didn't such questions. They were more interested in what you could do, and how cheaply you were willing to do it.

As for Mount Fuji, it's already moving in most frames of reference. To get it to move, one must only wait. But in one special frame of reference, Mount Fuji will never move, no matter what forces one applies.

- Lepto

It would be interesting to here this topic discussed on the SO podcast as Jeff and Joel obviously have polar opposite views.

The more I think about it the more I can see some merit in Joel's point on impossible questions - "Smart candidates will realize that you are not quizzing them on their knowledge, and they will enthusiastically leap into trying to figure out some back-of-the-envelope answer." "Not-so-smart candidates will get flustered and upset.". But I still think it ought to be possible to achieve the same effect within a more relevant context.

Hey Jeff,

A couple of years ago my wife had to have spinal surgery in Miami and we came to the same conclusion about the nurses. We found that the night nurses were invariably the worst nurses, but they were also the worst people. Rude pushy automatons who obstinately moved through their shift so they could go home. They were atrocious. It kind of makes sense because you'd figure the better nurses would move up the ranks to the day shift. The day nurses were always polite and they at least communicated as if they cared, even if they didn't (I couldn't tell).

None.

Interesting. Your recommendation that interviewees give a short presentation on their past work comes right out of Tom DeMarco & Timothy Listers's landmark book Peopleware. In chapter 15 - Hiring a Juggler, they suggest the very same thing. Probably a good idea, but I've never been able to directly apply it in any interview situation.

For interviews I've given, I've never liked the open-ended Fermi questions. They do allow interesting insights into a person's thinking process, but they are too off the wall. There are other ways to approach this.

Although I haven't applied the 10-15 minute presentation idea, you can get some sense of the depth of a person's experience by asking interviewees to talk about some particular aspect of what they've worked on -- what was the hardest code you've written? Tell me about the challenges in the XYZ project? How would you have improved the RST project?

Some interviewees just won't talk. If they can't discourse for 3-5 minutes on some interesting aspect of their work -- they go to the bottom of the pile. If they can't remember key details of some problem they worked on intimately -- bottom of the pile.

One item we did adopt from Peopleware is that we make interviewees code. Part of the interview process is a 30 minute session in which we introduce a moestly difficult problem, and ask them to write code for a solution. The actual code isn't as important as the process of watching them solve it. But, at the very least, we don't hire jugglers without watching them juggle.

I was interviewed for a position at Microsoft and I was asked a puzzle question. Did not answer it, but passed the interview!

Don't forget, if you are going to ask a candidate to write some code, *give them a keyboard* and at least Notepad. NOT a pencil and paper. I hate it when I literally have to *write* out code. That's not how I do it on the job, and I can type a lot faster than I can write. I can't tell you how many times I've had this happen.

For extra "realism" the test should replicate the conditions the candidate would be working in. Full development environment. If you're hiring me for a MS shop, give me Visual Studio with all the trappings (intellisense, etc).

To continue with the juggler analogy, that's like giving the juggler candidate paper representations of balls to demonstrate with, not the real thing. Yeah, you *could* juggle them, but it wouldn't be the same.

congratulations on surviving hospital, having babies is natural, going to hospital can be fatal!

Following your recent bad apple post, I would have thought a way of assessing how the person makes people feel, let's hope your 'Would your team enjoy working with this person?' question answers this.

The problem with presenting with past projects at other employers is those damn company secrecy policies

Really? I'm sorry you feel that way. I think presentation is a terrible way to interview programmers. Communication and Lexical skill while both desirable traits are sometimes mutually exclusive. In fact, I get terribly nervous around presentations, but that doesn't mean I don't have passion for my work. I always document my code well, and always have an eye out to be sure my programs are efficient and readable. My management reviews are always terrific. I just dislike presentation. *shrug*

It's not in the employeers interest what you can do, (by the way is all crap)(because if you get interviewed by the executive, he doesn't understand it anyway), but how cheaply you are willing to do it.
The programming skills aren't important at all, it's your social ability and how you communicate..
If you even can't concatenate two strings together that's not so important (beacause I promise you there are a couple of people calling themselves programmers that hardly can do that).

I am non-native English speaker, too....

communicating! communicating! communicating! communicating! ...

such like developers! developers! developers! ...

I always feel anxiety before using English.. Using foreign language is so difficult.

5 days? That sounds like something wasn't quite right at first. Hope everyone is healthy and well now.

"Really? I'm sorry you feel that way. I think presentation is a terrible way to interview programmers. Communication and Lexical skill while both desirable traits are sometimes mutually exclusive. In fact, I get terribly nervous around presentations, but that doesn't mean I don't have passion for my work. I always document my code well, and always have an eye out to be sure my programs are efficient and readable. My management reviews are always terrific. I just dislike presentation. *shrug*"
Except if you used that as your pitch in an interview, you'd be very likely to succeed. It's clear, concise, and tells them what you consider important in your work. It's great presentation. Maybe you're bettter than you think?

I've never interviewed anyone, but I always thought it would be good to ask the person to play Minesweeper on intermediate mode. Tell them that you only want them to make moves that they are certain about - if they can correctly state that there are no certain moves remaining, that would be considered winning. I think it would work well even if they have never played, to see them absorb a small set of rules.

I have watched many people play minesweeper and you often see people completely guessing, but also people who know a a few tactics, but that would rather guess than work through 5 or 6 squares to get to a square you can be certain about. It shows if a person is comfortable think with all their "register variables" active.

"I've never interviewed anyone, but I always thought it would be good to ask the person to play Minesweeper on intermediate mode. Tell them that you only want them to make moves that they are certain about - if they can correctly state that there are no certain moves remaining, that would be considered winning."

I think I could win it before my first move.

This like the stupid printf questions I had to de-construct back in the 1980's. The questions have no relavence to the job I do (programming) or to any position I would be interested in. I would likily tell them good luck with with their project and leave.

"'I've never interviewed anyone, but I always thought it would be good to ask the person to play Minesweeper on intermediate mode. Tell them that you only want them to make moves that they are certain about - if they can correctly state that there are no certain moves remaining, that would be considered winning.'

I think I could win it before my first move." -- Steve W

You would be wrong :). Windows' minesweeper is guaranteed not to give you a bomb on your very first click. You have a fairly good chance of terminating after that first click, though (especially if you click toward the middle).

I have to say to the military guy: that's kind of a tough difference, because "guessing" -- that is, estimation given imperfect knowledge -- is pretty much central to any field of engineering*. You get real data when it is reasonable, and you estimate when it isn't. And determining whether getting real-data is reasonable is a sort of meta-estimation in and of itself. That's why I think "how many <x> (are there/can there be) in <y>" type questions actually have real, germane relevance. I guess maybe it's the opposite for most military scenarios, but there it is.

The linked article about the guy walking out of the "how would you move mount Fuji" interview tells me two things:

1. The interviewer doesn't pass because the interviewee asked back a question that is really similar in nature. "Why would you move mount Fuji". If you have to be able to answer "How", why shouldn't you be able to answer "Why" with just as much BS. Maybe an eccentric billionaire has contracted your company because the view from his Fuji-facing mega-tower is blocked. Maybe it's a scheme to realign the earth's magnetic field and spin characteristics.
2. But it all turned out okay in the end because the interviewee was too much of an obstinate asshole and it clearly wasn't going to work.

I don't think completely abstract puzzle questions are really the best way to go, and I've never been asked in an interview to answer a question that wasn't either a real problem (even if well-known and previously solved) or just 1 fairly-obvious removed from a real problem, but I guess it does weed out a few people who have their strong opinions strongly held. Still, I wonder how common these people are in the real world, and how many people who even comment about just leaving are really just bluffing and full of anonymous bravado.

As an exercise to the mind, I like puzzle questions. To some extent they really do tell me something about a person, but I don't know that it correlates very much at all to successful developers.

*Yes, I know, not every programmer is an engineer. Some are, and those are the ones that can justify those questions.

"I think I could win it before my first move."

The first square you click on a Windows minesweeper board is certain to be empty. I think the algorithm actually waits for the first square clicked, then distributes the N mines among the remaining squares. This is part your strategy, since you should click a square that gives you the best chance of being able to expand.

Some homebrew freeware versions, like the Palm version, and maybe some linux versions, have the possibility of hitting a mine on the 1st click, but not the original Windows game.

As many of the commentors pointed out, there is no silver bullet. However, there are skills that employers are willing to give employees time to learn and develop during their career.

Communication is one of these, very often, especially for entry level positions.

However, problem solving is (largely) not a learned skill. It is something that is (hopefully) developed within you earlier.

When I interviewed at Microsoft, I answered several puzzle questions but they seemed to be dying out soon thereafter.

One of the more interesting interview techniques I've heard was given by John Robbins: he had people bring in a printout of an example of good code with them to the interview. The subject didn't have to have written the code (could have, didn't matter), but was to be prepared to discuss why they considered it good. It served as a springboard into discussion as well as a glimpse into the interviewee's thought process, without the pressure of having to write good code RIGHT NOW as part of the interview.

Microsoft used to have interviews like that.. not anymore. get a life.1!!

You are recycling these posts. Why do you keep talking about this Mt Fuji stuff? All the comments are the same except for the inane stuff about Minesweeper.

That must be a cultural thing.
In France, I had a boatload of job interviews (most of them unsuccessful, of course, my jobless periods happened, unsurprisingly, in crisis periods like now) and as far I as recall, I haven't had such questions.
From time to time, I was asked some technical questions, or to find as much errors as possible in a small C program (did a good job there) or to write a small C code.

But most of the time, the job interviewers relied on resume scrutinizing, asking what I did at various periods, etc.

Now, we have a 3 months (can be extended to 6 months) period where we can be fired immediately (after this period, it takes 3 months to fire somebody), so if you are blatantly incompetent, if you had bluffed about your experience, etc., it will become obvious and out you are. A loss of time for the employer, but not so much, and I suppose most candidates are honest anyway.

@WordofmouthMike: "congratulations on surviving hospital, having babies is natural, going to hospital can be fatal!"

The 'natural' mortality rate of childbirth (ie, nothing is done to prevent death of the mother) is estimated to be 15,000 in every million births. In Europe and the US, the current mortality rate is 90 in every million births. A few hundred years ago, less than 50% of women survived the birth of all of their (then standard) 5 or 6 children. But hey, who needs facts when you can just add the word natural to everything? https://www.youtube.com/watch?v=UB_htqDCP-s

"The first square you click on a Windows minesweeper board is certain to be empty."

Doh! I guess I don't get the job.

The Soda question is easy ...

I live and work in the UK ...

Soda is called either a fizzy drink or cola not Soda
There are no States in the UK
So the answer is : None

Do I get extra points for lateral thinking ....

@WordofmouthMike: "congratulations on surviving hospital, having babies is natural, going to hospital can be fatal!"

@Schmoo: The 'natural' mortality rate of childbirth (ie, nothing is done to prevent death of the mother) is estimated to be 15,000 in every million births. In Europe and the US, the current mortality rate is 90 in every million births. A few hundred years ago, less than 50% of women survived the birth of all of their (then standard) 5 or 6 children. But hey, who needs facts when you can just add the word natural to everything?

Facts: Women are screened for possible complications for the 8-9 months leading up to the birth, have a fully trained midwife on hand with a complete portable medical kit, and you only an emergency call and a short journey away from a modern hospital (or they would recommend a hospital birth), so a home birth is once again an option....

A few hundred years ago women had no screening, no medically trained midwife, no medical kit, no phone, and no access to hospital... and were often malnourished, a large number died after the birth not during it ....

Whoosh!

Jaster said : "There are no States in the UK "
The UK *IS* a state.

From Wikipedia : "The United Kingdom is a unitary state consisting of four countries: England, Northern Ireland, Scotland and Wales."

So ... I guess you don't get the job.

The simplest way to figure out if someone can program is to ask them to write a small program. During the intervew.

Say: Here's a PC (not connected to the internet), I want you to write a program to (pick one):

a. convert a string to an integer without using the library routine that does it for you.
b. backup every file in a given directory and that directories' children to another directory.

In one book I read, back in the days when I was reading books about how to run a development team, the author said something like "the way most of us hire programmers is like hiring a juggler without actually asking him to juggle in front of you before you hire him."

Other techniques I've used with success include asking a programmer to bring in a program or part of a program she wrote that she was proud of and discuss briefly what it was that she found most interesting. One candidate brought a 1,000 page print out and couldn't tell me anything about it. She didn't get the job.

My wife and I also just birthed our first kid at Alta Bates (your photo of the footprint blanket is the giveaway) and I must agree that the constant flux of nurses is ridiculous. They even send in head nurses just to ask you questions about how good a job the other nurses are doing! You can imagine I had some fun coming up with the answers that I *didn't* give them.

And I have an unrelated question based on the same post. (Reading your segueways between disparate topics is always fun and has often reminded me of William Poundstone, which is *really* funny because today is also the first time I've seen you mention one of his books..!)

The question is about your interview process. My favorite interview is to ask the candidate about a recent project. (No prep time, but also no audience other than me.) I then make up a way to enhance the product he tells me about, and ask him how he'd build that enhancement. It's a new feature, or an optimization, or a public API for the product, or whatever. This seems like a logical extension of your favorite type of interview, so the question is, have you done that before and was it informative?

By the way, the company I know that asks puzzle questions is full of very smart geeks and they ask puzzle questions simply to gauge whether the personality fits -- not to gauge software skills.

Congratulations on your new son and on making my work partners laugh when I showed them his "hello world" message.

"how much of your favorite brand of soda is sold in this state?"

I hate soda and don't drink it. Next!

@Schmoo, thanks for letting me know about this Tim Minchen person. That was great! A lot more informative than this repetitive prattle about Mount Fuji (To put it in the modern dialect of the American teenager "OMG WTF who cares?")

"One of my favorite questions to ask is "Did you notice anything in particular about our facility when you came in?" (not applicable for phone interviews of course). Its not a pass/fail question, but it gives a little insight into how they think. Out of the 20 or so interviewees for the last opening here, the ones that didn't notice anything also didn't have any programming skills; the ones that said something vague (that parking was a problem) had basic skills; but the ones that pointed out specific things (like the ashtray 50 feet after the no smoking sign) had some l33t skilz."

This is so fucking full of bullshit i'm very happy i don't work in your company... Can you make a difference between attention to useless details and ability to grasp detail when you actually NEED it. Actually, forget it, this is worse than that. I could basically say the total opposite, a lot of programmers i know don't notice shit about this kind of things unless they actually need to, because they're using their mind on more important matters.

I so hate those tricky shits about how to be the best hirer anyway ...

@Raph, I agree. That is just pretentious drivel. The kinds of comments I see about hiring programmers are always so strange, moronic, stereotypical, and nonsensical.

I feel asking puzzle questions is a good way to judge candidates with no prior experience. Jeff's method will probably work for experienced programmers. That's how I go about it.

A little bit OT, but relating to interviews -- well, to job postings that might lead to interviews...

My primary coding language is C#. When coding web functionality, I also use ASP.NET, JavaScript, HTML, and CSS. Many job postings, however, require ".NET programming" experience. From the context, it appears employers, or at least the HR departments, think of .NET programming as something other than C#, VB.NET, and ASP.NET. They seem to think that my years of experience with C# and ASP.NET aren't relevant to ".NET programming," even though the job description says, "Create and enhance company web site," or "create/update company application to foobar widgets."

So, what does ".NET programming" experience really mean?

Thanks.

I guess I think a little differently than most developers.

The question about moving a mountain made me think about a couple of Zen parables. In one, the wise man answers "on bucket at a time". This is probably a variation on the story of a monk who comes upon an empty well at the foot of a mountain and, having only a spoon, starts trekking up and down the mountain to bring melted snow to the well, a spoonful at a time. In either case, the story prmpts consideration of the nobility (or foolishness) in pursuing the "futile" cause. In the another parable, the ultimate answer to the question is walk away from the mountain. You can't actually move a mountain, but by moving yourself, you can achieve the same practical result.

The are many other references to "moving a mountain" in various cultures. "Faith can move a mountain." "If the mountain won't come to Mohammed, Mohammed must go to the mountain." In each, the "mountain" symbolizes the impossible, and the lesson of the story is found in the value of attempting the impossible.

There are many things that a software developer could learn from contemplating "moving the mountain". The least of these is how to actually move a mountain. We do that all the time these days, though seldom to any good effect in the end. Admittedly, I have a bias toward mountain meadows and against strip mines. To my way of thinking, the only valid answer to this question is in the question posed by another, "Why would you move mount Fuji".

I have to go now. It is Saturday, and I am spending my weekend getting a website ready for a demo on Tuesday. The site is the product of a two year old project that has meandered through a series of developers without any architectural direction, coding discipline, documented requirements or design, or meaningful software development process of any sort. I joined the project in January. How do you refactor a mess like that? One spoonful at a time...

Interviewers, by and large, seem to be a bunch of useless, unintelligent people, at least the ones who ask these sort of questions. They are trying to look for an easy way out. I have thought about this problem, and come up with the same solution as you have. Ask them about a project they have worked on recently, and tailor your questions to that. Ask what they think went right, what went wrong, what they would do better. Ask about the technologies used, and how they could have used other technologies. Maybe this requires more from the interviewer, they might have to actually think about it, rather than reading something from their printouts. But it might actually stop them getting too bored.

These questions can betray more about the company, especially if it is some small shop.

Puzzle questions suck...

I usually swap puzzle questions with ones that require an answer that can actually be applied to real solutions.

For my team is better to hire a developer with great social skills and good technical experience, than to hire the genius jerk. I have seen projects collapse and sink because of genius-rotten-apple-jerks.

In the end you have to spend more time with coworkers that you spend with your own family. Making sure those guys are likable people is critical for everyone in long therm. Being likable also covers the communication part. Experience has thought us that the main issue in communication matters has to do with trust and not natural communication skills. People how trust each other tend to communicate better regardless of their natural communication skills.

>"Faith can move a mountain."

Actually Faith would have some difficulty moving a mountain all by herself but her friend Michelle probably could, she's a rather, um, big girl.

If I wanted to move a mountain I'd do it the easy way, just move a molehill and then stand back while my wife made a mountain out of it.

Yep, ms doesn't give these puzzles at interviews anymore. But! Puzzle hunts are regularly held. See the old one here: https://puzzlehunt.isetv.com/.

I couldn't agree more! We just laid someone off here - a competent programmer, but he failed to communicate what he was doing, and he couldn't understand the communications of others enough to apply them to what he was doing. His work was completely lacking in context, to the point where he wouldn't realize when what he was doing was actually doing harm to the company (say, taking down a production server to work on code directly on the server.) He asked me for a reference - I told him I honestly couldn't give him a good reference even though I knew he was familiar with certain languages inside and out. He just didn't have the communication skills - the minimum level - to make it in the business world.

@glen

re manhole covers are cast casting a circular shape is not has hard as casting say a square one.

and 99% of BT's Man hole covers arent round

Yes, I know the "really good" reason manhole covers are round. It's because that's the only shape which, no matter how the cover is turned or swiveled, prevents the cover from accidentally falling down the hole.