A lot of those puzzles fall into a small number of categories:

• Fermi estimation - how many piano tuners in L.A?
• Church problem - gardeners who may have dirt on their forehead, pirates dividing coins - generally, recursive reasoning about other rational actors
• Discrete Measuring - dividing water or gold or whatever given inconveniently sized measuring devices.

Once you master the solution to one category, all the variations in that category are trivial.

"Freezing up" is precisely the problem; you can solve a lot of these puzzles by following your chain of logic to its end instead of abandoning it when it looks difficult or sketchy.

Whether these puzzles are good for hiring is another matter.

I asked to him to write a certain program on the laptop, using the language of his choice. He chose C++.

He looked up APIs on google and an in man pages.

I'm pretty happy with the program. It's correct, no slower than necessary, reasonably readable. A few minor improvements can be made, and he started to find these before we ran out of time.

Unfortunately he did badly with other interviewers in classic whiteboard situations, so I don't think he'll be hired.

This is the second time I've interviewed this way. I learned that a small task takes much longer to code than I think. Also, that this measures something quite different from whiteboard questions.

Preferred knives? Probably. But I've seen comments from chefs that they wouldn't take their good knives to work, where kitchen help would borrow or ruin them.

"He can do more with a candlestick than most men with a pistol. But he is pretty sure to have the pistol, too."

I run Ubuntu. With every upgrade, they break something and I have to spend time researching it.

Mostly this breakage is someone trying to "improve" things.
For example, pulse-audio. I suffered with it for a long while, then finally found how to rip it out by the roots.

I do not want unix to be like Windows.
I do not want my expectations broken on every release. Let it be. Make it stable.

This is compatible with progress. I want great new applications like Chrome. New apps and libraries don't disrupt the platform. I wish these guys would understand how much of other people's time they are wasting.

I realize that what I'm about to say might not appeal to you. Please try to keep an open mind.

I've been reading Slashdot since about 1999. I've seen a lot of "outrage stories". Stories intended to get your blood pressure shooting through the roof. And they used to work on me.

Remember when Iraq invaded Kuwait? The story was circulated that Iraqi soldiers were taking premature babies out of incubators and throwing them on the ground. Turned out to be a total fabrication, created by Kuwait to get the US into the war. It worked.

Every controversy has two sides. No sane court will convict without hearing both sides. "There are two sides to every beef."

The "outrage story" is always based on giving you only one side. And it works - until you're old enough to recognize it.

Realize that every person who had an unpleasant contact with these border guards could tell a similar story. Only one in a 100 will recognize his own mistake. The majority will claim that he was nice, and the other guy created the problem.

The power to tax is the power to destroy

...and almost any serious MySQL shop uses InnoDB exclusively...

I work at a pretty serious MySQL user, and we use both MyIsam and InnoDB. Properly tuned and used, Isam is faster. Innodb allegedly has the edge in PK-lookups, but my measurements disagree.

Innodb is good if you want Oracle-ish features. Mostly we don't. In fact, the current is flowing the other way; towards things even leaner than MySQL.

We mysqldump the slave, which eliminates that issue. (You can also stop the slave and cp the db files; I think this does not work with Inno). Table locks remain a serious performance issue in Isam; it does take extra effort to prevent lock contention.

Thank you. It still seems to me that the more beneficial part of attr_accessor (automating accessor boilerplate) can be done at compile time.

The term "Monkey Patching" is new to me. If you wanted to (and I shudder at the thought) you could probably apply it to virtual methods in C++ since their addresses are stored in a class vtable.

Within each of the two blocks, the two lines are equivalent; one Perl and one Python. There is no relationship between the two blocks.

Eg attr_accessor. It is a method which, when evaluated by the interpreter generates accessor methods for the names passed in.

I know nothing about Ruby and attr_accessor, but from a quick search this seems to be a compile-time feature. Couldn't you add attr_accessor to a C++ compiler? The compiler would generate the accessor methods.

Perl can be written to be prettier than Python or uglier than anything else imaginable.

Even well-written Perl is noisier than Python.

my $txn = $store->getTxnGroup()->getTxn($txn_id);
txn = store.getTxnGroup().getTxn(txn_id)

Or:

my $ids = [ map { $_->{ id } } @$txns ];
ids = [i['id'] for i in txns]

I still love Perl, but can only think of one place where it's prettier than Python - that's quoting.

I've worked on both good and bad Perl. Perl's sigils are not an issue; neither are Lisp's parentheses or Python's whitespace. These things cease to annoy once you spend some time with the language.

The reason there's a lot of bad Perl is the reason there's a lot of bad PHP: both languages enable beginning programmers to get things done.