What answer (or maybe what kind of answer) are you looking for? The correct answer depends on too many variables: from protocol used to network configuration. Do you have a particular number of seconds in mind or are you interested in the process that the candidate goes through to answer this question?

I want to hear the entire thought process so I can discern how much the candidate really knows. If I was asked this question, I would say obviously the theoretical limit is 80 seconds (provided you use raw data with no compression) and there is no way it could be done any faster. Add to that frame + packet + TCP overhead, delays due to ack/handshaking + latency, packet loss and the download takes longer. Also, speed is influenced by MTU / Jumbo Frames settings, TCP window sizes, and tuning options.

I would have accepted the answer even if the candidates were slightly wrong or off the mark on any of these. Instead I got answers from "ummmmm" and "less than 1 second" to "35 minutes" and "it's impossible to answer this question." Like _delirium said, the basic answer is available on Google so it wasn't a single right/wrong answer that I wanted, of course that would help. I just wanted to hear them think this problem through. I even broke down the problem for them and told them 1 byte = 8 bits. So 10 MB = 10 million bytes and 10 Mbps = 10 million bits per second. sigh

This isn't just a random interview question by any means. I have a solid reason to ask this - we have hosted Exchange from Rackspace and because of how Terminal Server works, we have to use it in non-cached mode. My users use Outlook but it works pretty much like any web-based mail app does - every email is downloaded each time you click on it. It is worse because browsers can at least cache attachments. So a user who gets a 10MB file gets mad at me because it takes 30 seconds to download it. If the new IT person can't understand and explain why that happens, how can they determine the solution to this problem?

Well, yeah - 100/10 * 8 bits in a byte in theory, longer depending on what else you've got going on at each end.

I share your surprise at the poverty of results - it seems so obvious I thought it was a trick question, or else that you were trying to scam your way through a phone interview (before I clicked on the discuss link). And to think I'd shy away from that job because I'm not up to speed with installation and configuration best practices any more...in my mind nobody has any business applying for such a job unless they can write shell scripts while half asleep.

Can you expand on the sort of candidates you're getting? Like, do you think they only took a few classes in a commercial college or 'learned' their stuff from a certification book? I wonder because of a recent tale of woe from someone about software QA staff with such a robotic approach to their work that they didn't seem to understand the basic concept of 'know what the product does and why you would misuse it to test error handling'. Also curious what the position pays, if you can reveal that.

The scary thing is that the candidates are very well qualified and have extensive background in this very field. I think the problem is that all of them have worked in teams where one person does the planning/thinking and the rest just do the grunt-work. I need someone with good problem-solving skills. I don't even care about their past experience, credentials, or accomplishments. I want to know if they can figure stuff out when things go wrong. If they can do that, then they can help take away 40% of my current workload. Otherwise I have 100% of my work + babysit someone else.

Too bad I'm on the opposite coast or I'd drop in :) Good luck finding the right person - this is as good a place to look as any.

You've gotta be kidding me -- no, I know you aren't.

I'm nothing approaching a network admin, and the deductive process and factors you mentioned immediately occurred to me.

This reminds me of a (failed) Rational toolset deployment I suffered under some years ago. TPTB decided they were going to support users in India from a U.S. installation. I argued for testing with one or another form of network simulation, but I got nowhere. Sure enough, they deployed, and the thing was unusably slow. The Rational tools involved wanted to touch files and DB (very) repeatedly for each action. Latency killed performance under these circumstances.

I guess your story heartens me, a bit. I get to the point of feeling under-experienced particularly as, on paper, I may look under-credentialed. But in practice, as often as not I'm the one posing the difficult and pertinent questions.

Amusingly, Google can answer such questions: http://www.google.com/search?q=100+megabytes+divided+by+10+m...

Wolfram Alpha too http://www.wolframalpha.com/input/?i=100+Megabyte+at+10mbps

More amusing yet, both of those ignore (of course) transport overhead. In RS-232/dial-up days, that would be 20% worth of start/stop-bits (i.e. a byte of data requires 10 bits transmitted).

For my purposes (not a network admin), I still figure on 10 bps = 1 byte/s. Easier, and usually close enough, what with packet headers and network burps. So, 100MB*10b/10Mbps = 100 s.

P.S. just read OP's expansion on problem. I would recommend reading C.N.Parkinson's take on candidate search (ch. 5 of the Parkinson's Law book, e.g. http://www.02articles.com/read/parkinsons-law-chapter-5 ). If it does not actually help, at least you'll be amused.

P.P.S. searching for the above link, found this also amusing testimonial from a satisfied user: http://direkobold.blogspot.com/2009/04/parkinsons-law-for-hi...