15 ms·

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 d

• senorprogrammer 12y ago
  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.
  • simpleigh 12y ago
    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.
  • cursork 12y ago
    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.
  • sanderjd 12y ago
    > 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 12y ago
      This question is better than the cliched "bad" interview question because the answer is actually relevant to a software engineer's work.
  • cbd1984 12y ago
    > 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 http://en.wikipedia.org/wiki/Blab_school
    • astrojetsonjr 12y ago
      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.
• baddox 12y ago
  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.
• nostrademons 12y ago
  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 12y ago
    And someone who says "duh it shows the Google homepage" is destined for the executive team.
    • brownbat 12y ago
      The executive answer begins "It connects you with the world, but moreso, connects us all as a society..." (This answer continues for two hours.)
      • AtmaScout 12y ago
        The word 'synergy' will also be used numerous times.
      • ibmthrowaway218 12y ago
• emirozer 12y ago
  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 12y ago
    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 12y ago
      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 12y ago
      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.
• wting 12y ago
  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 12y ago
    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 12y ago
      > 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.
• sfeng 12y ago
  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.
• minaguib 12y ago
  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.
• Devthrowaway80 12y ago
  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_ 12y ago
    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.
    • deleted 12y ago
• phil21 12y ago
  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.