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.

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.

Frankly, the fictional Feynman in the article sounds confrontational and arrogant. Take the manhole question for an example, all the counter questions are either nit picking, or rejecting the value of industrial design. Of course there is a reason for choosing a round shape for manhole cover. Of course there is a trade-off among different shapes.

Please note, I'm not saying the manhole question is good for interview, but it does not mean that we need to be mean and resort to cheap attacks to make a point.

Just like the question of how much water dumps out of the Amazon river per day. Yes, I can write down a formula with a bunch of variables, but there is no way I could justify my guess of what the values of those variables are without some research ahead of time. And in reality, who wants a developer that just starts banging out code without researching the problem domain space first?

In Fermi's case he already knew the inputs such as air resistance, weight of the paper, and of course knew all the relevant math formulas because that was part of his education and job.

Actually, that's exactly what Feynman did in the excellent writeup: https://longnow.org/essays/richard-feynman-connection-machin.... A quote: "For Richard, figuring out these problems was a kind of a game. He always started by asking very basic questions like, "What is the simplest example?" or "How can you tell if the answer is right?" He asked questions until he reduced the problem to some essential puzzle that he thought he would be able to solve."

1. Identifying key assumptions or inputs. You may not know the dimensions of a 747 off-hand but ideally you can come up with a way of determining the number of ping-ping balls GIVEN the correct dimensions as input. That is you can come up with a model that you can plug the right numbers into once you look them up.

2. Clarifying the problem by asking questions and drilling in on requirements.

3. Create a model that you can communicate to others and allows you to make decisions just based on order-of-magnitude considerations. I.e. make decisions under uncertainty.

All of those skills I think are relevant to software engineering and system design. For example, you may need to provision hardware long before you know the exact design of a system. Can you come up with a rough estimate of how much storage you will need? Or at least put reasonable upper bounds on it? How many qps would you expect a system to need to support and does that mean you have to use a distributed datastore vs a single RDBMS?

Ultimately these sorts of job interview questions are designed to evoke a response that can let you demonstrate how you would go about solving/explaining the problem; actually solving it correctly is rarely required or expected. I’d just say having never seen a 747, for purposes of the calculation let’s assume they are 300m long with a 10m diameter etc etc and proceed to do a terrible job of calculating how many ping pong balls fit.

Ok. Do you know how many people it carries? Is it about 10, 300, or 10,000?

And how many spheres of diameter 1 can you pack into a cube of length 1? About 0.13, 1.3, or 13?

What else do you need, seriously?

If someone fights a hypothetical, they're usually being adversarial, confrontational, or just avoiding answering the question, which is useful information in an interview.

Plus money is obviously discrete, while water is conceptually nice and continuous.

    Haha, awesome answer. I agree with you from a business perspective it seems stupid at first. Now I can't come up with a good reason to do this, but let's say I as your Product person have convinced you with enough good reasons that it is indeed a valuable task to fill this 747 with as many ping pong balls as you can. What would you do?

Is this a 747 in it's "raw" state, i.e. no seats, no overhead compartments etc, basically empty fuselage? Am I supposed to fill the wings as well (i.e. the kerosine storage areas? Is the aircraft supposed to be able to fly after this? Do I have to care about the flammability of ping pong balls? Btw. how much do ping pong balls weigh and how big are they again, just to be sure we're talking about the same thing I'm thinking of here?

And the list goes on. This is just the stuff I could come up with in a minute without being in a high pressure interview situation :) One of my bosses once told me why he likes me working for him: You don't say "can't be done" you just ask back "How much can this cost?"

