My favourite interview question (2006)

In both cases, the point isn't to get the right answer, but (allegedly) to see how the person thinks. With the estimation question, the trick is to make up some plausible-ish numbers and then multiply and/or add them to get a plausible-ish result. If someone's seen one of those before, they'll nail it for sure. If not, it's a crapshoot. In theory, you're measuring whether or not someone's able to reason well enough to spontaneously estimate something off the top of their head, but comparing the number of people who've seen those question before vs. the number of people who can answer that type of question without having ever seen it before, what you're really filtering for is people who have heard of or seen Fermi questions.

A while back, someone's interviewing experience got posted to HN and they mentioned that they got asked to design a URL shortening service maybe five times. They failed it the first couple of times and got progressively better each time. I doubt the interviewers meant to measure whether or not this person had done enough interviews to catch on to the style of questions that are currently trendy, but that's what they actually measured.

I think the most common objection to this is that the point of these questions is to drill down and figure out how the person really thinks, but in empirical studies on interviewing, they find the actual evaluation of chatty questions like this is heavily influenced by all kinds of biases. Techniques that have more clear-cut evaluation criteria, like work sample tests, and even completely non-technical interviews like behavioral interviews end up being better filters. Even then, the filtering isn't "good" (IIRC, the last time I read one of those studies, work sample tests score the best, and had a correlation of around .5 with an ideal filter), but it's better.

For these kinds of questions, even if you haven't seen the specific question before, there's all sorts of interview gamesmanship that helps tremendously. One thing in the blog post, not spending an hour on requirements gathering, is an example of that. In real life, if you're going to write an application from scratch, spending more than an hour on requirements gathering is perfectly reasonable for a lot of problem domains. But if you're playing the interview game, you know that you have, at most, an hour to sketch out the entire problem, so you have to cut the requirements gathering phase short (but not too short). The post mentions that this gets at real skills. That's true. It does. The problem is that everyone who's seen this kind of question five times is going to be good enough at the interview gamesmanship that they don't need to have good real skills to breeze through the "don't spend too long talking about requirements" sub-filter.

I was never quite sure whether the 'waiting for input inside elevator' actually existed, because every once in a while the elevator would get summoned by someone else before I could give it a destination when inside.

I guess this is a bit off-topic, it's just to say that even very simple logic can solve the problem, in a possibly infuriating way. ;)

Are they? I think they have analogies in task schedulers. You have things like fairness guarantees (maximizing number of trips made or people moved is not ideal, as that could keep someone waiting for an elevator for weeks), livelock (elevators being stuck on short trips between floors 1 and 2 with people waiting forever on floor 55), elevator/CPU affinity (if we know it is highly likely that the person on floor 14 wants to go to floor 7, we might not let the elevator going past it to floor 3 stop at 14, but schedule the elevator now a few floors higher that we knew will stop at 7 stop there instead, but if we are fairly sure he wants to go to floor 6, where the elevator is going anyways, we might want the first elevator to stop there)

For the "ground floor in the morning" thing, task schedulers can switch behavior, too, for example by detecting the difference between batch-like and GUI-like programs. Extreme example (probably far-fetched): in embedded systems, the task scheduler could even know, say, when Wall Street opens, and make sure the cron task that should run then is paged in when it does.