[Jabbles]

I don't understand people's problem with estimating. It's a useful skill. Perhaps it would be better if the questions actually related to technology, rather than golf balls - but the principle is the same.

For instance - "how many hard drives does Gmail need?" requires a rough guess of how many users Gmail has (if you're interviewing at Google, you should know it's 1e8-1e9). How much space each one takes (probably nowhere near a gigabyte on average - let's say 1e8 bytes). And that the current capacity of hard drives is (1e12 bytes).

Then you can say that they probably need 1e5 hard drives, link it to redundancy, availability, deduplication, backups etc. You can comment that it's feasible to build a datacenter with that many hard drives.

No one cares that the actual number is 12,722 - but you've demonstrated a broad set of knowledge about the current state of technology. Saying "dunno - a billion?" is not going to get you anywhere, and with good reason.

The Monopoly question is crap, though.

I'd like to know how useful http://google-tale.blogspot.com/2008/07/google-billboard-puz... was.

[fishtoaster]

I used to think estimation questions were useful. I still think that estimation ability is something a programmer needs for exactly the reasons you state.

However, I used to ask one estimation question (How many hours have you spent coding over the course of your life) on all my interviews. Over time, I lost interest in it because almost everyone got it "right" (took an acceptable route and arrived at a reasonable estimate). The only people that got it wrong were ones I decided to reject for other reasons (this being a semi-technical but mostly ask-about-experience phone interview).

So, although I agree it's a useful skill, I don't think it's worth askin estimation questions from my personal experience.

[rayiner]

I had a professor who used to say: a great engineer should be able to answer any question in 30 minutes, at some level of precision. Her example was deriving the equations for the dynamics of the space shuttle. You should be able to do it in 30 minutes, even if it's an extreme approximation.

[nawitus]

>(if you're interviewing at Google, you should know it's 1e8-1e9)

Why? Is the interview a trivia exam like in college?

[bcgraham]

> Saying "dunno - a billion?" is not going to get you anywhere, and with good reason.

Not sure if you were referencing this bit from comedian Pat Brice, but here's a relevant video: http://www.youtube.com/watch?v=J2nrKdECSGU

[pavanred]

Even if this idea had some merit, I think once the candidates start preparing for interviews by reading some idiots guide to brain teasers then it loses it purpose and further hurts the candidate who is actually skilled, quick on his feet and has good instincts.

[tomlu]

They do ask those sorts of questions still, but I wouldn't call them brainteasers.

[lancewiggs]

In which case this is lifted in part out of the McKinsey interview play book. A behavioural interview and a case study, with a resume review frost up. Keeping the case studies consistent across a set of interviewees for the best calibration. Making them realistic problems rather than academic exercises or quizzes means multiple paths can be taken to a variety of right answers. Laszlo and many others inside his area are ex McKinsey. (As am I)

[dpritchett]

As a developer I've never heard good things about McKinsey. Can you tell us your perspective on their value proposition and the relevance of their hiring methodology?

The best I've heard about them is that they provide political cover for executive agendas that might not play well absent validation from a third party with some academic credentials.

[lancewiggs]

McKinsey don't operate above the radar, but are responsible for helping with an incredible number of major corporate decisions across the world.

Recruitment and development is McKinsey's core advantage. They attract and retain incredible talent from all sets of places.

Teams work with the top clients - the CEO and team as well as high flyers at more junior levels. Things get done extraordinarily quickly. And well. But make sure that the internal team is up to scratch, and that there is that mandate from the top.

There is no prescription for how to deliver a project, beyond the hypotheses approach.

There is an obligation to dissent, and a client-first mandate. When enforced well the client gets what they need to hear, not want they want to hear. High quality consultants don't want to work on projects justifying dumb decisions - and can choose not to.

Use McKinsey and other consultants to help with new issues, not business as usual. They are fantastic for quickly understanding and assessing important questions of strategy, for mergers and acquisitions, organisational design and so on. They help understand the context and set the new agenda, or validate the old one. Generally clients simply don't have enough internal capacity to perform this work alone.

Use them, decide what to do and start doing it - and then get rid of them. Consultants that are camping at a client are in effect wildly expensive employees.

[sliverstorm]

The other nice part about being able to estimate- you can often determine feasibility with a reasonable degree of confidence, for a minimal investment in effort.

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