You can answer the question - pick whatever part of the stack you're familiar with and explain what's going on there. If you're a web developer, talk about how the browser loads the HTML for the page, then pulls out the <link rel=stylesheet> tags and fetches CSS for them, then executes any <script> tags. It sees a <form> tag, then an <input type="text">, and uses that to render the query box. If you type and that and hit submit, it loads the page in the <form>'s action attribute.

If you're a desktop software guy, talk about how Windows dispatches a WM_KEYDOWN event, which the browser's event loop picks up. It then initiates an HTTP request and renders Windows controls for every HTML element on the page.

If you're a backend database guy, talk about how Google must run a query against a massively sharded database to look up the terms you just entered and fetch document URLs for each of them. It then merges the query results to AND your query terms together, and return them.

Note that all of these answers are completely wrong (and basically the only way I could know this is because I worked on Google Search and actually know how it works). Google.com inlines styles into a single <style> tag; there are no <link> stylesheets, because we found the latency of the HTTP request outweighs the cache savings. I know less about how Windows works, but I wouldn't be surprised if under Windows7 and .NET the Win32 API is an emulation layer, and I know that most of the elements in modern browsers have no OS analogue and are rendered in shadow DOM via the browsers own box-and-painting mechanism. And there are no databases involved in Google; the whole web is stored in RAM and queries are matched & scored against everything (this itself is an oversimplification, but I'm limited to public information in what I can disclose...)

It doesn't matter. The point of the question is to get you to reveal what you know. If you don't reveal anything, you fail. Most people, when faced with a problem that they don't know the answer to, shut up and don't do anything. For a lot of tech companies, you want to hire people who will move forward and do something, even if it's wrong, because you'll have more information to course correct with a wrong solution than with no solution.

Apropos of nothing, I hadn't realized that "shard" in reference to databases had made its way beyond MMOs, and I think it's hilarious.

Ultima Online pioneered the MMO concept of using different copies of the game world, each with their own server and backing database, to partition a large player base into manageable chunks. These were called "shards" in reference to the shards of the evil wizard Mondain's Gem of Immortality, which was shattered at the end of the original 1980 Ultima and caused problems in later games. The word was informally used for later MMOs' servers, and apparently it's now formally used for horizontal database partitions.

So, if anyone asks you what a "shard" is in a database context, I recommend you start by telling them about the terrible legacy of the wicked sorcerer Mondain.

Whoa wait, that can't be totally true? The full text of everything is in RAM? Not just the indexes and whatnot? I guess the textual information is a small fraction of the total bytes, and some clever compression would make it possible, but wow.

So even at Google scale, some problems are already possible just to put in RAM. (The original Page rank paper spent a bit taking about aiming for 1 seek per lookup.. And my own multi billion record lookup system also found that to be the biggest latency.. But even I'm dealing with at least a TB a day of mostly text protocols and am happy to get the rough indexes into RAM.)

Wow.

I really struggle to believe that a competent software developer would be unable to answer this question with some degree of accuracy. It's not like it's a networking question - it's fantastically open-ended and covers everything from hardware, operating systems, networking, GUIs... and that's useful flexibility. On top of that, it's useful to help judge communication skills - engineers must be able to clearly express ideas, understand the audience that they're communicating with, and be able to discuss and reason with other engineers.

I would not hire an engineer who was not able to answer this question.

Let's see. I've done flight software. I've done cancer statistic software for the NIH. I've done autonomous robots and UAV. I've done drones. I've done weapons systems for the military. I've done mapping applications back on 486 machines with 16 bit software (hard to be responsive in that environment). I've design/built/debugged circuit boards. I've disassembled compilers and sent bug reports back to the manufacturer. I've done machine vision and computer vision. I've done simulation, solved partial differential equations, built bayesian filters.

But, you know, I haven't had to do anything significant with resolving google.com. I mean, I know that it resolves to something like 145.234.34.45, I know there is a difference between TCP and UDP, and a few other things, but I pretty much just need to open sockets once in a while. I'm pretty much the goto person for hard problems whereever I've worked. I've written articles, and am writing a book.

How does not knowing some specific fact make me unhirable?

"there are no good engineers". Well, I guess there is one, since one person was able to answer the question.

You are actively answering the question here - this is exactly the sort of thought process and reasoning that would be required. There are no specific facts - that's the point. And I can help but feel you've missed that.

Does this make you unhireable? No, not if you're upfront about it - "I haven't done much networking." OK, well given your work history I'm sure I could buy you a book or two and you'd be able to pick it up with no problems. That said, if the job was for a network engineer, you might not be at the top of the list. Or maybe you would be, who knows? I think a GOOD interviewer wouldn't pass you over because of one question.

Am I unhireable as a drone engineer because I'd have to look up some basics of computer vision, control systems or other domain-specific stuff? No, probably not - I've done very well in a lot of different technical roles and I have a strong background in mathematics. That said, if you and I were up for the same job, I wouldn't be holding my breath for an offer letter.

Nobody can know everything about anything. Smart interviewers understand that. People who don't aren't people you want to work with anyways.

Sure, if you are a dedicated embedded device programmer who has never used a web browser or engaged in networking of any kind, then maybe you like unaccountably not be able to construct a compelling description of the process. But I find that unlikely; all I can suggest is that if you are hiring for such a position, then a similar question more tilted towards a particular field would be equally useful.

The overall idea of an open-ended question like this is sound.

Most people fail pretty much any technical question you can imagine. It's unreal.