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.
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.