Let's say the answer is that it's still supposed to fly (working software you are adding a feature to), so also no stuffing ping pong balls into wings and such. Ignore fire hazards and such (no edge cases for now, build an MVP). Now a plane fuselage is basically a cylinder. At one end I assume full size but there's suddenly a wall where the cockpit and such is. The other end is more "fun" because the cylinder becomes more narrow. In any case now we are probably gonna have to find a 3D bin packing algorithm for packing spheres into a cylinder, potentially its already implemented or we might need to implement it from some research paper we find but in any case it is probably a solved problem (reinvent the wheel in-house or use a library and be done with it? Is the library good enough? Is it supported or some dude in a basement wrote and abandoned it?). Just like in physics where we ignore some forces sometimes for easier calculations for example we can probably cut the narrowing cylinder into sections of one ping ponf ball width and assume constant diameter for those. The difference this make in the end either doesn't matter (80/20 rule of software development, don't gold plate it, make it good enough) or we assume that any extra balls we "miscalculated" can fit into the nooks and crannies we have ignored anyway because a plane fuselage is not a perfectly smooth tube anyway. Never mind the landing gear and such.

A more interesting problem would be to suppose you needed to float a 747 that crashed and sank in tact. How would you go about calculating the right number of ping pong balls to do that.

Those look like they'd be easier to deal with too though. And in any case a great discussion in the interview can ensue regardless. Which is the point.

Interesting second problem too. So you have a regular 747 you say, which I suppose has a mass I can look up somewhere, we have statistics probably about how much cargo and passenger baggage usually weigh (or maybe these are even available for the specific flight?) and passengers hopefully made it out alive since you said the aircraft was intact and didn't burst into pieces.

Now would come the part of just looking stuff up that I don't know but know is known to man already so you better look it up instead of reinventing it all. Apparently from a quick google I would probably want to know how much the plane's buoyancy already works for us (it definitely sank so there's that, but did it barely sink or did it sink like a stone?) and see how much a ping pong ball wants to float. My guess is that the ping pong balls are so buoyant that we can even ignore their small plastic shell and calculate it as if the plane was directly attached to the needed volume of air to make it float.

The real problem is that the ability to come up with a good napkin math estimate for a technical problem doesn't correlate with the ability to actually do the job to solve the problem.

Ability to estimate doesn't imply engineering/programming skill. You still have to evaluate that part somehow (coding, take home test, github contributions, etc).

It also tells you nothing about the candidate's ability to work with others, under pressure, collaborate in a team, and all sorts of other "behavioural" interview questions.

Once you spent enough time to evaluate someone's behavioural skills, and also their technical skills, you don't have any time left in an hour interview to evaluate their napkin math skills.

I don't think this is true at all. There have been many times where I've estimated numbers to come up with a "scale" number ... which was important in other ways. How many servers are we likely to need? How many connections per second are we likely to see? How much memory is this likely to take up. Depending on the context in which you need to know the answer, estimating a value can be extremely useful. It can point you towards the right "group" of solutions that you should consider.

You realise that that's a very strong (and probably wrong) statement? Those two abilities are obviously distinct, but quite probably positively correlated. So while there are be better interview questions, the answer to this question tells you something about the candidate.

Someone once asked Feynman which way a top spinning sprinkler would spin if it was underwater and water was sucked through it instead of pushed out of it. He got into back and forth debates with other students. He ended up using the universities cooling pond for the cyclotron to actually run the experiment.

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

So if you asked Feynman "How many ping pong balls would it take to fill a 747?" you wouldn't receive a "Why do you ask? What problem are you trying to solve?". Instead you'd find him trying to acquire a large 747 and a whole lot of ping pong balls in order to validate his initial guess.

This man never heard of a Fermi estimate, or encountered one in a problem set.

That's one reason, but from my personal experience interviewing, an even bigger signal is a candidate's attitude to a challenge. I've found that the best candidates tend to be those who 'own' the challenge such that they clearly get excited about solving it themselves, rather than just to please the interviewer.

>Why do you ask? This is a particularly interesting question, as I'd say it's asked by the best and the worst and the best performers, the best looking to solve the underlying problem, and the worst looking to shirk responsibility.

An engineering person would come up with the thought process to their estimate.

A business person might start asking questions about the business needs for trying to fill a 747 with ping pong balls.

But someone trying to get an engineering role should think twice before trying to sound smart and replying in an out of line manner.

[1] - https://www.iusmentis.com/patents/priorart/donaldduck/

Like I've done my entire career. Most of our job is mygyvering crap. Esp for scrubbing data.

"Well, ya, that'd work. And probably what I'd do too."

Next interviewer really grilled me about parsing and spam detection. For a UI job. When I explained some of the grammars I did write, for a hobby project, this "bar raiser" dismissed the effort by saying "well, that's nothing, lex/yacc did all the work." (To my overlasting shame, I sarcastically replied "Ya, and my compiler writes all my code too.")

Next interviewer, the engineering manager, grilled me, repeatedly, about how I'd choose between two options, using his current dilemma as the example. (Because apparently I was interviewing to replace him.) I related my prior experiences, eg satisficing. Not good enough. Try both options? Nope. Take a vote? Naw, that'd be too adversarial. Flip a coin? Oh, please, that's not rational.

I didn't get the job.

This is fine as long as you understand that it's equivalent to walking out of the interview right then and there.