Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The other thing the question tests for is rigidity of thinking.

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.



> If you're a backend database guy, talk about how Google must run a query against a massively sharded database

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.


>the whole web is stored in RAM

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.


Bingo, you're hired. When do you want to start? Er.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: