Technically speaking, blogs are supposed to be places where you talk about things you've seen or read and comment on them, at least in one connotation of the word, which I rarely do here. However, I came across this article, discussing the origins and popularity of the "brain teaser" interview/recruiting format and seemed like a good way to return to my blogging roots.

I have previously railed against brainteasers as I feel that it has little or nothing to do with what software engineers actually do. In this article though, in addition to the classic brain teasers, it also discusses the use of estimation problems such as "How much would you charge to wash all the windows in Seattle?". The article failed to mention the historical context for these questions as Fermi Problems, but it offers a similar justification, via a Google employee:

Such questions are more relevant to a high-tech job interview than you might think. "Employers want to see if you can make an estimate in the ballpark, within an order of magnitude," says Mark Jen, a former Google employee who is now a program manager at Tagged.

and it goes on to posit:

Coders are constantly making educated guesses rather than calculating exact answers, so a good interview should probe how well a candidate handles such estimates. That's why Amazon.com interviewers, for example, have been known to ask job candidates to guess how many gas stations there are in the United States or to ballpark that bill for washing all of Seattle's windows.

I agree that we often need to make educated guesses instead of direct calculations, so it certainly is a more authenticate assessment than a brainteaser (in my opinion). The bigger question is: is this a useful skill to test in an interview setting? I believe that if the original intent of the Fermi Problem is actually observed, then the answer is yes. To me, that means two things:

1. Ignoring the actual generated estimate, or inputs used to the estimate in favor of looking at what the inputs were - In the classic Fermi Problem "How many piano tuners are there in Chicago?" the fact that someone wildly under or overestimates the population of the city is less important than the fact that they chose that as an input.
2. Paying attention to where they feel they need more information, and probing about how they might obtain it.

In addition, I would suggest choosing more domain-specific estimation problems. Instead of the cost to wash the windows of Seattle, ask them to estimate the number of bytes that are actually transmitted across the network to load a 100K HTML file in the browser, or the amount of power needed to keep a 1000 piece server farm at 90 degrees for an hour. In addition to understanding their estimation process, you will be able to see their mental model for the realization of these operations in the real world, which is the part I personally feel is the most critical.