[cursork]

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.

[nostrademons]

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.

[CPLX]

And someone who says "duh it shows the Google homepage" is destined for the executive team.

[brownbat]

The executive answer begins "It connects you with the world, but moreso, connects us all as a society..."

(This answer continues for two hours.)

[ibmthrowaway218]

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.)

[AtmaScout]

The word 'synergy' will also be used numerous times.

[tough-crowd]

Haha because executives are long winded.

[flomo]

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?"

[bkeroack]

If your interview question has a correct answer, it's probably the wrong question.

[nostrademons]

It's quite acceptable - often a good idea - for the correct answer to a question to be another question.

[rasz_pl]

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.

[cbr]

    Google cluster identifies you even when you are not
    logged in and browse in private mode with no cookies

Source?

[mynameisvlad]

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.

[cbr]

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.

[rasz_pl]

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.

[jwatte]

I would be surprised if Google didn't use per-ip reputation and targeting at some level of their stack.

[jwatte]

Note that browser fingerprinting is a good thing for those fighting online fraud (such as credit card chargebacks.)

[jacquesm]

Credit card chargebacks are not always fraud.

[throwawaykf05]

> 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.

[eru]

I sat in on someone who gave this question an half hour treatment on all levels. Lots to learn.

[tdaltonc]

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.

[izolate]

I really enjoyed your first paragraph. You seem to have quite a large spectrum of knowledge in the tech world.

[Florin_Andrei]

> 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.

[johnchristopher]

What kind of job description could those different profiles have answered to find themselves in the same waiting room ?

[Devthrowaway80]

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.

[cgb_]

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.

[Devthrowaway80]

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.

[senorprogrammer]

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.

[cbd1984]

> 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

[astrojetsonjr]

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.

[simpleigh]

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.

[sanderjd]

> 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.

[yen223]

This question is better than the cliched "bad" interview question because the answer is actually relevant to a software engineer's work.

[cursork]

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.

[phil21]

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.

[wting]

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.

[cursork]

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.

[lambda]

> 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.

[jwoah12]

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.

[lambda]

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.

[minaguib]

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.

[sfeng]

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.

[baddox]

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.

[emirozer]

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.

[senorprogrammer]

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.

[girvo]

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.

[cozuya]

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.