I hate this interview question. This question however would be a great intro to CS/CMPE in university, "What happens when you type google.com into your browser and press enter....well you'll be able to answer `most` of that by the end of your PHD Dissertation."
Agreed. It'd be terrible if it were being used to look for a "right" answer, but as a means of getting someone to talk about systems and processes so you can get a glimpse of their approach to things, I feel like it's really handy.
Just by quick browsing I see missing a lot of network and server-side: what if name server doesn't have domain record, routing protocols (BGP), what happens when request hits Google on their side, there's load balancer for sure -how do they work-, there's probably CDN -how do they work, anycast etc-, there's HTTP to HTTPS redirect...
This would be even cooler if you could expand a specific branch and continue going into further and further detail. IMO the TLS section would be one of the most interesting pieces, but it gets near-zero attention.
Cliche, but I've found this to be an amazing interview question for nontechnical positions. You learn quickly how much someone can hand wave and bullshit. If they are too cocky and can't say "I don't know", that's great to suss out up front. If it's for a sales role, maybe that's a good thing.
Regarding the DNS lookup, i recently noticed Chromium (OS X latest versions) connects to Google's public DNS servers a lot, even though i have a (working) local DNS server defined in /etc/resolv.conf :/
This is another one of those cliche questions along with "how do you build a URL shortener" and "what is a process" etc., that demonstrates a complete lack of originality of the interviewer. "Oh I have an interview, let me google some good questions. Seriously is there a list somewhere of these for lazy interviewers?
Why would originality be a concern, if the question is good and cannot be "prepared in advance"? I believe that the question is not meant to be asked without follow-ups, or deep dives in specific areas (maybe asking the candidate where they want to focus next). I agree that if the question is asked without entering a two-way discussion, then it's useless.
In the interest of a constructive discussion, why do you believe that a URL shortener is a bad interview question?
Would you really answer this way? Maybe they are trying to test communication skills, ie tell me what's only relevant. Can you imagine if you gave this answer to a product manager for a browser? Context people....
Here's your context, good sir: This is, for intensive porpoises, a page trying to go into as much detail as possible on a very mundane task. No, Actual People (tm) would not answer that way - but going deeper down the stack than usual is considered a form of geek amusement.
OT: Did you intentionally write "intensive porpoises" instead of "intents and purposes"? I can't work out if it was a sublte joke or genuine mistake. The mental image of intensive porpoises is hilarious
Good catch, I have indeed done so on purpose. My other favorite phrase to sneak into technical writing is "[this and this] needs to be done that way for hysterical raisins". Barely anyone notices.
I think these days Google.com is served as a web-application, so that adds some complexity to the whole question, for example, did you enter Google.com before? (probably, yes :-))
no need to speculate about this one; Jen from "IT Crowd" gave this dire warning during a presentation to the executive staff meeting (http://tinyurl.com/zsfuutd): "You...Can...Break...The...Internet."
As an interviewer, I love this question, but I don't have very good luck with it. My goal is for them to find the area they know the most about and tell me about it extreme detail. But the answer I always get is very short and broad, and never dives into anything.
I will probably modify the question to just ask about how the TCP/IP portion works, or just ask about how the HTML rendering portion works.
Yep, I find it to be a terrible proxy for the question, "Which parts of the HTTP request-response cycle interest you?" Please, please, please, if that is your question, just simply ask that question. It gives the interviewee the opportunity to steer the conversation in a useful direction (especially if the answer is "Well, I'm not really interested in the details of that, but let me tell you what I am interested in..." which would not be possible with the original question, without sounding rude).
The problem with the original question is that it masks your true question and makes it really difficult to understand what the discussion is about. If someone is used to answering questions succinctly, directly, and usefully (which are valuable traits in a productive engineering environment) then it's really difficult to formulate a clear answer on the spot, regardless of your depth of knowledge. The best response is probably the question, "Exactly which part are you interested in, and in relation to what kinds of problems?"
They give a broad answer to a broad question. It's not clear which details the interviewer wants or the amount of time that the interviewer wants you to spend on it.
That's nice, but you forgot to explain how electrical circuits work. Which ideally would have begun with with a rigorous statement of Kirchhoff's laws (and in particular how these are generalizations of Ohm's law, and corollaries of Maxwell's equations in the low-frequency limit).
We were also hoping to see you demonstrate at least a basic understanding of how modern semiconductors work, to a point where we could feel confident that you were at least reasonably conversant in the underlying language of solid state physics. If you really wanted to get our attention, you would have asked for extra time at the whiteboard to derive at least, say, the 1-soliton solution to the wave equation, and used the first few terms of the expansion series to obtain both elementary conserved quantities and additional non-trivial quantities using the invariance and multiplier approach based on the well-known result that the Euler-Lagrange operator annihilates to total divergence.
That is, you could have. But you didn't.
We thank you for taking the time to discuss this opportunity with us; but mind you, when we said we were looking for candidates with "strong CS fundamentals", we meant it. So unfortunately we'll be moving forward with other candidates, and we wish you the best of luck with your job search.
"What happens.... and give as much detail as you can" is how I phrase it. If the candidate tried to give this much detail, I'd stop them, congratulate them on their ability to Google, put a positive mark next to that and move on. Or not, as I've detected they're effectively plagiarising someone else's work. Depends on how far they go with it I suppose. It could go either way!
That said, if I let them completely hijack the interview, I'm failing as an interviewer. They're also failing as an interviewer, if they're actually willing to waste the entire time answering the question in full in that way, rather than recognising that the interview process is a two way street.
Either way, all this does is change the range of acceptable answers. Being aware this information has been collected in such a useful way is the important part. So again, Thanks!
> Or not, as I've detected they're effectively plagiarising someone else's work.
Ideally, if you're testing ability to research rather than domain-specific knowledge, they'd just send you a link to a really good explanation. No sense reinventing the wheel.
