I interviewed for a QA position at (Deleted to protect the guilty) where I had to answer a bunch of brain teasers like this. I always prepare thoroughly and even enjoy solving these sorts of puzzles, so I knew most of the standard ones by heart and did fine. I would say that about half of the people who interviewed me did not appear to have the mental acuity to answer such questions themselves. I did learn some new and interesting puzzles though!
Two months later I was hired for what turned out to be an excellent software development position at a completely different organization.
When I interview technical candidates, I ask a pair of related questions that encompass data structures, sorting, and time complexity. It is a very simple-sounding problem. The good candidates get the questions almost before I finish asking, and the mediocre candidates struggle.
The idea behind the questions aren't bad. The point of the questions is to see how someone works through a problem. Even if they can't figure out the answer, the way they try to work it out is what is important.
However, a few of these questions have been used so much they have become cliche. Rather than test how someone works through a problem, they merely tell the employer if the candidate has heard it already. Any employer who asks any of these questions is lazy, plain and simple.
The problem is that most of the type of questions are "tricks", they require you to come up with a specific insight (or maybe do a little algebra in your head).
Asking someone to do this on demand in an interview is iffy; in some jobs I'm sure that sort of puzzle solving is needed, but for most I find it a lot more apropos to ask them to do something related to the job. E.g. to attack a design problem, where I will indeed be looking at how they work through it.
Especially so, I think, for the title question- where do you bury the survivors? I can't say for all the questions, but that one deliberately misleads and misdirects the listener. That's why it works as a joke.
Could be useful to see if they can be distracted or misled, but it sure doesn't check for intelligence/insight.
Am I understanding correctly that this is satire to Microsoft style interview questions? Pointing out they this style of question is less important that the ones he gave examples of?
I agree. I think it would have been even better had comments not be allowed, so the piece could stand on its own as a whole. It sort of reminds me of the tech industry's version of Dadaist poetry.
(The reason why manhole covers are round is obvious - because manholes are round (which also happens to have additional benefit of not allowing cover to fall into manhole). So the question is why manholes are round?)
Manholes are round because of the same reason most wells with brick walls are round - less material is required to support pressure trying to collapse the shaft. I.e. given that manhole needs to reach the same depth, it will be cheaper to have round shaft than, lets say, square, because round shaft walls can be thinner, but still support required pressure.
Surely if it makes sense to have manhole shafts be round, and it also makes sense to have manhole covers be, say, square (for whatever reason), then manhole covers would be square, no?
1) Covers also can have hinges, so training of personal may be not even required.
2) It's unclear that round cross-section is the most convenient for humans to climb, after all humans in horizontal cross-section are like elongated ovals, so rectangular shape could be better. :)
A cover in the shape of a reuleaux triangle still wouldn't fall into the shaft, but also wouldn't roll away--it would have constant width, but its center of mass would move up and down while rolling. Apparently the UK has superior civil engineers.
In modern US cities there are a lot of different manholes, mostly round and rectangular - some shafts don't go deep, so there is no need to make shaft round.
I wonder what kind of shaft is under triangular cover, why would someone build triangular shaft? :)
Two months later I was hired for what turned out to be an excellent software development position at a completely different organization.
When I interview technical candidates, I ask a pair of related questions that encompass data structures, sorting, and time complexity. It is a very simple-sounding problem. The good candidates get the questions almost before I finish asking, and the mediocre candidates struggle.