For anyone wondering what relevance an estimation question could possibly have in real life, imagine it's 2004 and you're about to launch GMail. How many hard drives are you going to need?
Or more practically that they would do a roll-out release (as they did) and increase capacity as they go. All questions for devops, the product manager or some type of an "Architect" working with analytics to estimate demand and volume.
To imply that a single engineer in a room with no information about Gmail's infrastructure is supposed to know that without (any information about: technologies, storage, indexing, user volume, mail volume, etc) seems absolutely fucking stupid. If they want to hear me think aloud about these things and know that I can be cognisant of them... well... there are better ways of doing that than asking me stupid questions that it's stupid for me to even try and answer.
As someone else said, simply changing the question from "How many gas stations are there in NY" to "How would you estimate the number of gas stations in NY" makes it entirely different, IMO.
What if, increasing capacity as they go, they discover that they're going to need 140 billion dollars worth of hard drives?
Before the rollout can happen, someone has to decide whether or not to greenlight the project. And that person needs to come up with an estimated cost. Before the rollout begins.
> To imply that a single engineer in a room with no information [etc]
Who implied that?
I'd prefer questions and problems and challenges that I'm likely to face and address as an engineer.
If Google hires engineers to answer "brain teasers" that either require a dozen exceptions/qualifications or some vague random nonsensense answer, then more power to them.
(But I doubt they do, they wouldn't be where they were if their hiring practices didn't work to some degree.)