Typically, trick questions are things like "how many golf balls fit in a bus", "you've been shrunk and dropped in a blender" , or the infamous "why are manhole covers round". These supposedly test the candidate's creativity, but actually just test whether the candidate has read a book of riddles recently.
I personally think manhole covers should be human-cross-section-from-above-shaped.
Often, the specific result of an estimate is less interesting than the user's understanding of what drives that estimate, because it determines if they understand the levers they can pull to change the outcome in the real world.
Sometimes folks call these "puzzlers" but I think they're unfairly lumped in with true "puzzlers" - crap like "why is a manhole round" where there's a right answer that depends on either experience or some specific insight. A question where you're asking a candidate to walk through their thought process on a hypothetical (but reasonable) situation isn't "puzzling" unless you just can't handle the question.
http://en.wikipedia.org/wiki/Drake_equation
That's the mental template I have for these guestimation bullshitorama type questions, anyway.
Adding features to your software can drastically reduce throughput per CPU core. Even simple architecture refactoring for better scalability can drastically reduce throughput per CPU core (just as you have to pick availability versus consistency, you also have to pick scalability versus throughput).
And hence, because it depends on what the software does and how it evolves, the question cannot be answered unless you stress test a CPU core. The question itself, as phrased, is even stupider than how many golf balls fit in a bus.
I participated in Google's interview once. After 2 phone screenings with algorithmic questions I was invited to a full day on-site interview involving meetings with 5 people, all of which asked me to solve algorithmic problems. In the end I was told that I did OK at the first 3 meetings, but not so well on my last 2 (actually I was able to answer all the problems given to me, but my performance dropped at some point due to getting tired and the last 2 people probably had other questions they wanted to ask, but couldn't due to lack of time).
Personally I recognize the importance of algorithms, data-structures and reasoning about asymptotic complexity. It's stuff that some are learning since high-school and should be common knowledge for all of us.
But what about other things of importance, like actually being able to build and deliver functional software? What about things like the quality of the code you write, or being experienced in building scalable systems, or being capable of working in a team, or having personal projects? I was never asked (maybe it was just my chance to end up being interviewed only by people that cared about algorithms).
Of course, it can be said that these practices worked well until now for Google. After all, there are plenty of really capable people working there. But maybe that happened in spite of the interview process, not because of it (e.g. one reason could simply be that resumes with internal recommendations have priority and people at Google are good at networking and recommending other good people).