If Richard Feynman applied for a job at Microsoft (2002)(sellsbrothers.com)
sellsbrothers.com
If Richard Feynman applied for a job at Microsoft (2002)
https://sellsbrothers.com/12395
219 comments
I don't get the derision for these kinds of problems. And I think it's unlikely Feynman would have found this unhelpful. These are commonly referred to as Fermi problems. Fermi was a physicist of Feynman's generation - they were probably standing together at Trinity when Fermi did the famous yield approximation. The other physicists held this ability in such esteem they gave it a name and remembered him for it.
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.
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.
Indeed. Feynman talked in ‘surely you’re joking..’ about his affection for MIT students in his fraternity setting one another puzzles, and he talked about the question of how trains go round corners being one he found particularly interesting. In fact he repeats it in this interview: https://www.youtube.com/watch?v=y7h4OtFDnYE
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.
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.
The 747 ping pong ball estimation problem is a Fermi problem, where the goal is to get the right order of magnitude of the answer. Sure.
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.
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.
I worked and interviewed a lot of people in business consulting. We did ask what you call Fermi problems as they are surprisingly representative of the abstract thinking that is required in the job, specifically proposing frameworks for what kind of information we need to either go and get or state as assumptions in order to support a decision. As the GP points out, the questions are testing how you model something you don't know but have common sense about, and significantly, how you don't get caught up in uncertainty or irrelevant minutia and identify some core assumptions.
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.
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.
This is really good insight and reminds me of similar industry norms that often get strong pushback (e.g. OKRs). Often there is solid reasoning behind why and when you'd want to employ these practices. However, enough organizations implement them just because they've seen them used or because there's hype around them. Eventually the poor implementation attracts pushback, but often the naysayers also don't understand the reasoning behind the practice.
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 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 have no idea why anyone asks brainteasers in an interview.
I'll go one further - interviewers doing Myers Briggs Personality Tests.
I'll go one further - interviewers doing Myers Briggs Personality Tests.
> 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.
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.
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.
I do agree that logic puzzles which require a single observation and/or have a binary outcome tend to be very bad interview questions. That being said, I think the original post demonstrates that the issue with the manhole cover problem isn't necessarily the question itself, but how it's evaluated. I'd be quite pleased if I were asking the question and the interviewee gave that answer (though I might raise the point that the configuration necessary to drop a rectangular cover is also one of the most ergonomic for holding it). The general notion that there is a single right and wrong answer is incongruous with a class of question used to evaluate the candidate's reasoning ability. Though I wouldn't be surprised if these were historically evaluated appropriately and candidates simply misinferred why they were being rejected.
An interesting little tid-bit: I've read that Feynman was sitting in a truck at Trinity, and I think he was alone. Feynman calculated that the truck's windscreen would absorb enough of the bomb's UV emissions to obviate the need for additional eye protection. The same source (which I cannot currently locate) said that everyone else was wearing welding masks/goggles.
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.
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.
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.
That would be true if everyone wasn't also asking the same questions. So you are just testing whether the person knows that you ask that question or has interviewed at other places that do (I have seen this in other industries too: firm adopts some "interview technique", no women get through, no under-represented groups get through, they are baffled but put it down to their process being a completely objective identifier of innate genius...kind of ignoring that some of these places are hiring tens of thousands of people who, by definition, aren't geniuses...people are weird).
[deleted]
I'm not sure I buy this type of attack. How is this different from calculating yield of a bomb as Fermi did? It's back-of-envelope calculation that physicists do all the time. Ping Pong in a Boeing is merely a setup with the least context. This is like criticizing a math teacher for asking elementary students to calculate how long it takes to fill a swimming pool when water is flowing in and out of the pool at the same time. Yeah, the setup sounds ridiculous, but you know what, that's the setup that a student understands, and we see similar scenarios in real world: a company earns and spends at the same time, a queuing system has incoming traffic and completed tasks, a factory has incoming jobs and outgoing completed products... So, what's wrong with the question again?
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.
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.
This is fine if the question relates to something that the candidate is familiar with. But I have personally never set foot in a 747, much less be able to come up with any estimate of the dimensions in order to estimate volume. Then there is the formula to determine the packing volume of ping pong balls.
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.
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.
I guess we can always clarify the context? Something like: I've never set foot in a 747, could you please describe what that is? Can I assume that the plane has no furniture, and the dimension is yada yada? You know, have a conversation.
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."
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."
How well these questions correlate to job performance is an interesting question but the goal I think is not for you to get to the "right" answer (in the sense of figuring the optimal bin-packing approach on the fly). The goal is to see how you are able to take a broad problem and break it down by:
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?
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?
I’ve found in interviews you can just declare your assumptions for the things you don’t know.
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.
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.
You would think that ultimately the question is about the thought process. But that usually gets lost and it devolves into a question that gets asked with an expected answer.
> I have personally never set foot in a 747
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?
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?
Why use the pool at all if you already have useful examples of inflow and outflow of money or another or the queue at the grocery store? Someone of age to understand flow rates of liquid would likely be able to understand money enough to be able to do the same calculations can’t get the same principles but with a functional analogy instead.
There are an infinite number of variations on the problem; you could also ask about a reservoir with inflows and outflows, or a water tower, or a continuous distillation process. I think the money variant is actually one of the worst, as it evokes no imagery (in an era of largely digital transactions), but I'm not sure the exact question asked really matters.
If someone fights a hypothetical, they're usually being adversarial, confrontational, or just avoiding answering the question, which is useful information in an interview.
If someone fights a hypothetical, they're usually being adversarial, confrontational, or just avoiding answering the question, which is useful information in an interview.
> I think the money variant is actually one of the worst, as it evokes no imagery
Plus money is obviously discrete, while water is conceptually nice and continuous.
Plus money is obviously discrete, while water is conceptually nice and continuous.
My guess is that such problems are for 3rd-graders, who do not necessarily have real-world experience to understand more realistic setup.
There is an interesting point in there about reverse engineering stuff, like you sometimes see in evolutionary biology and such.
The cylinder being the strongest shape is the most interesting answer.
In an interview, stopping at this might just make you not get the job. If you're lucky the interviewer will laugh and ask the appropriate followup question. It goes something like this:
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?"
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?"
Yeah, unfortunately you get asked to do some pretty silly stuff all the time and being able to cope with that is a critical skill.
Actually I find this a fun thought experiment that can show if you are just a code monkey or a software developer.
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.
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.
Actually the Anwser is simple to solve at least estimate fairly accurately if you assume the Airplane has to fly. You just need to know the model and how many pallets fit into the cargo. The pallets are square with known volumes you pack them at the packing factor for spheres and you are done. There is some bulk cargo area but it’s not big so you need to account for that and That’s about it. You can ignore mass unless the problem lets you smash then then you are just packing plastic blocks into a container and you have to double check you aren’t limited by cargo capacity and range.
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.
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.
Square pallets sounds awesomely easy indeed. I didn't know that existed. I've only seen the ones that are wider on the top vs. the bottom. Like this one https://www.dsm.com/content/dam/dsm/dyneema/en_GB/images/app...
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.
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 with that question isn't that it's stupid. Everyone knows it's stupid, it's testing your ability to come up with an estimate in a domain you're not too familiar with using "napkin math". That's a legitimate skill and asset in software engineering.
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.
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.
> 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.
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.
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.
Which is why companies started moving into other questions that have no relation to your job, like designing youtube. There is such a slim chance that you'll end up designing youtube at your tenure there, in a team of 2...that it's probably more likely to fill a jet with balls. Yet somehow people are not bothered by the design youtube question the same way they are about balls in a plane. It's true that the youtube version has technologies that are somewhat related to what you'll be doing, but in practice you won't have the opportunity to choose that many technologies for a single product, you'll be a cog in the machine anyway.
Yeah, I think in general people lump Fermi estimation problems in with "brain teaser" questions (which I think really are silly) because they are both technical(ish) interview questions that have nothing to do (superficially) with software engineering.
> 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.
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.
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.
Feynman wouldn't dismiss that question. He'd overthink it.
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.
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.
> I'd think it was stupid to fill a 747 with ping pong balls and think about something else
This man never heard of a Fermi estimate, or encountered one in a problem set.
This man never heard of a Fermi estimate, or encountered one in a problem set.
It's possible to know what a Fermi problem is and still think that they're bad interview questions.
>We want to understand your thought process
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.
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.
The problem is that it is impossible to give a good answer without context. Did it matter a 2% error? There are cost limits? Maybe you don't even need to know the number of ping pong balls but it would be faster to transport them by ship....
If you dissolve the ping pong balls in acetone first I can fit as many as you have available into a 747 with plenty of room left over for a machine to reconstitute them on the other side.
Isn't the context an interview, ie. give a decent order of magnitude estimate with back of the envelope methods.
Probably, but to be fair, when a client asks "can you put a button here that sends an alert email when it's clicked?"... a reasonable first question may very well be "what is it you're hoping to accomplish here... so we can tell if such a button is really the right answer". In many cases, the button isn't the right answer. And being the kind of person that digs to find out what the problem trying to be solved actually is... can be very important.
Oh, yes. It's about having a shared culture more than intelligence or knowledge. I know what I will answer if I wanted the job, that does not mean that it's a good answer, it just means that I have the background to know what are they looking for.
Also, you need pilots. And never mind ping pong balls are highly flammable and thus dangerous goods. Maybe they want to burn down a 747?
The correct answer really depends on what role the candidate is trying to get.
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.
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.
Usefulness of the question aside, dismissing it as stupid is at the very least, shortsighted[1].
[1] - https://www.iusmentis.com/patents/priorart/donaldduck/
[1] - https://www.iusmentis.com/patents/priorart/donaldduck/
This could be a mass or a volume problem, actually there are some other things that could limit the problem statement but those are the obvious ones. But the problem is too general to solve. It really just depends on what you want to do with the ping pong balls and the airplane after you filled the airplane. That’s the critical piece of information that’s missing that should be provided. Otherwise you end up with a bunch of solutions that technically meet the problem parameters but don’t actually solve a real problem
When asked how I'd do some contrived text processing task, I replied "I'd look at the wiki page for grep and futz until something worked." (Today I'd probably start with 'tldr' command.)
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.
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.
> I'd think it was stupid to fill a 747 with ping pong balls and think about something else
This is fine as long as you understand that it's equivalent to walking out of the interview right then and there.
This is fine as long as you understand that it's equivalent to walking out of the interview right then and there.
I was expecting something a little different, where they passed on him because he didn't give the 'right' answer (what the interviewer had preconceived and/or looked up online).
You know how police have to take an IQ test and get denied the job if they score too high?
Like that, but for tech interviews.
Like that, but for tech interviews.
I think it's a rare practice right?
"... 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...
"... 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...
Bored like Peter Gibbons?
https://www.youtube.com/watch?v=j_1lIFRdnhA
Maybe you need a promotion.
https://www.youtube.com/watch?v=af8DVIZ5LX4
https://www.youtube.com/watch?v=j_1lIFRdnhA
Maybe you need a promotion.
https://www.youtube.com/watch?v=af8DVIZ5LX4
There are a lot of good points in there
> police have to take an IQ test and get denied the job if they score too high
Pilots as well, apparently.
Pilots as well, apparently.
Well yea, that expectation was produced purposefully in order to be subverted for the actual punchline.
Well, that _is_ the conceit here. The ‘right’ answer is that all manhole covers are round because a round cover can’t fall into the hole.
I'm fairly certain a square manhole cover with a sufficient perimeter would still have no chance of falling into a hole, depending on the diameter of said hole.
It explains in the joke how it's possible to fit a square cover into a slightly smaller square hole. The easiest way is to position the cover vertically and across the diagonal. The lip that the square cover rests on would have to be impractically large to fully prevent the cover from fitting into the hole.
If you provide a sufficient lip on the hole such that the minimum side is larger than any of the four diagonals it would work.
Right, but this makes the area of the cover twice the area of the hole, and the cover twice as heavy as it would need to be if it were round. As Feynman pointed out, even round covers are already pretty heavy—I injured my wrist (ligaments?) from the tension of lifting one in my teens.
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.
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.
Indeed, though to do it this way would be very wasteful of resources as the ratio of the manhole size to the size of the cover wouldn't be maximized. The cover would be needlessly covering a lip whose large size only exists because of the poor choice of shape.
[deleted]
If we're talking square cover, round hole, no cover big enough to cover the hole could fall in.
If I know anything about capitalism, the primary reason manhole covers are round is because that's the most cost-efficient shape for the job.
This is almost certainly the answer. They're round to fit the cylindrical holes they're covering, and those holes are round because they're made with drills, and they're made with drills because that's a lot faster and cheaper than digging.
Tunnels are round because a round tube on the inside is stronger against compression than an equivalent square tube is. They are like vaults.
Manhole covers are round so you can move them by rolling them around. Duh
[deleted]
But a triangle works for this, too.
Pretty sure I can toss a triangular cover into a triangular hole. You might be thinking of a Reuleaux triangle (which is not a triangle, narrowly conceived.)
https://en.wikipedia.org/wiki/Reuleaux_triangle
https://en.wikipedia.org/wiki/Reuleaux_triangle
Yes, you're right, it's actually a curved triangle; or any curved shape with a constant width. The key aspect is that it has to have a constant width.
Many manholes are in fact squared. So the premise itself is wrong.
Let's just say there are many questions that people ask in interviews where they have a scientific sounding answer that is simple and wrong (when considered in full context).
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'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
This has nothing to do with full context and some obscure scientific fact. The squared manholes are super common. Many of them are squared and I probably stepped over some squared on my way to interview.
It is like asking why milk is sold always in yellow box. The question makes no sense, because milk boxes can have any color.
It is like asking why milk is sold always in yellow box. The question makes no sense, because milk boxes can have any color.
This is pointed out in the first two words of the "Feynman" answer ("They're not.")
In Feynman's day, people climbing down a manhole ladder were still mostly elliptical in cross-section. It's only nowadays that most people are mostly circular.
Ok, this is funny and odd. This immediately reminded me of the scene in Cryptonimicon where Waterhouse takes a 'simple' math test. It apparently reminded my past self of the same thing 11 years ago, when this was posted back then.
https://news.ycombinator.com/item?id=1866629 (I dug up the actual passage from the book, so you can read it)
https://news.ycombinator.com/item?id=1866629 (I dug up the actual passage from the book, so you can read it)
I listened to it as an audiobook while driving, and listened to that segment 3 times back-to-back.
But can he do a heap sort on the whiteboard, that's the real question
Probably not, but he could sleep with his bosses wife
Why not? He was into computing. His lectures on computation (transcribed from his course in California Institute of Technology) are published:
https://www.amazon.com/Feynman-Lectures-Computation-Frontier...
https://www.amazon.com/Feynman-Lectures-Computation-Frontier...
He worked for an early computer manufacturer at one point in his life. The completely wacky Thinking Machines Corporation, who built probably the strangest computer architecture ever commercially developed.
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.
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.
They're very good lectures, too.
In the same vein: The Barometer Question and Calandra's account
https://en.m.wikipedia.org/wiki/Barometer_question
Hold the barometer up and shout that it's a bomb & you'll blow up the building if someone doesn't tell you how tall it is.
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.
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.
Dig a hole all the way through the earth and drop the barometer from the top of the building into the hole, and subtract from that time the time it would take the barometer to fall from directly over the hole to the other side and then divide the remainder by 9.8m/s^2.
Strap the barometer to a bomb & drop it on the building. Proceed to argue with the examiner in the rubble over the definition of "building" and whether the tallest piece of debris qualifies.
I'd never seen that before, that's excellent!
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.
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.
It sounds like the original question was just badly worded. It should have read "Show how it is possible to determine the height of a tall building using only a barometer.". The other answers, while not incorrect, do assume the availability of additional items such as rope and watches.
The one about direct measurement wouldn't require anything else. You're just climbing the stairs and counting. Doing it the "right" way would also require the stairs (well, and elevator would work for that too, but I would count the elevator as an additional item which itself uses complex mechanics and cables to get you to the top.)
> using only a barometer
But the pressure of a vacuum is 0, so unconventional means would be required, if it were worded that way.
But the pressure of a vacuum is 0, so unconventional means would be required, if it were worded that way.
Interesting. Unz.com is a radical Right (I wouldn't say extreme-right) wing website...
They have a dualistic world view, and the public school system is part of where the enemy stands. Anything that scores points against the enemy is a good weapon.
this is one of my favorite made-up stories
"It looks like you're trying to create a pictorial representation of the mathematical expressions describing the behavior and interaction of subatomic particles. Would you like help with that?"
It amazes me how defensive, threatened, and snarky people get about interview questions.
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.
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.
tease out if someone is a creative thinker
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.
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.
Eh, your mileage may vary, but I've normally found too completely open ended questions impossible to ever really get a good signal from. I've done enough interviews to feel like questions with a pretty binary "you either get it or you don't", evaluation make it pretty hard to judge someone. I'd rather ask questions where there are multiple levels of evaluation, rather than a single trick.
> do you know how hard it is to tease out if someone is a creative thinker or just a bullshitter?
One day, we'll look back at brainteasers for interviews like how most of us currently view phrenology today.
One day, we'll look back at brainteasers for interviews like how most of us currently view phrenology today.
I've read it before, but it's always such a fun read. The author got Feynman's speaking style down perfectly.
Well, I think it gets it wrong when it comes to the safety issue question. Something being possible, even if unlikely, is obviously more dangerous than something being impossible. Feynman would definitely understand that even if he insisted that the main reason for the shape of the cover is the shape of the hole (which is probably true).
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.
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.
> Something being possible, even if unlikely, is obviously more dangerous than something being impossible. Feynman would definitely understand that even if he insisted that the main reason for the shape of the cover is the shape of the hole (which is probably true).
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_...).
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_...).
Love the o-ring story. One of the reasons he's my hero.
[deleted]
I couldn’t help but read that in Feynman’s voice!
I misread the title and thought it was talking about Stallman, and I wondered why he would ever apply for a job at Microsoft...
[deleted]
I can't read anything about Richard Feynman without thinking of the letter he wrote his wife 16 months after she passed away. "I love my wife. My wife is dead."
https://fs.blog/2013/08/richard-feynman-love-letter/
https://fs.blog/2013/08/richard-feynman-love-letter/
Well, the computer company he did work for isn't around anymore, so Microsoft would probably be ok passing on him.
What an amazing ending! :)
When I worked there in the early 2000's I had a friend of a friend whose fiancée graduated with a bachelor's degree in either CS or EE and applied for a developer position. Somehow, and I struggle to understand the mechanics of this because engineering was highly compartmentalized away from the "business" parts of the business, they managed to turn her down for an engineering role and got her a job in marketing.
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?
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?
That was actually fun to think through for a minute. Easy, but I can see how a young me nervous at an interview might have stumbled.
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.
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.
It depends on your definition of optimal. If you optimize for time, then pressing each button one at a time until a Coke comes out. Plus it doesn't take any brain cells so I can get back to coding quicker. : )
You can also optimize for
- The highest likelihood of getting your choice with a single pick
- The least amount of money spent to guarantee getting your choice
- The highest likelihood of getting your choice with a single pick
- The least amount of money spent to guarantee getting your choice
If you take as given, "none of them are correct," I think both of those optimisations still start with pressing Pepsi. It is either Coke or random, so you have about a 75% chance of getting what you want on the first press.
If none of them are correct, then
- 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.
- 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.
> 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.
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.
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.
If you hit the Pepsi button and get Pepsi, you know it's random, so the random button has to be Coke (and Coke gives Pepsi). So picking the Pepsi button first still works in two tries - you either get a Coke all the time, get it randomly on the first try, or figure out which button gets you Coke.
Whoops, good point.
At a quick glance, everyone in this thread seems to be assuming 'random' gives you Coke or Pepsi with equal probability ….
Regardless of the probability distribution of the random button, it does not change the optimal strategy. By pressing the Pepsi button, you are either going to get Coke (you "win") or Pepsi (so you know the button is random and you "win" by pressing random on the next go which you now know is Coke).
> Regardless of the probability distribution of the random button, it does not change the optimal strategy.
I agree, and didn't mean to suggest otherwise. I was just referring to the specific probability computations being made.
I agree, and didn't mean to suggest otherwise. I was just referring to the specific probability computations being made.
>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?
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.
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.
I really think the answer for all of those kinds of questions should be "I'd use Google to find the answer". I mean who would try and solve a problem like that without searching for a solution first?
Edit: http://mathpuzzlewiki.com/index.php/Soda_machine
Edit: http://mathpuzzlewiki.com/index.php/Soda_machine
If you're being interviewed for a job at Microsoft the answer should be "I'd use Bing to find the answer."
When I interviewed in Redmond in 2011, they actually told us this in the pre-interview orientation session!
[deleted]
Does anything beat just pressing the buttons in order?
Yes.
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"
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"
IIRC, optimal was measured by how many quarters you put in the machine.
Smashing the machine?
This is essentially the Monty Hall problem. First choice is 1/3d to be correct, if this choice is wrong, then change, because you will now improve your odds to be 1/2
Maybe I am misunderstanding but the question says NONE of the labels are correct right? If so, I was thinking of it this way. If you press coke, it can only be random or Pepsi (.25?), if you press Pepsi, it can only be coke or random (.75?), if you press random it can only be coke or Pepsi (.5) (oddly this is still random 50/50 :) ). So the optimal on first try would be to press Pepsi?
You press random and taste, lets say it comes out pepsi. This means that this button has to be the pepsi button because if it was the random button then the label would be correct, like you mentioned. This settles the pepsi button.
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.
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.
Both methods are fine.
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.
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.
And if that first press fails, the Pepsi label must be the Random button, so you should press the button with the Random label as it is guaranteed to be the Coke button.
This was actually my first-glance answer. Consider that the Pepsi label can't possibly be the Pepsi button, but the other two can.
No, you an apply more reasoning to it up front. If "none of them are correct" then you press 'surprise' first, and you either get the drink you wanted that time, or on your next guess.
If the labels are all incorrect, you would want to start with the one labelled with the drink you don't want. This would give you an initial chance of 75% of getting the drink you do want (.5 + .25). If you don't get it on the first press, then you would press the one labelled "random", as this would 100% be the drink that you do want.
I worked this out for the version of the problem on the linked pages but I must have misread the one posted here.
In Monty Hall Game you improve your odds to be 2/3, not 1/2. If you think the staying door wins 1/3 of the time and the switching door 2/3, where is the car located in the 1/6 missing?
[deleted]
Ask my coworker which one is coke
I don't think I get the punchline. Could someone explain?
You were supposed to expect them to fail his interview because he didn't give the "right" answer (manhole covers are round so they can't fall in the hole). Instead, he completely disagreed with the "right" answer, but did so in a way that was incredibly convincing. So, they decided his primary value was not in his intellect (leading him to a job in engineering), but in his ability to convince people of things (leading him to a job in marketing).
I did follow the "intended" vs. "right" subtext right until the punchline.
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.
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.
yep, the joke was getting at the "talk lots and lots of bullshit" aspect. it's the engineer's stereotype of a marketing person. like, "hey, this guy won't cut it as an engineer - he couldn't even answer the manhole question. but he sure can spout bullshit with the best of them!"
Just a bit of a talky wise-ass, really.
That much, at least, actually sounds like Feynman. But for the most part, no, it didn't really sound much like him.
That much, at least, actually sounds like Feynman. But for the most part, no, it didn't really sound much like him.
Sounded like Stallman than Feynman tbh.
Yeah, it doesn't sound like the real Feynman at all to me. Where's the wit and charm?
Old previous discussion: https://news.ycombinator.com/item?id=1866305
Could've been funny if the interviewee was someone like Descartes rather than one of the most lucid, funny and friendly voices of the 20th century.
[deleted]
Those are actually some very good answers.
I've made all those observations (and more) regarding manhole covers.
And what job did he apply for?
And what job did he apply for?
jmgrosen(3)
gorwell(2)
This is epic :). I can imagine how interviewer would be pissed off if you come this prepared. They love those koan type questions but don't like when you turn the tables on them.
I'm so pissed at these stupid questions during interviews that now I start doing that.
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.
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.
"Do I have a crew to help me?" had me laughing out loud.
[deleted]
[deleted]
So what's not serious about that question assuming it was for a programming position?
Well for one thing, it's painfully trivial. We had to estimate the number of marble candies in a glass jar back in 3rd grade. The closest estimate won the jar of candies. We approached it methodically in much the manner I assume the interviewer expects the applicant to there? Estimate volume of the container. Estimate volume of a marble when packed together. Divide. I guess it does serve as a very, very basic test of arithmetic and reasoning skills. But kind of insultingly so.
For one, it has nothing to do with programming. Also, nothing to do with time management, people skills, or anything else that programmers do on their job.
Without trying to be pedantic... it may have nothing to do with "programming", but it does have to do with "software development". Programming is writing code. Software development tends to be more about problem solving, figuring out what code needs to be written in the first place. I'd rather do the "figure out the number of balls that fit in a building" than "write code to re-order a binary tree", since the former is more likely to clearly demonstrate the problem solving skills I use every day at work... developing software.
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 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.
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.
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 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.
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.
I think there's advantages and disadvantages to either approach. In this case, the thing I like about it is having them talk through their reasoning, regardless of the domain. If it's a domain they're familiar with I get the benefit of their knowledge, but it also takes longer because the specificity raises a lot more questions. If it's an unfamiliar domain, I get a glimpse of their creativity with a problem they haven't previously considered.
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.
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.
These are so cliche that they mean nothing. They're all the same question. Superficially different, but fundamentally three same. There nothing to sink your teeth into, because they're all made up. Asking something with some grounding in reality gives us something to actually chew on.
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.
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.
I find it pointless to convince someone who doesn't see the value of thinking about solutions to problems they've never seen before. They will never be pioneers and that's okay, an organization needs both.
If you're implying I don't see value in solving problems I've never seen before, part of my objection is precisely that these "problems" aren't it. They're all the same. You pull 3-5 numbers out of your moderately informed ass and multiply them together. This is not "a problem I've never seen before", it's a problem I've heard a hundred times before. There's no creativity here, it's a dreadfully dull and well-established process.
They are completely 'it', you just don't understand how, and don't even bother to ask why.
If you want to know how many servers I'd need for a task or to discuss memory/space tradeoffs, then ask those questions outright instead of doing this indirect dance. I don't see how the question gives you an advantage when you're being asked to take skills you use and apply them to domains you don't work in that are irrelevant for the job.
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.
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.
Sounds like we have an excellent accord, then. I want employees who can think creatively about problems that they haven't seen before. So with any luck, you'll find places who want employees like you, and I'll find employees who match my criteria.
The answer to that question is the volume of the building minus some factor (let's say 40%) for other stuff like walls and floors, etc. times the number of tennis balls you can fit in a given space, like a cubic meter. Basically...
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?
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?
[deleted]
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