[rorrr2]

The problem is, the interviewers often judge how accurate your estimation is, and not the fact that you know (the highly flawed) Drake Equation.

These estimates are completely useless in real life, because in real life nobody guesses how many drives you need for GMail, or how many gas stations there are in LA.

[ctdonath]

These estimates are completely useless in real life

Oh yes they are, for getting a grasp on what real life entails and what's possible.

With all the NSA scandal/hysteria going around, lots of people are approaching the issue with the presumption "gee, they can't possibly record everyone's phone calls". With a quick estimate I figured recording everyone, all the time, in CD quality, would take just 5% of the federal budget - making it doable instead of improbable or impossible, and making subsets of the scenario (i.e.: just recording phone calls) likely. For those of us who remember 10MB hard drives and 5.25" floppies, such a data scale is staggering - but it's a current reality, and a little estimating provides a reality check.

Likewise grasping the concept of, or even implementing, high-res "eye in the sky" drones. Gigapixel cameras seem like a novel futuristic impractical concept ... but then a little estimating involving HD-quality cell phone cameras, you can realize that a 24/7 flying 30fps gigapixel camera drone is in fact quite possible for a relatively modest sum (speaking in jurisdictional law enforcement budget terms). (Takes less than 200 cell phone cameras and a suitable multiplexer & high-bandwidth downlink BTW.)

I had an epiphany about accounting (!) when touring a billion-dollar timeshare (hotel/condo) project. Wanna make a billion dollars? Pick some large expensive project, then estimate your way down to a plan for pulling a few dollars out of a LOT of wallets by dividing, dividing, dividing away into manageable chunks people are willing to shell out a few bucks for.

Such estimates are exercises in how to mentally manage very large scale money, personnel, opportunities, and processes. Wanna make a billion dollars? Charge a buck profit per window to wash a thousand windows for each of a thousand businesses every week for 20 years. Don't laugh, there's some really rich people who made a lot of money charging a buck at a time - because they estimated their way into a profitable vision.

[peripitea]

In my experience, the rare quality is not the ability to do these estimates, but the ability to recognize situations where such estimates might be valuable. Most educated people can come up with reasonable estimates if posed the question, but far fewer realize when the question is worth posing.

Imagine a world where car2go does not exist yet. I would expect most of my friends to be able to roughly answer the question: "how many cars do you need to start car2go in City x?", but only a handful, if any, would have the imagination/insight to realize the potential and ask that question in the first place.

[jzwinck]

Just yesterday someone asked me whether a particular disk array would be the right size or not. I didn't have any particular number in mind beforehand, yet I was able to say that the proposal was oversized by a factor of five. If someone told me they had a sweet new application for gas stations in California, I would be ready to figure out how much money each installation would need to make to cover salaries for a programmer and a DBA, even if it's just a hallway conversation. It's OK to be a bit off; it's not good to have no idea.

Your point that interviewers read the wrong signals from candidates' responses is a very good one, but it's not specific to estimation questions. It applies as well to straight-up programming questions and probably a lot more.

[ig1]

I'm not sure where you've worked, but doing resource estimation for projects has been pretty important for most greenfield projects I've worked on.

It's also good for sanity testing, it's a useful skill to be able to spot that something is out by an order of magnitude as it can allow you to catch problems early on.

[tomp]

Perhaps these kinds of questions would be met with less "wtf" looks if they were asked in reverse, as in: "My manager ordered 10 000 000 hard drives for GMail. Do you think we'll need them?" It's much easier to judge an estimate when you see it than to come up with it (especially in an interview where the emphasis is usually on whether you're right or wrong), at least for me.

[rorrr2]

Data-backed estimation is completely different from random guesses you will make during an interview.

Not only that, even if your guesses are decent, multiplying them can drive you orders of magnitude in the wrong direction.

[ig1]

The underlying data might be different but the process is the same, you need to figure out what are the contributing factors, how they relate and establish an upper and lower bounds for the values you're assuming.

Once you have data you can make corrections to those bounds, but other than that the process is the same.

It's a skill that a lot of first time startup founders lack. They have no-idea how to estimate the market size for their startup, you need to understand the process of how to build an estimation model.

[Ziomislaw]

Process is not the same, in one case you have real data, in the other one you pull the data out of your arse.

[ig1]

It sounds like you build estimation models by looking at the data you have and combining it together to try and figure out your goal.

The disadvantage with that approach you often end up missing factors (because you don't have the data to hand) and end up with a suboptimal model.

In the same way that a lot of startups end up analyzing user behaviour by page analytics rather than user analytics simply because Google gives them page analytics.

It's a good idea to know how to do both top-down and bottom-up estimation models, as best practice is to make estimations using several different models and compare the results.

[hkmurakami]

In every situation I know of, it's not the accuracy of the answer that is being judged but rather the thought process and basic math and assumptions chosen to get there.

In any case it's one of those things where you tend to do well if you've prepared for it and do pretty poorly if you face it for the first time. Probably a better fit for interviewing management consultants than programmers for sure though

[atondwal]

> These estimates are completely useless in real life, because in real life nobody guesses how many drives you need for GMail, or how many gas stations there are in LA.

Do you never do sanity checks? If you want to compute the number of drives you need for GMail, you estimate, do the computation, make sure they agree, and then have someone check your work.

[skrebbel]

You're a startup in the cheaper-fuel business. You work on the assumption that most of your users will be mostly going around a single city's metro area, which heavily impacts your UX design.

You now need to make decisions about UI (map or list? what's a good default map zoom level?) and infrastructure (how much gas station data will a single user need in a single request? how does that impact my storage?) and a whole lot of other places.

You need a nice representative metro area that first a realistic worst-case scenarion, say LA.

How is any of this unrealistic?