[mistercow]

How do you mean "subjective"? There is an objective answer to the question "how many golf balls can fit in a double decker bus" and while I suppose you could call it "trivial", being able to make that kind of estimate efficiently really is an important skill for programmers (and scientists, and engineers) to have.

That said, this is another FizzBuzz sort of test, and should not be made unnecessarily complicated. This is what you're trying to filter out: http://www.youtube.com/watch?v=Qhm7-LEBznk

[v0cab]

There's so many different kinds of buses, and it clear what kind of level of accuracy is required. I can just say 'two thousand' and that's a good enough answer.

The problem is, that isn't good, as the interviewer wants to 'see how I think'. 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.

[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.