Earlier quoted context omitted.
It's an estimation problem, and programming is full of estimation problems. How many servers will I need? Will I be able to fit this in RAM or do I need an on-disk solution? How long will it take to go from 10 users to 10 million users, and will I be able to scale the design? You don't need the exact value, just a rough order of magnitude. That's the whole point of the big-O notation. A problem like that is lighthear…
I agree with you, and as such, I suggest simply asking such an estimation problem set in the computing world. It also has the advantage that you can get into discussions of things relevant to computing, like finding out how much they understand about orders of magnitude time like socket communication times to various distances, speeds of disks, etc. One of the reasons I don't like "how many ping pong balls" etc. is t…
If anything, it sounds like "ping pong ball" problems have become cliche. That makes them less useful: it doesn't represent my creativity, and it potentially leads to them reciting rote answers from "cracking the interview" books.
Fortunately, I can come up with a thousand problems off the top of my head. How many letter "e" in the New York Times every day? How many sodium atoms in the ocean? How many people at the Nobel Prize Ceremony?
The more off the wall the question, the more I'm testing how they handle the unfamiliar -- as well as conveying who I am. Which is part of the point. They should be interviewing me as much as I'm interviewing them.