Interviewing, tough questions, and things you actually know
Years ago, I had to face a three-on-one technical interview. It was conducted in a tiny little room with a table just big enough to fit the three of them on one side and little old me on the other. They started drilling me on all sorts of technical trivia.
Fortunately for me (and them), I had encountered nearly all of the situations they asked about. How do you set up an e-mail address to go to more than one place with sendmail? I knew that. How do you have a@domain1 and a@domain2 on the same box go to two different places? I knew that too. It's all of the stuff you want a web support monkey to know if at all possible, but it's also things you could easily learn if you were so inclined.
Still, out of all of the answers I gave, the one which stuck with them the longest and made it into interviewing lore at that company was one I didn't know. It was an Apache question, and they wanted to know what "UseCanonicalName" did. I told them the truth: I had never used it, and really didn't even know it existed, and so I didn't know.
But, I continued, and I said, okay, let's think this one through. Based on the name of it, and the kind of business you guys are in, I bet I can give you a guess. You guys do web hosting, and that probably means you run load balancers to allow more than one machine to actually serve up pages. So, you probably have a hostname/IP called "www" pointed at the load balancer box, and then there are Linux machines called "www1", "www2", "www3" and so on behind it.
Now, when one of those machines generates an error page and puts the host name at the bottom, or (more likely) it makes a 301 or 302 redirect or similar, it needs to use a host name. You don't want it to expose the inner workings of your site by using its actual host name like www1. So, you say "use this other name instead", and that way it pretends to be www even though it really isn't.
This way, you don't get users who find themselves "stuck" to just one of your web heads depending on which one they hit initially. That's bad, because what if it dies, or gets too many hits relative to the others, or whatever. Also, it looks messy, and if you have cookies bound to the www.blah, it won't get them. There's a lot which can go wrong.
But I said, that's just a guess. I don't know for sure.
They didn't let on right then and there, but months later, long after I had started at that job, I was hearing people talk about that interview question and how it had been answered. Apparently one person called it a "textbook answer", even though I was honestly guessing based on first principles and how that config directive happened to be named.
I've been on the other side of this, too. I used to ask people who claimed TCP/IP networking experience how certain diagnostic tools worked. Some of them would come right out and say they didn't know. I accepted that, but then I'd start asking them how they would build something which does that same task. In some cases, it turns out they knew enough of the fundamentals to get there anyway, but just didn't realize it.
People like that are hidden gems. They were just convinced somewhere along the line that they don't know certain things, even when they really do. Bringing out that shine is always worth the trouble.