He doesn’t answer the question ‘how does a train stay on the track’ with ‘some trains don’t’; he doesn’t switch to talking about rollercoaster trains and insist that the way they stay on the track is with horizontal wheels. He finds the logical, geometrically satisfying answer quite delightful.
And in fact, in many cases the flanges which he says are just for safety and aren’t supposed to impact the track because otherwise they make a terrible sound… are expected to hit the track to help the train make it round particularly tight turns. Coming from New York and having ridden the subways you’d think Feynman would know there are some corners subway trains take where the flanges rub all the way round, and the lovely conical wheels aren’t what keeps the train on the track at all.
So I definitely find this a weird characterization of a Feynman-ish approach to this kind of problem. I think he’d probably have delighted in the geometric neatness of why circular or triangular manhole covers can’t fall down their holes, and been happy to ignore the practical fact of square ones for the sake of a good puzzle story.
But "why are manhole covers round?" is not. It's a stupid "have you ever heard this clever fact" question that's often designed just to figure out if you're clever and/or lucky vs testing actual knowledge and skill.
If your aim in interviewing is to fill the team with people who love being clever then it's a great technique. But in my view, it's better to interview for the skills the job requires.
That said, I agree 100% with you about "trick" questions. It seems some people cannot distinguish between "market sizing" (Fermi problems) where you need to make reasonable assumptions and describe a model of something, and "a man is found in scuba gear in the middle of the forest" brainteasers for kids. I have no idea why anyone asks brainteasers in an interview.
I personally didn't understand what these types of questions would accomplish, but your explanation makes sense and it seems like this would be a good tool in the hiring toolkit.
I'll go one further - interviewers doing Myers Briggs Personality Tests.
I once had this interview question, gave them the expected answer, and cited the source of that answer. I never did get that job.
I am going to take your claim a step further and assert that this type of question can only reliably test cleverness if the interviewee is properly primed (e.g. there was a prior discussion of workplace safety), then the important thing is explaining why. Otherwise the only way to arrive at the answer is to realize that construction/maintenance workplaces place a high priority on safety. That isn't the type of thing you're likely to think about during an interview for a programming position.
Highly recommended.
Then talk about a real problem, for chrissake.
You're forgetting that you're "interviewing" someone who not only cranked out supercritical calculations for the first atomic bombs - but the first working models for path integral calculus in QM, and so much other stuff.
And you're asking him about... ping pong balls and 747s?
Granted, your average dev doesn't get to do work quite as interesting as what Feynmann did. But still, if they're senior-level - and especially if they're at least reasonably good - then there's a 99 percent chance they can easily whip out 5 or 10 "end-to-end" problems that they've solved for which the guts were much, much meatier than those of...
Any of these jerk off problems that it used to be almost de riguer for interviewers to ask, a few years back.
Fortunately this practice is starting to fade from popularity, but unfortunately, not quite fast enough.
The question is meant to gauge whether you can create a simple model of a system that is completely foreign to you, but for which you are familiar with the fundamental rules governing it. The absurdity of it serves to remove bias. You don't have to worry about whether or not the candidate happens to have experience filling airplanes with ping pong balls. So much of effective programming is creating a model for the processes we are trying to automate. Coming up with effective abstractions uses many of the same skills.