If Richard Feynman applied for a job at Microsoft (2002)
sellsbrothers.com
sellsbrothers.com
Why do you ask? What problem are you trying to solve?
We want to understand your thought process
I'd think it was stupid to fill a 747 with ping pong balls and think about something else
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.
This man never heard of a Fermi estimate, or encountered one in a problem set.
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.
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.
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?
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.
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.
This is fine as long as you understand that it's equivalent to walking out of the interview right then and there.
[1] - https://www.iusmentis.com/patents/priorart/donaldduck/
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.
Highly recommended.
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'll go one further - interviewers doing Myers Briggs Personality Tests.
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 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.
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.
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.
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.
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.
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.
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.
However, if this were the only consideration, you could get a wider-diameter manhole with a smaller cover by making it in the form of an equilateral triangle, as evidently Nashua, NH, does: https://en.wikipedia.org/wiki/Manhole_cover#Other. Indeed, you don't need to stop there; if you curve the sides of the triangle in toward the center, you can get a manhole with an even smaller surface area for a given diameter, although at some point the extra "diameter" will be too curved to be useful.
it's not your job to consider it in full context and give the globally true answer (as feynmann attempted here). it's your job to be cleverer than the interview, perceive what they want to hear, and tell it back to them in a way that maximizes the score they give you on the interview.
The reason you do that is it directly impacts the size of the job offer they give you if you answer questions exactly the way you want to hear. It's eminently rational, and a form of social engineering. Once you're hired you can advocate for change from within *
* I tried to get google to change many of it's stupidest hiring practices for years but it was tilting at a windmill
It is like asking why milk is sold always in yellow box. The question makes no sense, because milk boxes can have any color.
Like that, but for tech interviews.
"... the theory that those who scored too high could get bored with police work and leave soon after undergoing costly training."
I must be a genius. I'm sooo bored at my software dev job.
https://abcnews.go.com/US/court-oks-barring-high-iqs-cops/st...
https://www.youtube.com/watch?v=j_1lIFRdnhA
Maybe you need a promotion.
Pilots as well, apparently.
https://news.ycombinator.com/item?id=1866629 (I dug up the actual passage from the book, so you can read it)
https://www.amazon.com/Feynman-Lectures-Computation-Frontier...
There were building massively parallel systems back in the 80s. Literally thousands of parallel processors, but each processor was only a single bit machine with an incredibly primitive ALU and little else. Or maybe it would be better to think of them as the first GPU builder, at least 20 years ahead of their time.
The original PDF is at https://www.unz.com/PDF/PERIODICAL/SaturdayRev-1968dec21/62/, which is includes a nice drawing of the student speaking with a building superintendent while holding a barometer, but to say more would be to spoil the punchline. Here is the text:
> Angels on a Pin By ALEXANDER CALANDRA
SOME time ago, I received a call from a colleague who asked if I would be the referee on the grading of an examination question. He was about to give a student a zero for his answer to a physics question, while the student claimed he should receive a perfect score and would if the system were not set up against the student. The instructor and the student agreed to submit this to an impartial arbiter, and I was selected.
I went to my colleague’s office and read the examination question: “Show how it is possible to determine the height of a tall building with the aid of a barometer.”
The student had answered: “Take the barometer to the top of the building, attach a long rope to it, lower the barometer to the street, and then bring it up, measuring the length of the rope. The length of the rope is the height of the building.”
I pointed out that the student really had a strong case for full credit, since he had answered the question completely and correctly. On the other hand, if full credit were given, it could well contribute to a high grade for the student in his physics course. A high grade is supposed to certify competence in physics, but the answer did not confirm this. I suggested that the student have another try at answering the question. I was not surprised that my colleague agreed, but I was surprised that the student did.
I gave the student six minutes to answer the question, with the warning that his answer should show some know- ledge of physics. At the end of five minutes, he had not written anything. I asked if he wished to give up, but he said no. He had many answers to this problem; he was just thinking of the best one. I excused myself for interrupting him, and asked him to please go on. In the next minute, he dashed off his answer which read:
“Take the barometer to the top of the building and lean over the edge of the roof. Drop the barometer. timing its fall with a stopwatch. Then, using the formula S=1/2at^2, calculate the height of the building.”
At this point, I asked my colleague if he would give up. He conceded, and I gave the student almost full credit.
In leaving my colleague’s office, I recalled that the student had said he had other answers to the problem, so I asked him what they were. “Oh, yes,” said the student. “There are many ways of getting the height of a tall building with the aid of a barometer. For example, you could take the barometer out on a sunny day and measure the height of the barometer, the length of its shadow, and the length of the shadow of the building, and by the use of a simple proportion, determine the height of the building.”
“Fine,” I said. “And the others?”
“Yes,” said the student. “There is a very basic measurement method that you will like. In this method, you take the barometer and begin to walk up the stairs, As you climb the stairs, you mark off the length of the barometer along the wall. You then count the number of marks, and this will give you the height of the building in barometer units. A very direct method.
“Of course, if you want a more sophisticated method, you can tie the barometer to the end of a string, swing it as a pendulum, and determine the value of ‘g’ at the street level and at the top of the building. From the difference between the two values of ‘g,’ the height of the building can, in principle, be calculated.”
Finally he concluded, there are many other ways of solving the problem, “Probably the best,” he said, “is to take the barometer to the basement and knock on the superintendent's door, When the superintendent answers, you speak to him as follows: “Mr. Superintendent, here I have a fine barometer, if you will tell me the height of this building, I will give you this barometer.’”
At this point, I asked the student if he really did not know the conventional answer to this question. He admitted that he did, but said that he was fed up with high school and college instructors trying to teach him how to think, to use the “scientific method,” and to explore the deep inner logic of the subject in a pedantic way, as is often done in the new mathematics, rather than teaching him the structure of the subject. With this in mind, he decided to revive scholasticism as an academic lark to challenge the Sputnik-panicked classrooms of America.
But the pressure of a vacuum is 0, so unconventional means would be required, if it were worded that way.
Use the barometer to prop open the door to the city's municipal building as the last person leaves for the day & sneak in to find the plans for building.
When leading an interview, do you know how hard it is to tease out if someone is a creative thinker or just a bullshitter? Very hard. You come at it from multiple angles. Sometimes you need questions like this, it is part of the interviewing toolkit along with coding examples, and domain-specific challenges.
EDIT: And sometimes you just need to hire a drone that will follow orders and not think creatively: just implement the spec as-is. WHy? because tech needs all sorts of skills. You don't need (and can't manage) a team of Feynmans. It would be crazy, his ego was huge.
While I get your point and have been in a similar position myself as the interviewer, the longer I've been working the more I think "creative" is just as much of an overloaded and under-defined term as "smart". These days I just look for the ability to think through complex things methodically, and the creative spark will show itself later, and in place of innate creativity, the ability to churn through lots of ideas when it's needed is a serviceable substitute.
And if by "creative" the interviewers (not necessarily you) mean the ability to come up with novel but compelling ideas, that's something that happens on timescales longer than an interview and certainly not under interview pressure. The people I know who are best at generating novel, compelling ideas do it on the timescales of weeks to months.
One day, we'll look back at brainteasers for interviews like how most of us currently view phrenology today.
EDIT: Assuming Feynman is deliberately being obtuse, he might point out that, while unlikely, if the round cover is placed on its edge, it could roll away potentially injuring someone or damaging property.
This is a very good point for someone who is known, among other things, for his O-ring demonstration (https://en.wikipedia.org/wiki/Rogers_Commission_Report#Role_...).
I also at no point got the impression that this fictional Feynman was very convincing, charming or anything like that. Just a bit of a talky wise-ass, really. Obviously he knows his stuff, but he's not direct enough to just say that outright, he tries to lord his intellect over the interviewer.
So I really wasn't sure what the punchline ("let's hire you in marketing") was all about. Is the interviewer saying this guy is a bad engineer since he doesn't get to the point? That he's a good marketer because he can talk lots and lots of bullshit?
Is the implication that being offered a position in marketing would be better than in engineering? It's definitely not what the candidate came in for, and the interviewer also doesn't mention if they would hire him for engineering, just for marketing.
That much, at least, actually sounds like Feynman. But for the most part, no, it didn't really sound much like him.
Also, the manhole cover question was considered déclassé as early as 1999. One that was still making the rounds was...let's see if I can remember this... You have a soda machine that has three buttons, Coke, Pepsi, and Random (Coke or Pepsi). You know that your trickster coworker has swapped all of the button labels, so none of them are correct. What's the optimal strategy for getting a Coke out of the machine?
Its why I hate those things. They aren't testing analytical or creative ability, they are testing grace under pressure - a quality I have found is gained through experience.
- The highest likelihood of getting your choice with a single pick
- The least amount of money spent to guarantee getting your choice
- pepsi is coke or random
- coke is pepsi or random
- random is coke or pepsi
If you want Coke and you start with Pepsi, you'll get back Coke (1/2 + 1/2x1/2) or Pepsi (1/2x1/2). However, you could pick it and get back Pepsi 10 times in a row.
If you start by picking Random, you get back Coke (1/2) or Pepsi (1/2). If you get back Pepsi, you know
1. Random = Pepsi 2. Coke = Random (since it can no longer be Pepsi, since Random is) 3. Pepsi = Coke
So, you get back Coke on your first attempt (1/2), or you get back Coke on your second attempt (1/1).
So picking random first, then the correct one, optimizes for lowest upper bound on the number of choices to get what you want. Which is _actually_ what I meant by "The least amount of money spent to guarantee getting your choice", but didn't actually express correctly.
Why would you push it ten times in a row? If you get a Pepsi from it on your first press, you now know:
- The button labeled Pepsi is actually Random (it can't be the actual Pepsi button, since none of the labels are correct, and it's also not the Coke button)
- Therefore, the button labeled Coke is actually Pepsi (it can't be Coke by rule, and it's also not Random since we know where Random is now)
- Therefore, the button labeled Pepsi is actually Coke (elimination)
So the max is still 2 steps, but you have 75% chance of getting a Coke on the first try instead of just 50% chance. Same lower bounds, but better expected value.
I agree, and didn't mean to suggest otherwise. I was just referring to the specific probability computations being made.
Regarding the other two buttons, one is random and the other is coke but their labels are pepsi and coke, giving us only two possible (order-independent) states which I'll illustrate with the format drink(label)/drink(label):
Coke(Pepsi)/Random(coke)
Coke(Coke)/Random(Pepsi)
The second case is invalid because it would require for the coke label to be correct, leaving only one possible case: the button labeled pepsi would have to give out coke.
Let's say you press the Random button first. If it is actually the Coke button, you get a Coke, and you can stop. Otherwise it's actually the Pepsi button, then you press the Pepsi button since that is actually the Coke button. So you get a Coke in one or two button presses.
Basically there are only two permutations of buttons possible, because all other permutations are disqualified by the "not the same as before" rule. Since the goal is specifically to get a Coke in the fewest button presses, you just have to not start with the Coke button since that is the least likely to produce a Coke.
rot13:
Bcgvzny fgengrtl vf gb fryrpg "enaqbz", gura vs lbh trg n Crcfv, fryrpg "Crcfv". Gjb cerffrf znk
Nsgre fryrpgvat "Enaqbz":
* lbh trg n Pbxr (1 cerff)
* Lbh trg n Crcfv
Vs lbh trg n Crcfv, lbh xabj gung "enaqbz" vf gur ohggba juvpu nyjnlf cebqhprf n "Crcfv" (bayl "Crcfv" be "Enaqbz" pna cebqhpr n Crcfv, naq lbh xabj gur ynoryf ner jebat).
Sebz urer, lbh xabj gung gur ohggba ynoryyrq "Pbxr" pna'g cebqhpr n "Pbxr", nf gur ynoryf ner fjvgpurq. Vg pna'g cebqhpr n "Crcfv", nf jr'ir sbhaq gung ohggba, fb vg zhfg or "enaqbz".
Gurersber, cerffvat "Crcfv" ba gur frpbaq gel jvyy nyjnlf trg lbh n "Pbxr"
I prefer Pepsi to Coke, so I wouldn't attempt to get a Coke. The optimal strategy is, of course, to get a crowbar, pry the machine open and take what you want.
That's the optimal, least expensive strategy -- assuming you have access to a crowbar.
And what job did he apply for?
The last one was "how many tennis balls could you fit in the Empire State Building?". I spent maybe 10 minutes asking idiotic "clarifying" questions before the interviewer realized I was messing with him (e.g. "can I use any color for the balls?" "Do I have a crew to help me?" "Can I try to crush them?" etc). He got pretty upset yeah, saying that I wasn't taking it seriously. I just said "with a question like that I think you're the one not taking it seriously". I didn't get the job.
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 lighthearted, which has the advantage of removing all of the computery specifics that could bog you down in a realistic question. The ability to pull numbers out of your ass quickly, and still have them be within a factor-of-2 of an answer that would take weeks or months to gather, is critical for a developer.
The ability to guess that is also a good indicator of whether you're likely to be a good culture fit.
One of the reasons I don't like "how many ping pong balls" etc. is that you're wasting valuable interview time. Interview time should be treated as very valuable to all concerned. Asking about ping pong balls just to find out estimation skills is a waste of time because it doesn't raise any other interesting questions, vs asking an estimation question that raises all kinds of other things you can pick up that are actually relevant in addition to testing estimation skills.
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.
But hey, ask your silly question about sodium atoms. As for "interviewing you" as well, if you're ever interviewing me and pull one of those out, you better be looking pretty good in the rest of the interview because you just lost a lot of points.
The skillset I have that allows me to accurately estimate software projects is based on my knowledge and experience in that domain, and just because I can estimate there doesn't mean I can estimate tennis balls in a building, nor does being able to estimate tennis balls in a building give any indication of ability to estimate software projects.
Anyone that thinks there's some overlap between estimating software problems and estimating how many tennis balls would fit in the Empire State Building is not someone I'd want to work for.
x * y * z * 0.6 * n
If you could quickly express it like that, despite not actually coming up with a number, you would probably pass. To me, being able to estimate the scope of things before launching into writing code is a valuable skill, but there's something about the quirkiness(?) of how the question is presented that's off-putting to some people. But on the other hand, maybe that's by design, and those people are the ones being selected out?