I'd decline any job offered by an organisation that asked these questions.

Mmmm .. and they'd probably be OK with that, because how you answer the answer (or walk out of the room) is part of your answer.

An interview happens on many levels -- there's the basic, "Hi, How are you, ..." level, there's the technical level, and there's also the meta-technical level. For me, the meta-technical level is the most interesting -- sure, you know how something clever works, but can you explain it to someone so that they understand? And why was it necessary to do it that way? Can you explain your thought processes out loud as you go, so that your interviewers 'get' how you approach a problem? (In my most recent interview, I proposed a solution to a regex problem, was asked to explain it, started my first sentence, said out loud -- "Wait -- that won't work", paused, then proposed a second, different solution. Apparently, that approach works.)

This meta-behavior also helps them understand how you may well behave when you get stressed our doing too many things -- My response used to be to bark at people (don't get into that habit -- it upsets them), but now I look them in the eye and say "I'm in the middle of an emergency right now -- is your problem more urgent?" and wait for them to explain. I make a point to follow up a few minutes later, once my emergency is over, and deal with their emergency.

The first couple were OK, but after that, you're just trying to catch the applicant out with trick questions involving code that they'd be sacked for if they used it in production code.

I really don't think anyone gets the boot as a result of a code review. It has to be a combination of many factors, all pointing to the breakdown of the employer/employee relationship.

There shouldn't be any 'tricks' involved in interviews -- it's an exploration into whether there's a the basis for a good relationship, based on mutual compatibility. But if someone has (unwisely) labeled themselves as a 'Perl guru', I guess they should expect a few of these tough questions.

Did you read the whole post? In the interview, the questions were posed as starting points for discussion, not as a pass/fail trick quiz. And that completely changes how I for one react to them. I'd say there are plenty of valid reasons for finding out what a candidate thinks about code like these examples!

My reaction to an interview along these lines would be:

1. Answer the questions.
2. Discuss why tricky code like that is bad, how I would refactor it, when and why I might choose to document rather than refactor, and the value of coding standards in preventing such code being written in the first place.

I'd make my decision on whether it was a place I wanted to work based on how the discussion went, not the questions themselves; and I'd hope the interviewer would judge me likewise.