[mistercow]

>There's so many different kinds of buses

There is a lot of variance in bus sizes, but not enough to put you off by more than an order of magnitude.

> and it clear what kind of level of accuracy is required.

Knowing what kind of accuracy is required is sort of part of the test. The parameters are vaguely specified, so you should know that you're looking at orders of magnitude.

>I can just say 'two thousand' and that's a good enough answer.

That would fit in a large duffle bag. If you told me that you thought you could only fit 2000 golf balls in a double decker bus, I would assume that you either put zero thought into answering the question, or that you did not have a good grasp of how to estimate things.

> The problem is, that isn't good, as the interviewer wants to 'see how I think'.

The interviewer wants to know that you can give sane estimates based on rough calculations. As the article explains, there are many, many situations where a programmer needs to be able to do this kind of thing. It's not about "seeing how you think". It's about seeing that you can think – at all – about estimation problems.

> But he hasn't really given me a problem to think about, so I have to just put on a show for him. He hasn't seen how I think at all; he's just seen me putting on a show based on what I think he wants to hear.

And if that show is "2000 balls", he has learned that he should not hire you.

[v0cab]

> There is a lot of variance in bus sizes, but not enough to put you off by more than an order of magnitude.

I didn't know that 'within an order of magnitude' was an acceptable degree of accuracy.

> Knowing what kind of accuracy is required is sort of part of the test. The parameters are vaguely specified, so you should know that you're looking at orders of magnitude.

I don't see how I would know that. I would just assume it was a stupid question.

>> I can just say 'two thousand' and that's a good enough answer.

> That would fit in a large duffle bag. If you told me that you thought you could only fit 2000 golf balls in a double decker bus, I would assume that you either put zero thought into answering the question, or that you did not have a good grasp of how to estimate things.

You're right that I didn't put much thought into it. But perhaps that's all the thought this problem requires.

> The interviewer wants to know that you can give sane estimates based on rough calculations. As the article explains, there are many, many situations where a programmer needs to be able to do this kind of thing. It's not about "seeing how you think". It's about seeing that you can think – at all – about estimation problems.

There's nothing to think about. It's not a well-formed problem. The interviewer is going to see me putting on a show, and all they'll see is that I can act.

[mistercow]

Sometimes as an engineer, you have to make reasonably accurate estimates based on very little data. If you think that concept is stupid or not worth thinking about, you shouldn't be in charge of designing stuff.

I don't mean this as an attack against you, but your response to this is exactly illustrative of why it's a useful interview question.

[ebbv]

As I said in my original post, I'm never comfortable acting on as little data (basically none) as is in the original question.

If you are, then I would go so far as to say you are the type of engineer who ends up creating problems other, more thorough engineers have to solve later on down the road.

[mistercow]

So you believe that you should exhaustively explore 100% of your options, collecting rigorous data about every possibility, no matter how numerous the options are, rather than narrowing down your possibilities early in the game and focusing on the best candidates? Now that is a waste of time.

Furthermore, sometimes your data is inaccurate, and that means that you have to build in error margins in your estimates. Doing that uses exactly the same skills as making rough estimates based on vague information.

[v0cab]

There are just too many possibilities here. We don't even know if it is a double- or single-decker bus. If we worked for a company that actually did do this kind of thing (fill things with objects), we would not start making estimates and assumptions based on so little information.

[mistercow]

There are good reasons to make assumptions early on in a project when narrowing down the solution space. You have 10,000 golf balls and you need to get them 5 miles south of here. You ask your coworker to look out the window at your company parking lot and tell you what vehicles you have at your disposal. A sedan, a double decker bus, an SUV, a small trailer, a motorcycle.

If you have reasonable estimation skills, then by the time you get out to the lot with a tape measure, you will have narrowed the search down to the sedan and the SUV. You don't need to bother measuring the double decker bus because you know that it's around 100 times as large as needed. You don't need to consider using the motorcycle because that is clearly far too small. If you collected data on those options, you'd be wasting time, because in the time it takes to collect the data, you could have already ruled them out.

"OK," you say, "but it doesn't hurt to be thorough." But see, it does hurt to be too thorough. Every second you waste on deciding not to use the bus is a second you could have spent making a better decision between the sedan and the SUV.