4 ms·

So what's not serious about that question assuming it was for a programming position?

988747 5y ago
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.
- jfengel 5y ago
  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.
  - jerf 5y ago
    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.
    - jfengel 5y ago
      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.
      - zepolen 5y ago
        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.
        jerf 5y ago
        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.
        zepolen 5y ago
        They are completely 'it', you just don't understand how, and don't even bother to ask why.
  - v64 5y ago
    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.
    - jfengel 5y ago
      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.
- RHSeeger 5y ago
  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.
13of40 5y ago
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?
- deleted 5y ago
  [deleted]
retrac 5y ago
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.

jfengel 5y ago
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.
- jerf 5y ago
  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.
  - jfengel 5y ago
    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.
    - zepolen 5y ago
      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.
      - jerf 5y ago
        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.
        zepolen 5y ago
        They are completely 'it', you just don't understand how, and don't even bother to ask why.
- v64 5y ago
  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.
  - jfengel 5y ago
    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.
RHSeeger 5y ago
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.

13of40 5y ago

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?

deleted 5y ago
[deleted]

retrac 5y ago

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.