> We used it once with the caveat that "there's no right answer, we don't really know every step either, lets see what happens".

Better might be, "We're not implementing every layer, or at least not right now. Give me a good overview of everything you think is relevant." You get to test technical knowledge and people skills that way.

Ideal would be a really good college lecture; less ideal would be someone who knows the topic but belabors every point, because they don't have a feel for what's actually important. A brain-dump of pure trivia is a sign of someone who doesn't understand the broad overview. We don't need blab school students anymore.

http://en.wikipedia.org/wiki/Blab_school

Umm, I teach at a well known East Coast school that name starts with a "D". First night of the Internetworks - TCP/IP class I do this in the second 90 min part of the lecture. There is a ton of stuff from ARP resolves, DNS, BGP connections, NAT at your local router, HTTP request / responses, etc. While I'm an EE and can do the electron level BS, there is more than enough to cover on the software side.

Take away from the first night are: Open protocols are good Many hands (software layers) make light work It is just amazing that it works at all... :)

Lots of lectures / labs, including learning how to use Wireshark and ripping apart protocols.

The penultimate class is us reproducing that lecture with what they've learned. I think I resent the Blab school remark. They don't parrot back but they understand the parts.

And we still think it's amazing it works at all.

I agree with this completely. I think the point of all interviews should be to start a conversation - and the sort of broad technical conversation this question inspires is a really good way to see both what candidates know and how they communicate it.

I've had candidates fail to explain the distinction between the client and the server. I had one candidate exclaim "I hoped you'd ask this" and jump straight into a discussion on the parsing of cache-control headers by proxy servers.

> it's only bad if you, as the interviewer, have a specific answer in mind.

This is true of all interview questions. The goal is to get a sense of how a candidate thinks about things and works through problems. Asking a sequence of clarifying questions is a huge part of that, and very similar to the process of requirements gathering in day to day work.

This question is better than the cliched "bad" interview question because the answer is actually relevant to a software engineer's work.

That's only superficially the same. There's questions and there's "let's work through this" questions. The latter are awesome when explicitly stated as such and can be (should be?) as hard as you want to make them - I find I learn from them whatever happens.