“What happens when you type Google.com into your browser and press enter?”
github.com
github.com
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.
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.
(This answer continues for two hours.)
"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 correct answer starts along the lines of "How hard should I geek out?"
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
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.
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
That depends on their (possibly very narrow) definition of which information is personally identifiable.
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.
Or someone with a background in electronics.
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.
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.
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.
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.
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'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.
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.
> 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 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.
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, 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 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.
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.
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.
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.
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.
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.
It is a very fun text to read and I really recommend it.
[1] https://plus.google.com/u/0/+JeanBaptisteQueru/posts/dfydM2C...
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.
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.
Heck USB was glossed over. That section alone should be at least 3x longer!
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.
http://www.amazon.com/From-GSM-LTE-Advanced-Introduction-Bro...
Well, once you get past the interrupt stuff, the handset establishes a pdp context.... How many people can afford to hire deep mobile hackers?
Just to be dissapointed again because the job consists of fixing bugs in crappy legacy code and writing CRUD code.
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.
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.
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.
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.
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.
Deleted comment
What about Bluetooth keyboards?
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.
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.
You can answer the question - pick whatever part of the stack you're familiar with and explain what's going on there. If you're a web developer, talk about how the browser loads the HTML for the page, then pulls out the <link rel=stylesheet> tags and fetches CSS for them, then executes any <script> tags. It sees a <form> tag, then an <input type="text">, and uses that to render the query box. If you type and that and hit submit, it loads the page in the <form>'s action attribute.
If you're a desktop software guy, talk about how Windows dispatches a WM_KEYDOWN event, which the browser's event loop picks up. It then initiates an HTTP request and renders Windows controls for every HTML element on the page.
If you're a backend database guy, talk about how Google must run a query against a massively sharded database to look up the terms you just entered and fetch document URLs for each of them. It then merges the query results to AND your query terms together, and return them.
Note that all of these answers are completely wrong (and basically the only way I could know this is because I worked on Google Search and actually know how it works). Google.com inlines styles into a single <style> tag; there are no <link> stylesheets, because we found the latency of the HTTP request outweighs the cache savings. I know less about how Windows works, but I wouldn't be surprised if under Windows7 and .NET the Win32 API is an emulation layer, and I know that most of the elements in modern browsers have no OS analogue and are rendered in shadow DOM via the browsers own box-and-painting mechanism. And there are no databases involved in Google; the whole web is stored in RAM and queries are matched & scored against everything (this itself is an oversimplification, but I'm limited to public information in what I can disclose...)
It doesn't matter. The point of the question is to get you to reveal what you know. If you don't reveal anything, you fail. Most people, when faced with a problem that they don't know the answer to, shut up and don't do anything. For a lot of tech companies, you want to hire people who will move forward and do something, even if it's wrong, because you'll have more information to course correct with a wrong solution than with no solution.
Apropos of nothing, I hadn't realized that "shard" in reference to databases had made its way beyond MMOs, and I think it's hilarious.
Ultima Online pioneered the MMO concept of using different copies of the game world, each with their own server and backing database, to partition a large player base into manageable chunks. These were called "shards" in reference to the shards of the evil wizard Mondain's Gem of Immortality, which was shattered at the end of the original 1980 Ultima and caused problems in later games. The word was informally used for later MMOs' servers, and apparently it's now formally used for horizontal database partitions.
So, if anyone asks you what a "shard" is in a database context, I recommend you start by telling them about the terrible legacy of the wicked sorcerer Mondain.
Whoa wait, that can't be totally true? The full text of everything is in RAM? Not just the indexes and whatnot? I guess the textual information is a small fraction of the total bytes, and some clever compression would make it possible, but wow.
So even at Google scale, some problems are already possible just to put in RAM. (The original Page rank paper spent a bit taking about aiming for 1 seek per lookup.. And my own multi billion record lookup system also found that to be the biggest latency.. But even I'm dealing with at least a TB a day of mostly text protocols and am happy to get the rough indexes into RAM.)
Wow.
I really struggle to believe that a competent software developer would be unable to answer this question with some degree of accuracy. It's not like it's a networking question - it's fantastically open-ended and covers everything from hardware, operating systems, networking, GUIs... and that's useful flexibility. On top of that, it's useful to help judge communication skills - engineers must be able to clearly express ideas, understand the audience that they're communicating with, and be able to discuss and reason with other engineers.
I would not hire an engineer who was not able to answer this question.
Let's see. I've done flight software. I've done cancer statistic software for the NIH. I've done autonomous robots and UAV. I've done drones. I've done weapons systems for the military. I've done mapping applications back on 486 machines with 16 bit software (hard to be responsive in that environment). I've design/built/debugged circuit boards. I've disassembled compilers and sent bug reports back to the manufacturer. I've done machine vision and computer vision. I've done simulation, solved partial differential equations, built bayesian filters.
But, you know, I haven't had to do anything significant with resolving google.com. I mean, I know that it resolves to something like 145.234.34.45, I know there is a difference between TCP and UDP, and a few other things, but I pretty much just need to open sockets once in a while. I'm pretty much the goto person for hard problems whereever I've worked. I've written articles, and am writing a book.
How does not knowing some specific fact make me unhirable?
"there are no good engineers". Well, I guess there is one, since one person was able to answer the question.
You are actively answering the question here - this is exactly the sort of thought process and reasoning that would be required. There are no specific facts - that's the point. And I can help but feel you've missed that.
Does this make you unhireable? No, not if you're upfront about it - "I haven't done much networking." OK, well given your work history I'm sure I could buy you a book or two and you'd be able to pick it up with no problems. That said, if the job was for a network engineer, you might not be at the top of the list. Or maybe you would be, who knows? I think a GOOD interviewer wouldn't pass you over because of one question.
Am I unhireable as a drone engineer because I'd have to look up some basics of computer vision, control systems or other domain-specific stuff? No, probably not - I've done very well in a lot of different technical roles and I have a strong background in mathematics. That said, if you and I were up for the same job, I wouldn't be holding my breath for an offer letter.
Nobody can know everything about anything. Smart interviewers understand that. People who don't aren't people you want to work with anyways.
Sure, if you are a dedicated embedded device programmer who has never used a web browser or engaged in networking of any kind, then maybe you like unaccountably not be able to construct a compelling description of the process. But I find that unlikely; all I can suggest is that if you are hiring for such a position, then a similar question more tilted towards a particular field would be equally useful.
The overall idea of an open-ended question like this is sound.
Most people fail pretty much any technical question you can imagine. It's unreal.
Probably should update the title before people starting submitting PRs in a doomed attempt to "not skip on anything".
Someone should write a Victorian-style novel on the hard, short, but virutous life of a packet.
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.
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.
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.
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.
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.
"What's your favorite programming language? Why?"
It's probably even more complicated than that, I believe "google.com" is a very special case in Chrome.
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.
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.