“What happens when you type Google.com into your browser and press enter?”(github.com)
github.com
“What happens when you type Google.com into your browser and press enter?”
https://github.com/alex/what-happens-when
135 comments
> that there seems to be an infinite number of ways to split some kinds of systems
Indeed、you can even go to the electron level to describe what's happening in the circuitry and how it interacts with the silicon to propagate signals... it's never ending.
Indeed、you can even go to the electron level to describe what's happening in the circuitry and how it interacts with the silicon to propagate signals... it's never ending.
Good point. Reading this article, it also crossed my mind that the level of detail is always arbitrary. There is no "right" level of detail, that explains everything. We can keep going infinitely more into detail, explaining each step in more and more detail.
This article could just as well have included an explanation of how and why electrons travel from one point to another, or "the quantum effects that govern this" (a figurative example).
A metaphor for this that references the world of electronics is the ability to always increase the resolution of a display. We can keep going on, although the human eye might not be able to pick up a difference after a certain point.
Perhaps there is also a limit to the usefulness of increasing the level of detail in an explanation, as this article does, just as there's a limit to the usefulness of increasing display resolution.
This article could just as well have included an explanation of how and why electrons travel from one point to another, or "the quantum effects that govern this" (a figurative example).
A metaphor for this that references the world of electronics is the ability to always increase the resolution of a display. We can keep going on, although the human eye might not be able to pick up a difference after a certain point.
Perhaps there is also a limit to the usefulness of increasing the level of detail in an explanation, as this article does, just as there's a limit to the usefulness of increasing display resolution.
I would really like to know what happens when Im driving down a highway at say 60mph and browsing the web on my smartphone (or well let's say my wife is doing the driving and Im browsing the web :-) ). What kind of communication is happening between me and the cellphone towers? What data is my phone sending to the different cellphone towers as I drive by them? How does the cellphone tower send that data to the internet?
Does someone have a good pointer to a resource that would answer these questions?
Almost everything is exactly the same as on your desktop computer. The only thing that's different is what goes on under your TCP/IP layers.
Your Phone has a modem built in, that modulates a digital signal over a carrier wave at a certain frequency (set of frequencies, depending on the channel access protocol) the modulated carrier wave is sent out to the cellphone tower.
When the modem is supposed to receive, when it's allowed to send, how it negotiates these things is all strictly defined by protocols the telecom industry has standardized on. I can't say I'm an expert on these protocols, there's a whole bunch of them. They are grouped in protocol stacks with familiar names like GPRS, EDGE, UMTS, LTE.
These protocols besides making optimal use of their available bandwidth taking into account all kinds of noise, disturbances, moving from tower to tower, other phones also specify how the communication should be encrypted.
The encoding/decoding of these protocols is usually done by an integrated circuit in your phone that's separate from the rest of the phone's functionality, to prevent you from tampering with it (and to ensure reliability I guess). So all your phone's general operating system has to do is interface with that circuit to get neat IP packets.
Your Phone has a modem built in, that modulates a digital signal over a carrier wave at a certain frequency (set of frequencies, depending on the channel access protocol) the modulated carrier wave is sent out to the cellphone tower.
When the modem is supposed to receive, when it's allowed to send, how it negotiates these things is all strictly defined by protocols the telecom industry has standardized on. I can't say I'm an expert on these protocols, there's a whole bunch of them. They are grouped in protocol stacks with familiar names like GPRS, EDGE, UMTS, LTE.
These protocols besides making optimal use of their available bandwidth taking into account all kinds of noise, disturbances, moving from tower to tower, other phones also specify how the communication should be encrypted.
The encoding/decoding of these protocols is usually done by an integrated circuit in your phone that's separate from the rest of the phone's functionality, to prevent you from tampering with it (and to ensure reliability I guess). So all your phone's general operating system has to do is interface with that circuit to get neat IP packets.
Like tinco said, above TCP/IP it's pretty much the same as on your desktop. If you want to know about TCP/IP and below, I suggest this title: "From GSM to LTE-Advanced: An Introduction to Mobile Networks and Mobile Broadband".
http://www.amazon.com/From-GSM-LTE-Advanced-Introduction-Bro...
http://www.amazon.com/From-GSM-LTE-Advanced-Introduction-Bro...
Jiminy crickets!
Well, once you get past the interrupt stuff, the handset establishes a pdp context.... How many people can afford to hire deep mobile hackers?
Well, once you get past the interrupt stuff, the handset establishes a pdp context.... How many people can afford to hire deep mobile hackers?
Can't remember how many jobs I did where the interview questions were the hardest part of the job. In the beginning you think wow I'm going to get a nice and existing job.
Just to be dissapointed again because the job consists of fixing bugs in crappy legacy code and writing CRUD code.
Just to be dissapointed again because the job consists of fixing bugs in crappy legacy code and writing CRUD code.
It frustrates me that it just goes "Interrupt fires".
There's a whole lot that goes on between the USB bus receiving the packet and HID driver - I mean, even making the processor branch is non-trivial.
There's a whole lot that goes on between the USB bus receiving the packet and HID driver - I mean, even making the processor branch is non-trivial.
It's a WIP. Scroll down and you'll see a lot more similar headings. The ellipsis is to indicate that the section is incomplete. Perhaps you can contribute?
I don't know the details of that section myself - I'd love to find out, hence my disappointment that it wasn't there.
On the network level, seems to have missed the ARP protocol entirely. Didn't seem to mention the function of the multiple routers between client and server, the calculations of netblock and subnet mask, role of firewalls between client and host, etc, etc.
Probably missing off the top of my head at least 100 steps. If you sat down to write a paper on it he's probably missing closer to 1,000 discrete units of work in the overall process.
Probably missing off the top of my head at least 100 steps. If you sat down to write a paper on it he's probably missing closer to 1,000 discrete units of work in the overall process.
I agree. Fork it, flesh out those details and submit a pull request. I get the feeling this is very much a work in progresses.
>USB bus receiving the packet
its not really receiving packets, its receiving data _you specifically requested in YOUR packet_. in USB only host is capable of generating traffic on the bus, your device cant generate any packets, only answer to them.
its not really receiving packets, its receiving data _you specifically requested in YOUR packet_. in USB only host is capable of generating traffic on the bus, your device cant generate any packets, only answer to them.
And this is exactly the sort of thing that I wish it included, so I could learn about it.
It's complex, I know it's complex, and I want to know what actually happens at that awkward fuzzy boundary between hardware and software.
It's complex, I know it's complex, and I want to know what actually happens at that awkward fuzzy boundary between hardware and software.
I needed a break so I used this as an excuse to try to remember how Windows actually handled keyboard input. I submitted a pull request:
https://github.com/alex/what-happens-when/pull/21
https://github.com/alex/what-happens-when/pull/21
[deleted]
[deleted](1)
Wouldn't it be more convenient for people to contribute if this were set up as a wiki?
Lots of interesting things happen in between your computer and Google's servers - like ISPs exchanging routing information using BGP, so the routers can determine a route through each different AS (provider/transit network) it has to go through to actually Fong the machine with that IP, and the kinds of physical and data layers it goes through (cable or DSL, fibre, and Ethernet, SONET/SDH, maybe tunnelling over MPLS at some point) etc.
Maybe it's a test to see how well you can communicate? I would of given a very brief high level overview, such as...
A request is sent to Google's severs for their "new search" page. Google then responds with the necessary data in order for your Web browser to display the Web page . There's a lot more to the full story, but I can go into detail if you would like.
I would offer diving into the important parts related to the position.
A request is sent to Google's severs for their "new search" page. Google then responds with the necessary data in order for your Web browser to display the Web page . There's a lot more to the full story, but I can go into detail if you would like.
I would offer diving into the important parts related to the position.
People look at you strangely and explain how browser URL bars search for you in all recent browsers, making the Google homepage irrelevant.
Maybe they explain how home pages and bookmarks and bookmarklets work and set one up for you.
Nobody explains anything technical; the sort of person who types Google.com into a URL bar in 2015 isn't very computer literate, and wouldn't care about the details - any details.
Maybe they explain how home pages and bookmarks and bookmarklets work and set one up for you.
Nobody explains anything technical; the sort of person who types Google.com into a URL bar in 2015 isn't very computer literate, and wouldn't care about the details - any details.
This would make a great subject for a book, along the lines of NAND2Tetris, starting at the transistor level or below.
I have asked this question (more or less,) and the point is to get the candidate to singer point where they don't know the answer, and then the real question comes: "so how would you design that next piece?" That's the interesting part!
Lack of arp/layer 2 isp, routing.
There is also a mistake inside the DNS part. DNS queries are done from the client - and this is actually true for a majority of client/server requests - by opening a dynamic random port above 49152.
There is also a mistake inside the DNS part. DNS queries are done from the client - and this is actually true for a majority of client/server requests - by opening a dynamic random port above 49152.
Wow, judging from the comments in here, there are a lot of people that are in management positions that are horrible judges of technical ability and value. This question asks so many things that it doesn't really ask anything at all. No matter which field they decide dive into, if they can dive into any at all, it sheds no light whatsoever on their ability to solve problems, or their ability to learn new difficult concepts. Moreover, making assumptions about where their specialties lie because of the topic they chose to answer in is wrong--if they answered well, they could be skilled in many other topics as well, and if they didn't, that doesn't mean they're incompetent--it means they didn't know how to answer what is essentially a trick question.
>it sheds no light whatsoever on their ability to solve problems, or their ability to learn new difficult concepts.
This is of course correct; one way to check for these is to ask specific questions for prior job experience; however the top-dog companies like to hire promising graduates right out of college and so they don't wish to cut them off by asking these questions.
This is of course correct; one way to check for these is to ask specific questions for prior job experience; however the top-dog companies like to hire promising graduates right out of college and so they don't wish to cut them off by asking these questions.
I prefer to ask open-ended questions more calculated to give me an idea of where the interviewee's head is at:
"What's your favorite programming language? Why?"
"What's your favorite programming language? Why?"
His emphasis on lower level protocols is not what I would expect a python programmer.
I wonder what the following would say about me in an interview situation...
Device specific rendering. Localization and Language logic. Image download and display. Screen rendering. Caching, cookies & browser history. Analytics integration. Account lookup. The search being saved on the backend.
I wonder what the following would say about me in an interview situation...
Device specific rendering. Localization and Language logic. Image download and display. Screen rendering. Caching, cookies & browser history. Analytics integration. Account lookup. The search being saved on the backend.
I'd like to see a detailed description of sockets work.
The first part is already outdated. A lot depends on the browser. Chrome will look up stuff as you type it, and by the time you press <enter>, the DNS lookup will likely have happened already. And, likely, the actual request to the page.
It's probably even more complicated than that, I believe "google.com" is a very special case in Chrome.
It's probably even more complicated than that, I believe "google.com" is a very special case in Chrome.
> The keyboard controller then encodes the keycode for transport to the computer. This is now almost universally over a Universal Serial Bus (USB) connection, but historically has been over PS/2 or ADB connections.
What about Bluetooth keyboards?
What about Bluetooth keyboards?
Ooh, now we can add a big section on EMR, wireless protocols, forward error checking, the possibilities are endless!
Nah, it always ends with Maxwell's equations.
Love it! One of my favourite bad interview questions. I got asked this in an interview ~5 years ago. My response was to look shocked... Pause. Then ask: "What do you mean? What detail do you need? DNS? SYN / ACK? HTTP?"
At the point I started talking about syn/acks they just cut me off and moved on to the next question.
Same company (different person) started the phone screen with 'oh so your CV says you know linux, what's the difference between a hard link and a soft link' and was shocked when I knew the answer, declaring the rest of the phone interview pretty pointless - he'd obviously had a bad morning and started with his hardest question.
I've now learnt to see such interview questions as a sign of a workplace with little-to-no learning on the job. Most places that actively encourage learning don't try such things.
At the point I started talking about syn/acks they just cut me off and moved on to the next question.
Same company (different person) started the phone screen with 'oh so your CV says you know linux, what's the difference between a hard link and a soft link' and was shocked when I knew the answer, declaring the rest of the phone interview pretty pointless - he'd obviously had a bad morning and started with his hardest question.
I've now learnt to see such interview questions as a sign of a workplace with little-to-no learning on the job. Most places that actively encourage learning don't try such things.
That's part of the point of the question - which part you go into detail on is a pretty good indication where your strengths lie. Someone who spends a lot of time on DNS and SYN/ACK is probably a low-level networking guru, and the rest of the interview should be structured accordingly. Someone who immediately jumps into HTTP requests, HTML parsing, and stylesheet application is probably a web developer, and the rest of the interview should be structured accordingly. Someone who talks about the enter key firing off an interrupt that the keyboard device driver handles and puts into a message queue for the windowing system's event loop to handle is a low-level desktop OS person. Someone who talks about the browser retrieving the event from the window loop, dispatching it the urlbar's hwnd, and kicking off an HTTP request is a Windows application programmer.
The advantage of this over just looking at someone's resume is that you can tease out areas of strength beyond someone's particular work experience, so that if eg. you get someone who's been stuck doing Win32 programming his whole life but has managed to teach himself a bunch of web technologies on his own time, he can talk intelligently about the browser's style rendering. It can also identify areas of cross-training, eg. the bulk of my professional experience is in web development, but I know enough about how the other layers of the stack work to write this comment.
The advantage of this over just looking at someone's resume is that you can tease out areas of strength beyond someone's particular work experience, so that if eg. you get someone who's been stuck doing Win32 programming his whole life but has managed to teach himself a bunch of web technologies on his own time, he can talk intelligently about the browser's style rendering. It can also identify areas of cross-training, eg. the bulk of my professional experience is in web development, but I know enough about how the other layers of the stack work to write this comment.
What if I can go from matrix scanning algorithm used by keyboard controllers firmware, usb descriptors used (hierarchy, order, meaning of fields, direction), kernel (usb driver, keyboard driver), system (windows keyboard event), program (event loop, logic, tons of stuff here to decide what to do), back to system (dsn query, cache or network driver), network(can start on 4th osi layer and go all the way to 1) .... up to the part how mighty Google cluster identifies you even when you are not logged in and browse in private mode with no cookies, concluded by the statement that clicking enter begins your adventure of being a product Google sells? Every step of the way from sub 10 millisecond (usb polling, in reality nothing happens when you press enter :P) up to three months in the future (Googles earning report).
edit: Doh, finally clicked on github link, and its just what I wrote, but crowd sourced.
edit: Doh, finally clicked on github link, and its just what I wrote, but crowd sourced.
Google cluster identifies you even when you are not
logged in and browse in private mode with no cookies
Not saying that Google itself does this (I doubt it, honestly), but browser fingerprinting does exist and your browser is, more than likely, unique:
https://panopticlick.eff.org
It isn't entirely unconceivable that a site may use browser fingerprinting to track you even when not signed in by associating your unique browser fingerprint to your account.
https://panopticlick.eff.org
It isn't entirely unconceivable that a site may use browser fingerprinting to track you even when not signed in by associating your unique browser fingerprint to your account.
I agree that it's possible. I would be extremely surprised if Google were doing this, however, so I'm interested in why rasz_pl thinks they are.
ex googlers startup
http://www.technologyreview.com/news/508176/get-ready-for-ad...
browser fingerprinting is old school and almost outdated by now
All Google needs is few hours of your online activity to associate a fresh newly installed system / browser / ip with a trace of crumbs you usually leave on the network, your 'online routine' - often visited pages, order of visits, time of day, time stamps, all thanks to ever present adsense. Not to mention everything you type in the Chrome address/search bar is reported back to the mothership one letter+timestamp at a time in the name of instant search/autosuggestions/autocomplete (keystroke dynamics), Google knows most common mistakes we make when entering urls/words (limited stylometry), Google has a whole warehouse of stylometry data inside gmail.
Everyone is doing it, Google, FB, Amazon all have acres of server farms grinding such data. Google even offers free DNS servers just to collect more of it. Small companies offer free url shorteners, image hosting, all great sources (who you share with, how popular you are, how far it reaches, for how long). Six degrees of separation etc, everyone wants to know your interests, ip, os, browser, email, phone numbers, address, friends, contacts, social graph influence. The more data sources the easier to correlate and aggregate. Just an example of visible usage - Amazon will give you different price depending on who it 'thinks' you are.
http://www.technologyreview.com/news/508176/get-ready-for-ad...
browser fingerprinting is old school and almost outdated by now
All Google needs is few hours of your online activity to associate a fresh newly installed system / browser / ip with a trace of crumbs you usually leave on the network, your 'online routine' - often visited pages, order of visits, time of day, time stamps, all thanks to ever present adsense. Not to mention everything you type in the Chrome address/search bar is reported back to the mothership one letter+timestamp at a time in the name of instant search/autosuggestions/autocomplete (keystroke dynamics), Google knows most common mistakes we make when entering urls/words (limited stylometry), Google has a whole warehouse of stylometry data inside gmail.
Everyone is doing it, Google, FB, Amazon all have acres of server farms grinding such data. Google even offers free DNS servers just to collect more of it. Small companies offer free url shorteners, image hosting, all great sources (who you share with, how popular you are, how far it reaches, for how long). Six degrees of separation etc, everyone wants to know your interests, ip, os, browser, email, phone numbers, address, friends, contacts, social graph influence. The more data sources the easier to correlate and aggregate. Just an example of visible usage - Amazon will give you different price depending on who it 'thinks' you are.
associate a fresh newly installed system / browser / ip
with a trace of crumbs you usually leave on the network
Everyone is doing it, Google, FB, Amazon all have acres
of server farms grinding such data.
Google even offers free DNS servers just to
collect more of it.
Amazon will give you different price depending on who
it 'thinks' you are.
[1] https://developers.google.com/speed/public-dns/privacy [2] http://abcnews.go.com/Technology/story?id=119399
> "Google Public DNS does not permanently store personally identifiable information."
That depends on their (possibly very narrow) definition of which information is personally identifiable.
That depends on their (possibly very narrow) definition of which information is personally identifiable.
And someone who says "duh it shows the Google homepage" is destined for the executive team.
The executive answer begins "It connects you with the world, but moreso, connects us all as a society..."
(This answer continues for two hours.)
(This answer continues for two hours.)
Or:-
"That's a great question! I think the best way to answer it is..."
(This answer continues for two hours without actually answering the question posed.)
"That's a great question! I think the best way to answer it is..."
(This answer continues for two hours without actually answering the question posed.)
The word 'synergy' will also be used numerous times.
Haha because executives are long winded.
> That's part of the point of the question - which part you go into detail on is a pretty good indication where your strengths lie. Someone who spends a lot of time on DNS and SYN/ACK is probably a low-level networking guru, and the rest of the interview should be structured accordingly.
Hmm, interesting, I had not thought of it that way. I'd probably start talking about the debouncing logic in the keyboard microcontroller, but I'd not want to be pegged as an embedded systems guy, because I could talk about all the other layers as well. If I run into this question I think I'd just ask what level of detail and which areas the interviewer would like to focus on.
Hmm, interesting, I had not thought of it that way. I'd probably start talking about the debouncing logic in the keyboard microcontroller, but I'd not want to be pegged as an embedded systems guy, because I could talk about all the other layers as well. If I run into this question I think I'd just ask what level of detail and which areas the interviewer would like to focus on.
I sat in on someone who gave this question an half hour treatment on all levels. Lots to learn.
[deleted]
> Someone who talks about the enter key firing off an interrupt that the keyboard device driver handles and puts into a message queue for the windowing system's event loop to handle is a low-level desktop OS person.
Or someone with a background in electronics.
Or someone with a background in electronics.
I really enjoyed your first paragraph. You seem to have quite a large spectrum of knowledge in the tech world.
At least in my line of work, the big gist of that question is: "Can this person summarize a technical issue in a comprehensible way for the audience? e.g. So that it could be passed through various sales teams and project managers, but is still sensible when it lands in the client engineer's inbox?"
The correct answer starts along the lines of "How hard should I geek out?"
The correct answer starts along the lines of "How hard should I geek out?"
If your interview question has a correct answer, it's probably the wrong question.
It's quite acceptable - often a good idea - for the correct answer to a question to be another question.
What kind of job description could those different profiles have answered to find themselves in the same waiting room ?
I started thinking about the sensory transduction in the right pinky that culminates in the prediction of a class of visual gestalt in the temporoparietal junction.
It might be frustrating for you personally because you know so much that you could talk for hours about what happens, from keyboard interrupts to DNS to HTTP(s) and what-have-you, but in the absence of a personal recommendation, interviewers have to operate under the assumption that any and all claims of knowledge/experience/skill are suspect. I have interviewed people who claimed to have "deep algorithm design experience" who could not articulate what a set is, "network experts" who hadn't heard of NAT, and several "top graduates from a respected CS program" who froze when asked to talk about some basic tree operation.
If you'd responded to the question with the shocked response above, I'd probably have said "don't worry about it, let's pick X and Y" and mentally marked you as having knocked the question out of the park.
I can't stress enough how little the average applicant knows, regardless of how long they've been in the industry. It's helpful to have these questions as some sort of filter if you're looking to hire into a more-senior role, because many people either lie or obliviously overestimate their skills.
That said, if I was interviewing for a junior position and they bombed the question, I'd probably just make a mental note to buy them a copy of TCP/IP Illustrated when they came onboard or something.
If you'd responded to the question with the shocked response above, I'd probably have said "don't worry about it, let's pick X and Y" and mentally marked you as having knocked the question out of the park.
I can't stress enough how little the average applicant knows, regardless of how long they've been in the industry. It's helpful to have these questions as some sort of filter if you're looking to hire into a more-senior role, because many people either lie or obliviously overestimate their skills.
That said, if I was interviewing for a junior position and they bombed the question, I'd probably just make a mental note to buy them a copy of TCP/IP Illustrated when they came onboard or something.
Agree, and it's an opportunity for the candidate to demonstration their knowledge on whatever level they think is appropriate.
Interviewing is not about just showing you know x, y, z, it's largely a demonstration of your ability to communicate.
And the weaker candidates tend to get hung up on this question as being 'too simple' or confused about what level of detail they need to be supplying. Umm, look at the job description, tailor your answer, inform the panel you can elaborate further on something you're strong with, but avoid waffling on about irrelevant (to the position) technical detail. That's a bad thing in my book.
I think crucially, good candidates know what they don't know and have no problem communicating that. Weaker candidates feel pressure to "know everything" (impossible) and the moment they open their mouth with vague or incorrect responses, they become a risk if employed because when confronted professionally with something they don't know much about, they are more likely to try and wing it rather that stop and fill their knowledge gap or seek assistance from colleagues.
Interviewing is not about just showing you know x, y, z, it's largely a demonstration of your ability to communicate.
And the weaker candidates tend to get hung up on this question as being 'too simple' or confused about what level of detail they need to be supplying. Umm, look at the job description, tailor your answer, inform the panel you can elaborate further on something you're strong with, but avoid waffling on about irrelevant (to the position) technical detail. That's a bad thing in my book.
I think crucially, good candidates know what they don't know and have no problem communicating that. Weaker candidates feel pressure to "know everything" (impossible) and the moment they open their mouth with vague or incorrect responses, they become a risk if employed because when confronted professionally with something they don't know much about, they are more likely to try and wing it rather that stop and fill their knowledge gap or seek assistance from colleagues.
[deleted]
Yes, the communication aspect of it is huge as well. You might well be posed vaguely defined questions all the time in your work. If you get upset and/or are unable to start picking out the most important aspects of a question, that's a problem.
I'm not so sure it's a bad interview question. Or rather, perhaps it's only bad if you, as the interviewer, have a specific answer in mind.
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". We collaborated with them, it was great, and by the end of the conversation were pretty certain we wanted to keep the conversation going by hiring them.
Set your expectations accordingly, I suppose.
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". We collaborated with them, it was great, and by the end of the conversation were pretty certain we wanted to keep the conversation going by hiring them.
Set your expectations accordingly, I suppose.
> 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
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.
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.
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 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.
As an interviewer of entry-level technical ops folks (think datacenter tech who we hope to train to become junior sysadmins) I love this question. Hiring a high-end network engineer or developer? I'll only ask if it they are otherwise struggling, as to gauge if the interview should even continue.
> I've now learnt to see such interview questions as a sign of a workplace with little-to-no learning on the job. Most places that actively encourage learning don't try such things.
I strongly disagree with this statement. The folks who we hire starting out in ops nearly always get asked this question, and the responses vary drastically. That 19 year old kid in community college that can nail it down to the TCP level means they are pretty much hired instantly (at least based on technical chops and interest in the field), and many of those types have grown into very senior level roles in the company.
I will make the caveat that this has to be a discussion between a highly technical interviewer and the interviewee. It being asked by an HR type is pointless.
The other reason why I love the question? It's important and extremely relevant to the job in question. When a customer submits a ticket, it's nice for the front-line folks to be able to identify a problem likely to be on the browser, dns, network, or server layer.
You would also be surprised at how many otherwise supposedly "experienced" interviewees have no clue.
> I've now learnt to see such interview questions as a sign of a workplace with little-to-no learning on the job. Most places that actively encourage learning don't try such things.
I strongly disagree with this statement. The folks who we hire starting out in ops nearly always get asked this question, and the responses vary drastically. That 19 year old kid in community college that can nail it down to the TCP level means they are pretty much hired instantly (at least based on technical chops and interest in the field), and many of those types have grown into very senior level roles in the company.
I will make the caveat that this has to be a discussion between a highly technical interviewer and the interviewee. It being asked by an HR type is pointless.
The other reason why I love the question? It's important and extremely relevant to the job in question. When a customer submits a ticket, it's nice for the front-line folks to be able to identify a problem likely to be on the browser, dns, network, or server layer.
You would also be surprised at how many otherwise supposedly "experienced" interviewees have no clue.
Could you expand into why you think this question is indicative of a workplace with "little-to-no learning" on the job?
I ask this question to new grad candidates with no expected answer in mind. The goal is to establish some level of technical competency and discover the candidates' interests. Do they talk about kernel, network, backend, frontend, etc?
The percentage of candidates who can spend more than 1 minute answering is abysmally low. If I get a curt response I'll follow up with relevant questions to the position they're applying for.
I ask this question to new grad candidates with no expected answer in mind. The goal is to establish some level of technical competency and discover the candidates' interests. Do they talk about kernel, network, backend, frontend, etc?
The percentage of candidates who can spend more than 1 minute answering is abysmally low. If I get a curt response I'll follow up with relevant questions to the position they're applying for.
Yes. My experience of hiring is that it is extremely hard and imprecise. I prefer to give the candidates every advantage possible. I would help them to the extent of my abilities in a work situation, so I see no use in being unnecessarily difficult in an interview. It's a bad signal.
Maybe it's just my experience, but the more 'forgiving' style of interview has tended to result in a better work environment.
There are some situations where you do want to hire someone who 'knows it all' already. In which case, fire away with these challenges. But they're not needed for the 99% case.
Not a direct response, but expanding my thoughts slightly:
1. I know many highly able programmers who wouldn't know how to respond given so many options. These 'tricky' questions just aren't good for some personality types.
2. Everyone talking about it showing what you're interested in is 100% wrong in my case. I am not interested in TCP, DNS, etc. I know the details because at some point I've needed to debug something at that level. I'd hate being pigeon-holed just because I happen to know one thing.
3. There are much simpler ways to discover 'basic competence'. Getting candidates to translate a basic algorithm to pseudo-code even.
Maybe it's just my experience, but the more 'forgiving' style of interview has tended to result in a better work environment.
There are some situations where you do want to hire someone who 'knows it all' already. In which case, fire away with these challenges. But they're not needed for the 99% case.
Not a direct response, but expanding my thoughts slightly:
1. I know many highly able programmers who wouldn't know how to respond given so many options. These 'tricky' questions just aren't good for some personality types.
2. Everyone talking about it showing what you're interested in is 100% wrong in my case. I am not interested in TCP, DNS, etc. I know the details because at some point I've needed to debug something at that level. I'd hate being pigeon-holed just because I happen to know one thing.
3. There are much simpler ways to discover 'basic competence'. Getting candidates to translate a basic algorithm to pseudo-code even.
> Yes. My experience of hiring is that it is extremely hard and imprecise. I prefer to give the candidates every advantage possible.
Yes, I agree that hiring is hard and imprecise. I generally try to ask questions on a variety of different topics, to make sure that I can find where their strengths are; if they are weak in one or two areas, that can generally be worked around, but if they come off weak in 3 or more of the areas, I generally feel that it would be too much of a risk and take too much time to bring them up to speed.
> I would help them to the extent of my abilities in a work situation, so I see no use in being unnecessarily difficult in an interview
Do you really consider this question unnecessarily difficult? I find that it's one of the easiest, that someone without even programming knowledge but with a good technical background should be able to answer.
> I know many highly able programmers who wouldn't know how to respond given so many options
If someone doesn't know where to start, I give them a prompt; "just focus on the networking level". If they start but miss something, I ask a follow up question to clarify that "so how does it know what IP address to contact?" When I ask a question like this, I'm not trying to be tricky, but trying to ask a question that should involve knowledge that just about every competent programmer should have, and see how well they can break it down, explain it, stop at the part where their knowledge runs out rather than making things up or guessing.
I've had people guess on this question, completely getting it wrong when I ask something like "and so what is the difference between TCP and UDP", and I find that even worse than just saying "I don't know how that part works"; if someone knows what they don't know, they will know when to ask questions, but if they just make stuff up to try to make themselves sound more knowledgeable, I don't know if I could ever trust their knowledge or judgement because it could be based on them just covering up a lack of knowledge about something.
> Everyone talking about it showing what you're interested in is 100% wrong in my case. I am not interested in TCP, DNS, etc. I know the details because at some point I've needed to debug something at that level.
Yeah, I don't ask this question to tell what someone's interested in. I ask it to determine (a) if they have enough experience that they have done at least some looking into how the stack works enough to discuss it intelligently and (b) whether they are capable of breaking down and explaining a complex piece of technology with several interacting parts.
For the jobs I'm hiring for, understanding the basics of how the network works is pretty much a requirement. If someone doesn't know how DNS and TCP work, asking them to debug a complex performance problem with a distributed filesystem communicating with dozens of clients over a 40 G backend network and 10 G frontend is probably going to be asking a bit much of them. Even for the more basic application development tasks, almost everything we do touches the network somehow.
And if someone does actually discuss the details of input getting from the keyboard into the kernel, and from there into the browser, and it handling the event, and so on, then that does provide me with information that they know that portion of the stack well; I don't expect everyone to know everything, but I do want people who are interested enough to at least have some basic knowledge of how the fairly complex system that they use on a day to day basis works.
> > Yes. My experience of hiring is that it is extremely hard and imprecise. I prefer to give the candidates every advantage possible.
Yes, I agree that hiring is hard and imprecise. I generally try to ask questions on a variety of different topics, to make sure that I can find where their strengths are; if they are weak in one or two areas, that can generally be worked around, but if they come off weak in 3 or more of the areas, I generally feel that it would be too much of a risk and take too much time to bring them up to speed.
> I would help them to the extent of my abilities in a work situation, so I see no use in being unnecessarily difficult in an interview
Do you really consider this question unnecessarily difficult? I find that it's one of the easiest, that someone without even programming knowledge but with a good technical background should be able to answer.
> I know many highly able programmers who wouldn't know how to respond given so many options
If someone doesn't know where to start, I give them a prompt; "just focus on the networking level". If they start but miss something, I ask a follow up question to clarify that "so how does it know what IP address to contact?"
> There are much simpler ways to discover 'basic competence'. Getting candidates to translate a basic algorithm to pseudo-code even.
Yes, you would not use this as a sole interview question. This should generally be used as one of several. My basic screen consists of: write up a basic algorithm in pseudocode, compare and contrast data structures and running times for a couple of basic tasks, the "what happens when I enter google.com into my browser and press enter" question, a question on designing a class hierarchy for modelling a particular problem, a question on debugging where I lead them through a problem I've actually had to debug and see what kinds of suggestions they make about things to look for and ways to figure out what's going on, and then an actual coding problem where I expect them to provide real code to solve a simple problem.
I don't expect everyone to be an expert on all of these. Some people haven't ever taken a formal algorithms and data structures course, or it's been 20 years since they did so, so they haven't really thought about asymptotic running time in a long time. That's OK, as long as they do well on the others. Or some people may not know much about networking, but are strong in the other areas; that's fine too.
But if someone doesn't know much about networking, or algorithms, can't design an appropriate class hierarchy and interface, and can't really offer very good suggestions for how they would debug a problem that we encounter variations of fairly often here, I wonder whether they really are going to be able to contribute effectively. Or if they can talk a lot about the data structures and networking, but then fail at actually writing pseudocode to solve a basic algorithmic problem (and I'm talking very basic, like you should be able to do this in a CS 101 class) or fail at actually producing working code for the simple coding problem, I feel like they may have some good domain knowledge but don't actually have the skills necessary to actually contribute.
Yes, I agree that hiring is hard and imprecise. I generally try to ask questions on a variety of different topics, to make sure that I can find where their strengths are; if they are weak in one or two areas, that can generally be worked around, but if they come off weak in 3 or more of the areas, I generally feel that it would be too much of a risk and take too much time to bring them up to speed.
> I would help them to the extent of my abilities in a work situation, so I see no use in being unnecessarily difficult in an interview
Do you really consider this question unnecessarily difficult? I find that it's one of the easiest, that someone without even programming knowledge but with a good technical background should be able to answer.
> I know many highly able programmers who wouldn't know how to respond given so many options
If someone doesn't know where to start, I give them a prompt; "just focus on the networking level". If they start but miss something, I ask a follow up question to clarify that "so how does it know what IP address to contact?" When I ask a question like this, I'm not trying to be tricky, but trying to ask a question that should involve knowledge that just about every competent programmer should have, and see how well they can break it down, explain it, stop at the part where their knowledge runs out rather than making things up or guessing.
I've had people guess on this question, completely getting it wrong when I ask something like "and so what is the difference between TCP and UDP", and I find that even worse than just saying "I don't know how that part works"; if someone knows what they don't know, they will know when to ask questions, but if they just make stuff up to try to make themselves sound more knowledgeable, I don't know if I could ever trust their knowledge or judgement because it could be based on them just covering up a lack of knowledge about something.
> Everyone talking about it showing what you're interested in is 100% wrong in my case. I am not interested in TCP, DNS, etc. I know the details because at some point I've needed to debug something at that level.
Yeah, I don't ask this question to tell what someone's interested in. I ask it to determine (a) if they have enough experience that they have done at least some looking into how the stack works enough to discuss it intelligently and (b) whether they are capable of breaking down and explaining a complex piece of technology with several interacting parts.
For the jobs I'm hiring for, understanding the basics of how the network works is pretty much a requirement. If someone doesn't know how DNS and TCP work, asking them to debug a complex performance problem with a distributed filesystem communicating with dozens of clients over a 40 G backend network and 10 G frontend is probably going to be asking a bit much of them. Even for the more basic application development tasks, almost everything we do touches the network somehow.
And if someone does actually discuss the details of input getting from the keyboard into the kernel, and from there into the browser, and it handling the event, and so on, then that does provide me with information that they know that portion of the stack well; I don't expect everyone to know everything, but I do want people who are interested enough to at least have some basic knowledge of how the fairly complex system that they use on a day to day basis works.
> > Yes. My experience of hiring is that it is extremely hard and imprecise. I prefer to give the candidates every advantage possible.
Yes, I agree that hiring is hard and imprecise. I generally try to ask questions on a variety of different topics, to make sure that I can find where their strengths are; if they are weak in one or two areas, that can generally be worked around, but if they come off weak in 3 or more of the areas, I generally feel that it would be too much of a risk and take too much time to bring them up to speed.
> I would help them to the extent of my abilities in a work situation, so I see no use in being unnecessarily difficult in an interview
Do you really consider this question unnecessarily difficult? I find that it's one of the easiest, that someone without even programming knowledge but with a good technical background should be able to answer.
> I know many highly able programmers who wouldn't know how to respond given so many options
If someone doesn't know where to start, I give them a prompt; "just focus on the networking level". If they start but miss something, I ask a follow up question to clarify that "so how does it know what IP address to contact?"
> There are much simpler ways to discover 'basic competence'. Getting candidates to translate a basic algorithm to pseudo-code even.
Yes, you would not use this as a sole interview question. This should generally be used as one of several. My basic screen consists of: write up a basic algorithm in pseudocode, compare and contrast data structures and running times for a couple of basic tasks, the "what happens when I enter google.com into my browser and press enter" question, a question on designing a class hierarchy for modelling a particular problem, a question on debugging where I lead them through a problem I've actually had to debug and see what kinds of suggestions they make about things to look for and ways to figure out what's going on, and then an actual coding problem where I expect them to provide real code to solve a simple problem.
I don't expect everyone to be an expert on all of these. Some people haven't ever taken a formal algorithms and data structures course, or it's been 20 years since they did so, so they haven't really thought about asymptotic running time in a long time. That's OK, as long as they do well on the others. Or some people may not know much about networking, but are strong in the other areas; that's fine too.
But if someone doesn't know much about networking, or algorithms, can't design an appropriate class hierarchy and interface, and can't really offer very good suggestions for how they would debug a problem that we encounter variations of fairly often here, I wonder whether they really are going to be able to contribute effectively. Or if they can talk a lot about the data structures and networking, but then fail at actually writing pseudocode to solve a basic algorithmic problem (and I'm talking very basic, like you should be able to do this in a CS 101 class) or fail at actually producing working code for the simple coding problem, I feel like they may have some good domain knowledge but don't actually have the skills necessary to actually contribute.
I'm curious how long your screen generally lasts. In my hour-long phone screens there's barely enough time to cover a coding question and a few basic data structures/knowledge questions. I feel like covering everything you laid out would take several hours.
I try to keep it within an hour, but sometimes go over, up to an hour and a half.
I usually have the final question, writing real working code, be something that the candidate does offline using a real editor and being able to test it out, and email me the result afterwards, as we're usually low on time by that point and many people are more comfortable doing that in a real editor, being able to test out their code, etc. However, it turns out that the last question can be done as a one-liner shell script (it has one little tricky bit that make the simplest one liner shell script you might write not quite work properly, but it's possible to work around that), so some people are able to just do that online with me during the screen.
I generally keep the screen moving quickly, giving people prompts and hints to get past parts they're stuck on to keep things moving, and when I say I'm asking basic questions, they are really quite basic. My experience has been that people who actually pass the screen generally complete it within the hour, while people who are struggling are the ones who take longer.
I usually have the final question, writing real working code, be something that the candidate does offline using a real editor and being able to test it out, and email me the result afterwards, as we're usually low on time by that point and many people are more comfortable doing that in a real editor, being able to test out their code, etc. However, it turns out that the last question can be done as a one-liner shell script (it has one little tricky bit that make the simplest one liner shell script you might write not quite work properly, but it's possible to work around that), so some people are able to just do that online with me during the screen.
I generally keep the screen moving quickly, giving people prompts and hints to get past parts they're stuck on to keep things moving, and when I say I'm asking basic questions, they are really quite basic. My experience has been that people who actually pass the screen generally complete it within the hour, while people who are struggling are the ones who take longer.
I really enjoy asking that question when interviewing people, followed by "in as much or as little detail as you'd like".
This typically happens 3/4 of the way in, and allows me to peek and poke quite a bit - it also allows the interview, if it hasn't already, to switch from a rigid process to a fluent organic discussion.
This typically happens 3/4 of the way in, and allows me to peek and poke quite a bit - it also allows the interview, if it hasn't already, to switch from a rigid process to a fluent organic discussion.
I think answering it with a general overview, and then optionally going into more detail based on feedback from the person you're explaining it to is actually a pretty important life skill for an engineer. Going into the weeds immediately is not great when you're communicating with people at a different skill level than yourself.
I think in certain contexts it could be a reasonable interview question. I think it could work well as a "here's a general topic, speak intelligently on it for a couple of minutes" question. You could even ask it for jobs completely unrelated to programming or computer networking.
I completely agree with your last statement and I would like to add that i think any question that can be answered by a 'single' google search provides absolutely no valuable information to the interview process.
I'm going to disagree with this only because it comes down to the intent of the interviewer. If they're looking for a boolean right/wrong answer then you're absolutely correct. Feel bad for the interviewer who asks such things thinking they're being clever (and believe me, I've suffered through those interviews).
Instead, if it's the starting point of a conversation then hell, bring Google into it. Use that topic to figure out if the candidate is someone who converses well, thinks well, googles well, bullshits well, ultimately is it someone your team would want to continue working with.
Contrast that approach to something like FizzBuzz, which really affords no avenues for interesting conversation and the difference becomes apparent.
Instead, if it's the starting point of a conversation then hell, bring Google into it. Use that topic to figure out if the candidate is someone who converses well, thinks well, googles well, bullshits well, ultimately is it someone your team would want to continue working with.
Contrast that approach to something like FizzBuzz, which really affords no avenues for interesting conversation and the difference becomes apparent.
I had an interview where the interviewer began describing a problem he wanted me to solve. About 3 seconds into it I exclaimed, "Oh, you want me to implement FizzBuzz" and so he stopped explaining the problem and said not to bother with it.
huh? I think there's a lot of interesting (relatively) conversation that can come from fizzbuzz. The whole "is aware of the modulus operator or not" thing is an easy one, but there's also the whole loop & print vs loop through a function that returns debate and also string building with plus equals vs flat output type stuff. Those are all pretty obvious and could cause some illuminating discussion from a candidate.
"I don't normally watch github projects, but when i do, it's projects like these :D "
Computerphile made a good vide on the same subject ~a month ago called "What Happens When You Click a Link?" [1]
It is obviously not as deep in content as the article is aiming to be, specially because it focus only on the first things that happens like DNS resolving and the socket connection, however, it is still fun video.
[1] https://www.youtube.com/watch?v=keo0dglCj7I
It is obviously not as deep in content as the article is aiming to be, specially because it focus only on the first things that happens like DNS resolving and the socket connection, however, it is still fun video.
[1] https://www.youtube.com/watch?v=keo0dglCj7I
There is also a very good introductory answer in this subject by Jean-Baptiste Quéru in 2013 [1] where he takes the revers approach of when the page is displayed, then talks about connection, OS, etc. "simplifying" the answer and going down several levels of abstraction and complexities to give the proper overwhelming sense that this question should impose.
It is a very fun text to read and I really recommend it.
[1] https://plus.google.com/u/0/+JeanBaptisteQueru/posts/dfydM2C...
It is a very fun text to read and I really recommend it.
[1] https://plus.google.com/u/0/+JeanBaptisteQueru/posts/dfydM2C...
When I first read the headline I thought of this post as well, my instinct was that someone had pasted it into a Gist but it seems like a collaborative project to make an even more detailed answer. Which is neat.
Came here to recommend that post also. Probably the best thing I've ever seen on Google+.
I hope people don't study this. The answer to this question doesn't matter.
The whole point of this question is to (1) gauge the clarity of the candidate's communication when explaining complex systems and (2) have them get to a place where they simply doesn't know and must start making assumptions of how things work and weigh the various tradeoffs. That's where things get interesting.
The whole point of this question is to (1) gauge the clarity of the candidate's communication when explaining complex systems and (2) have them get to a place where they simply doesn't know and must start making assumptions of how things work and weigh the various tradeoffs. That's where things get interesting.
I didn't know this was so popular of a question. I've been asking it for many years. I love it because anyone with expertise in any part of the system should be able to answer it. Are you a networking guru? If so, you should be able to talk a long time about the network bits. Are you a kernel guru? Same. Etc. It also gives me a good idea how broad the interviewee is.
It is always amazing to me how many people fail the question so badly. I've really had only one person answer it reasonably in all these years.
It is always amazing to me how many people fail the question so badly. I've really had only one person answer it reasonably in all these years.
So, everyone fails and you think it is a good question? That doesn't make a lot of sense to me.
I can't reasonably answer the question, because I haven't really needed to know it. When I need to know it, I'll learn it, and quickly. How is that question a good measure of me if you are not hiring me to architect a router or something where it pertains?
I could ask you questions in my domain that you'd be hopeless at answering. But I wouldn't, because it would be a horrible measure of you.
I can't reasonably answer the question, because I haven't really needed to know it. When I need to know it, I'll learn it, and quickly. How is that question a good measure of me if you are not hiring me to architect a router or something where it pertains?
I could ask you questions in my domain that you'd be hopeless at answering. But I wouldn't, because it would be a horrible measure of you.
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.
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.
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.
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.
The parent clearly said "so many people" and not "everyone" - that's a really important difference!
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.
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.
He said "really had only one person answer it reasonably in all these years ". Are we going to quibble about this wording?
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.
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.
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.
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.
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.
I could talk about this question for hours. You probably wouldn't want me building an autonomous robot or drone unless it was covered in pillows and safely contained far away from children and combustible liquids.
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.
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.
You're not unhirable, but if you applied for a senior web systems/operations position on my team, you probably wouldn't be hired. It's not because you're not a smart guy, but you don't have the experience we're looking for. Seems pretty easy to understand.
Also, if your resume says you're a web systems person or something like that, and you can't actually explain some details about DNS is doing, I have to wonder about the mismatch...
Context is important. My team is a web systems team. I wouldn't expect someone that has written flight software to know the answers. I would expect someone that is advertising themselves as a senior web developer or web systems guy to.
It's not about the specific answers - it's about being able to reasonably construct a model about how a system might work, based on the knowledge you do have, and clearly communicate that model (including its limitations!) to another engineer.
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.
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.
My usual "Pass" answers end up being something specific to the stack a good .net developer should know, with a mutual agreement of just how awesome it is to think about the smallest steps and finding out how deep - even if in hobby terms - that person's drive to understand it is. There's no rattling off a "freebie" answer to it.
The majority of applicants fail Fizzbuzz. It is a shitty question in the sense that it doesn't give you any information about whether you should hire somebody, but it does serve to send a very strong "don't hire" signal.
Most people fail pretty much any technical question you can imagine. It's unreal.
Most people fail pretty much any technical question you can imagine. It's unreal.
Even something as simple as the images and rectangles composited in hardware/software with Skia would take a thesis to explain.
the time-to-live value for a datagram reaches zero at which point the packet is dropped
Someone should write a Victorian-style novel on the hard, short, but virutous life of a packet.
Someone should write a Victorian-style novel on the hard, short, but virutous life of a packet.
Or a multilevel story-within-a-story type where the browser tells the HTTP server a story about an OS who tells a story about keyboard interrupts and network packets and so on.
>17.78 mA of this current is returned on either the D+ or D- pin (the middle 2) of the keyboard's USB connector.
Oh, so we will look at it at THAT level of detail, nice.
Then hardware interrupts, seems ok...
Then HSTS and DNS, yeah, no, you are skipping like 3 more pages of things that happen in between. Good luck with your naive experiment.
Oh, so we will look at it at THAT level of detail, nice.
Then hardware interrupts, seems ok...
Then HSTS and DNS, yeah, no, you are skipping like 3 more pages of things that happen in between. Good luck with your naive experiment.
Isn't that the point of having others help and fill in the gaps? What's the point of belittling it to a "naive experiment"?
My browser runs on a smartphone with a software keyboard. Instant smug assumption fail.
So far, nobody has filled in the section on how a key-press event works its way through the OS, up to the window system, to the application, and to the code handling the input text box.
Then there's what's happening at the Google end. Before search personalization, popular queries ("google", "Britney Spears") were handled by caches the first Google machine you talked to, and never even reached the search engine. Since search personalization, there's some cookie traffic, and then your personal dossier is retrieved from storage at Google for use in interpreting your query.
Then, in the middle, your query probably travels through five to ten routers (try a traceroute) just to get to Google. Packets move from local Ethernet or WiFi to DSL to fiber to bigger fiber to gigabit Ethernet within a Google data center.
And where is "google.com" for you? That's hard to find out. For me, today, it's at "nuq04s19-in-f14.1e100.net", wherever that is. My connection routed from Silicon Valley to Santa Rosa to San Jose before reaching a Google point of presence at Equinix in San Jose.
Somebody also needs to talk about what's happening in the CPUs, with 3 billion or so instructions per CPU core every second, all devoted to looking up a cat video for you.
When you play a cat video, more computation occurs than was done in the history of the world prior to 1940.
Then there's what's happening at the Google end. Before search personalization, popular queries ("google", "Britney Spears") were handled by caches the first Google machine you talked to, and never even reached the search engine. Since search personalization, there's some cookie traffic, and then your personal dossier is retrieved from storage at Google for use in interpreting your query.
Then, in the middle, your query probably travels through five to ten routers (try a traceroute) just to get to Google. Packets move from local Ethernet or WiFi to DSL to fiber to bigger fiber to gigabit Ethernet within a Google data center.
And where is "google.com" for you? That's hard to find out. For me, today, it's at "nuq04s19-in-f14.1e100.net", wherever that is. My connection routed from Silicon Valley to Santa Rosa to San Jose before reaching a Google point of presence at Equinix in San Jose.
Somebody also needs to talk about what's happening in the CPUs, with 3 billion or so instructions per CPU core every second, all devoted to looking up a cat video for you.
When you play a cat video, more computation occurs than was done in the history of the world prior to 1940.
"So far, nobody has filled in the section on how a key-press event works its way through the OS, up to the window system, to the application, and to the code handling the input text box."
That in itself is a multi-year discussion. From silicon chemistry theory, voltage biasing different types of substrates, the definition of ground, all the way to sofware control loops, eventing, software emulating parallellism, all the things happening and just waiting to happen on a single OS before you even press "g" on the keyboard will blow most people's minds away.
That in itself is a multi-year discussion. From silicon chemistry theory, voltage biasing different types of substrates, the definition of ground, all the way to sofware control loops, eventing, software emulating parallellism, all the things happening and just waiting to happen on a single OS before you even press "g" on the keyboard will blow most people's minds away.
I submitted a PR that got merged that covers a bunch of what happens from the kernel up to the app, for Windows.
> So far, nobody has filled in the section on how a key-press event works its way through the OS, up to the window system, to the application, and to the code handling the input text box.
Heck USB was glossed over. That section alone should be at least 3x longer!
Heck USB was glossed over. That section alone should be at least 3x longer!
There's a whole lot of BGP and stuff like that on the interconnect, too.
BGP, and usually some internal routing protocol on each end of the ASN path (likely something like OSPF). But those only inform the forwarding tables, they aren't an active component of the request. You could always go into the forwarding logic of the routers and switches as it moves through the network and TCAMs/DRAM.. As others mentioned, it's practically endless.
plus, with personalization, wouldnt you think dns lookups happen before you press enter. by the time you press enter, it should already have completed all the dns steps.
By far my favorite question to ask (and be asked) in an interview. As others point out, it's practically impossible to understand the entire system. At one point or another in my career I've been exposed to at least descriptions of most of the components, but if I wanted a processor engineer, I'd be looking for a different answer than a web developer, or a networking guy, etc. Essentially anyone involved in the modern world of IT has to be able to answer something they're good at - and more importantly, admit the parts they don't understand. You can't cheat your way through the question, hell, you could even know it's coming and you still can't "beat" it. You don't know if I'm looking for hyper-detail about something, business sense to skip over irrelevant (to the position) details of a certain level, etc.
An experienced developer is almost certainly going to start by asking you more questions, trying to find out what your expectations are.
That's not to say that you wouldn't gain SOMETHING, nor that it's a bad interview question. I actually like it. It's just not terribly productive, in an engineering sense.