17 ms·

2. What happens between you typing a URL into your browser address bar, hitting enter and seeing a web page? "What happens when I'm asked a question like X? I

• _jordan 9y ago
  regarding the database question: I hear it as: "Tell me how detailed your understanding is of database internals in a conversational format; here is a talking prompt to help..." regarding typing in the url question: "Tell me the level in which you understand networking protocols" In the real world I would hope these questions would be more of a discussion; "ah, you mention ACID, what kind of pattern can you employ to help implement that", "MVCC" etc.. This format of interview is hard to pass on simply regurgitation alone and does a pretty decent job of vetting technical understanding in a natural, conversational way.
  • methodover 9y ago
    The URL question is a really good one though. You should absolutely understand every step of that process if you're working on web applications. The database one is weird. You don't need to know how to create a good database system yourself in order to effectively use one, I think. Neither do you need to know how to make a web browser to know how HTTP requests work.
    • majormajor 9y ago
      Every step? Keyboard interrupts and the browser going from DOM to OS drawing APIs included? ;) Many of these questions are very vaguely scoped which gives the confident and familiar plenty of room to show how clever they are, but also makes it more intimidating for those who haven't seen them before. Or, to put it another way, the linked site looks like a great way to make yourself look like you have a junior-to-mid-level understanding of a lot of different areas. But the process it's optimizing for starts to break down the more senior a developer you either (a) are or (b) are trying to hire.
      • IncRnd 9y ago
        If it's a job to work on a haptic feedback system, they may very well want to plumb your understanding of when interrupts fire, without prompting for canned answers. If you're interviewing for a front end position, you can make a nod to interrupts and continue on with BGP, ARP, DNS, TCP, IP, routers, etc. If you want to show your knowledge of security you could mention heartbleed, poodle, or even say why this isn't vulnerable to shellshock. An overview will take a minute, and the interviewer will follow up with more targeted questions if needed. It's a chance for the candidate to shine.
        • majormajor 9y ago
          I think it's worth being aware that the more open-ended you make the question, the more you might freeze a less-practiced-at-interviewing candidate on not knowing where to start. I'm always ready when asking something very open ended to follow up after 15 seconds or so to say "let's talk about [area X] first." For URLs, maybe this is "let's talk about what the actual network request, if you sniffed the traffic, looks like."
          • IncRnd 9y ago
            That's perfectly reasonable. I interview candidates to let them shine not to fail them.
        • 9y ago
  • eradicatethots 9y ago
    Could you not just ask the direct question? Eliminate the nonsense..
    • IncRnd 9y ago
      Of course, but that isn't always as efficient. Candidates bone up on canned responses the weekend prior, and it's also good to see which candidates are independent learners. You'd be surprised how many senior developers freeze when they are asked to reverse a list using any language of choice.
      • SilasX 9y ago
        But since this is a standard one now, they can bone up on it too.
        • IncRnd 9y ago
          It's been a standard one for a long time, but many people have difficulty with it.
          • deleted 9y ago
            [deleted]
      • eradicatethots 9y ago
        I’m sure asking them the direct question won’t stop them from spewing out memorizes garbage. The better question is why you think that’s a good thing
        • IncRnd 9y ago
          Why do I think what is a good thing? Asking easy and qualifying questions upfront saves money for the company.
  • SilasX 9y ago
    This seems to happen every time the question comes up: 1) Everyone swears up and down that it's an absolutely vital, fair question. 2) Everyone justifies 1) by giving conflicting (to others' answers) criteria they're judging it by, such that no answer could possibly satisfy them all, except by saying something smart that impresses the interviewer and might not correspond to rigorous judgment criteria.
• methodover 9y ago
  > What are the things you should consider if you were writing your own database server? "How did I get to this situation? Why am I here? Why am I writing my own database system instead of using an existing one? Where should I leave my resignation letter? Should I give them two weeks notice or just quit right now?"
  • kafkaesq 9y ago
    Why am I writing my own database system instead of using an existing one? Not only is this a perfectly reasonable question to ask - one is almost tempted to fault someone for not coming back with this as the very first question to ask in response to the question that was initially asked. Given that 99.99% of the time you're tempted to go that route (as with, similarly: your own ORM, "scripting language", whatever) - you're going to wind up with, at the very least, way more of a challenge than you initially bargained for.
  • gaius 9y ago
    Why am I writing my own database system instead of using an existing one? My last job was to work on a proprietary, in house database, and while the case for it wasn't quite as strong as when it was originally written, it still did things that no external offering did that were considered important to our business. I probably wouldn't want to repeat the experience, but I learnt a lot there, and that company is wildly successful, not least because they make truly strategic decisions about buy or build.
• matthewmacleod 9y ago
  I'm not quite sure what you're complaining about. What happens between you typing a URL into your browser address bar? isn't a question that requires a canned response to be parroted back – it's a starting point for a conversation about your knowledge of the web technology stack. It's not at all like there is a 'correct' answer, but demonstrating that you have a vague idea of how parts work, can identify gaps in your own knowledge, and make reasonable choices about how you might fill them. Maybe what are the things you should consider if you were writing your own database server? is somewhat less directly applicable to most jobs, but I'd argue much the same sort of thing applies – it's a kicking-off point for a conversation about systems that you should have at least rudimentary knowledge about. I'm curious as to what you would prefer in a technical interview - more directly relevant questions about the specific systems you would be working on?
  • vonmoltke 9y ago
    > What happens between you typing a URL into your browser address bar? isn't a question that requires a canned response to be parroted back – it's a starting point for a conversation about your knowledge of the web technology stack. It's not at all like there is a 'correct' answer, but demonstrating that you have a vague idea of how parts work, can identify gaps in your own knowledge, and make reasonable choices about how you might fill them. The one time I have actually been asked this question it sure felt like the interviewer was expecting a certain explanation rather than trying to start a conversation. Hard to tell, since that was the only technical question I got asked in that phone interview and they rejected me after that.
    • kafkaesq 9y ago
      Yeah that's the thing - the vibe I get from these questions is, "Uh, I actually have no idea what to ask these candidates. I just know I better not fuck this up. So how about that question everyone was talking about on HN the other day? That way, if they don't give an answer as detailed as the one I vaguely read about, at least I'll know right away they're a complete moron."
      • 9y ago
• ptero 9y ago
  I think many technical interviews are simply trying to assess whether the candidate has his head screwed on straight and the ability to do basic engineering. As such, the specific topics are practically irrelevant. At least that's what I try to do when I end up interviewing someone. For example, can he suggest what sensors would be good for a Lego robot that would knock a tennis ball off the ping pong table without itself falling off? Can he describe the logic? How would he test this? How long, on average, would it take? What position of robot and ball would give the worst case performance (success or time)? His job will not involve Lego robots, but IME the person who can give sane answers on those would do a lot better than a coder who knows one toolkit well and nothing else.
  • majormajor 9y ago
    FWIW, though I'm just one datapoint, if I'm going to have a "this isn't the day to day job" question thrown at me, I'd rather it be something more off the wall like this than most of the "do you remember this from your textbook/reference materials" style of trivia. Then I feel like approaching it from first principles is what's desired, and free to bounce ideas around, rather than being expected to remember the optimal log(n) "right" answer.
  • gumby 9y ago
    I agree these kinds of open ended questions are good since they can go in lots of different useful directions (specs, performance, algorithms, generality) and give you some idea what it's like to work with this person (and for them to get an idea if you're jerks or not).
  • brian-armstrong 9y ago
    He?
  • kafkaesq 9y ago
    For example, can he suggest what sensors would be good for a Lego robot that would knock a tennis ball off the ping pong table without itself falling off? Right off the bat, this is very muddled question to ask. For one, "sensors"? I think you meant to say "actuators". Because a sensor by itself can't knock anything off a table. More fundamentally, "Legos", for those of a certain age, were entirely non-mechanical components in their day. So (even though yes, we've also vaguely seen and heard about, and rolled our eyes at, the newer kind), this just sounds like asking them to (seriously) consider the question of how to build a logical circuit out of tinker toys. Yes, it can be done - but on the face of it, that kind of a question comes off as an invitation to join a mental masturbation session. Not the kind of question you'd ask of someone you respect, and whose time you know to be as invaluably precious as you own. The person who can give sane answers on those would do a lot better than a coder who knows one toolkit well and nothing else. This is of course a false dichotomy. Especially given that it was -- not sure how else to put this -- a silly question to ask in the first place.
• IncRnd 9y ago
  These types of questions aren't about playing a game of catchphrases but are meant to let the candidate shine through demonstrating their thought processes. They are also used as behavioral questions to assess how a candidate deals with situations in which they are not familiar, even if the task itself is incredibly easy or not directly applicable to the job. You'd be surprised how many people freeze when they are asked to reverse a list of elements. Another reason to ask fundamental questions is to ensure that an otherwise fit candidate understands the tradeoffs involved.
  • spatley 9y ago
    The question we ought to ask though is: Is a candidate that freezes when asked to reverse a list be an employee that would be incapable of basic coding? Or more interestingly (to me) is the candidate that can easily write the reverse pseudocode on an interview whiteboard one that will be a good employee? When I interview, I ask for her to write some code, yes. But I make it very simple: fizzbuzz, or reverse a string. But then inform the canditate that I am looking for style, craft and personality. Somewhat akin to a chef being asked to fry an egg
    • onikolas 9y ago
      And how do you quantify "style, craft and personality" ? I ask about quantification because I see it as the only way to reduce/eliminate bias.
    • IncRnd 9y ago
      > Or more interestingly (to me) is the candidate that can easily write the reverse pseudocode on an interview whiteboard one that will be a good employee? You're looking at it backwards. That type of question catches people who misstated their qualifications. It's a buy-in to sit at the table. People can debate whether they should have to answer questions, but in the real world one or two small qualifying questions of this nature save the employer a lot of money and time in the hiring process.
• gwbas1c 9y ago
  (Downvoted) That's a really nasty attitude to take when someone is trying to evaluate paying you a large sum of money for many years of work. Considering that I've run a ton of technical interviews, there's no good way to evaluate someone for competency without these kind of hypothetical questions. (This is how I screen out the morons who don't know how to use a database.) It's a two-way street, though. You can learn a lot about an organization by the kinds of questions they ask and the direction they send you down.
• wh-uws 9y ago
  Some permutation of this comment is made litterally everytime any coding interview resource is posted. I'm sorry man no cares that you and everyone who upvoted this comment are Super God programmers with 30 offers everytime they say they are looking who can afford to tell every company where they can stuff their interview. Us mere mortals are willing to do whatever it takes to get our dream gigs. These guides are largely targeted are getting into the some of the best, thus pickiest and most selective, companies in the world. And if getting on means being a dsalgo monkey in front of a whiteboard for a few hours so be it. Let us share interview tips in peace please. This "hurr durr technical interviews suck" but I have no real alternative and have never built a company nor seen any really flourish at the top without this is monotonous. Put your money where your mouth is and start and only support companies that skip these kinds of interviews. Like these fine people https://github.com/poteto/hiring-without-whiteboards https://github.com/poteto/hiring-without-whiteboards But the snarky comments are beyond annoying.
  • booleandilemma 9y ago
    I think the parent is implying they’re not a Super God programmer, and some of these interviewers are expecting them to be, when in fact their company has no need of such a programmer. My own opinion is let’s ignore companies that make us jump through hoops, as it only encourages them to become increasingly ridiculous.
    • rifung 9y ago
      > My own opinion is let’s ignore companies that make us jump through hoops, as it only encourages them to become increasingly ridiculous. Unfortunately not everyone is in a position to do that.. "beggars can't be choosers"
      • taurath 9y ago
        I find it interesting that in the span of 3 comments it’s gone from “this company is only looking for the best of the best” to “beggars can’t be choosers”. I’m of the opinion that if you are a company having trouble hiring people (everyone other than google/amazon) you should not copy their interview process. There are great developers out there that do not do well in these interview environments, who are not worse than those who do well in them. If you are going for a high power attorney partner job at a big firm they do not ask you to recite obscure case law. Id you are a master carpenter they do not ask you to build a cabinet using a hand lathe. IMO provable previous work experience if a candidate has it should trump conceptual knowledge spewing, and interviews that ignore experience and give the same theoretical knowledge quiz as they do a new grad are shooting themselves in the foot. And I think everyone knows it, but most engineering orgs are terrified of letting a bad hire through so they blindly do whatever the “top” companies do.
• neeleshs 9y ago
  #2 is a great filter question. You'll be surprised how many people don't have a clue on this. I'm more than willing to answer that question. It tells the interviewer I have a basic understanding and can expand on it later
  • deleted 9y ago
    [deleted]
• hpcjoe 9y ago
  In my previous search, I had two interviews scheduled, one day after another, with different organizations which were diametrically opposite in outcome, though asked similar questions. It was the way they asked the questions, the body language of the interviewers, and for one of the interview sessions, a seeming desire to show that the interviewers were "smarter" than me. In the first case, I got a nice offer. In the second case, I cut short the interview. The questions were virtually the same. In the good interview, some silly fizzbuzz stuff, followed by "how do you do X", and me doing it. In the bad interview, do this thing, in bash. Had to read a man page on it, asked the interviewer if they had man pages, found out they didn't, asked if I could use the interwebs, at which point he became more flustered and overtly hostile. I then proceeded to solve the problem, while typing in vim, while talking him through the whole process. He was visibly angry and shaking after this. Tried a few networking questions, some of which I've known, some of which are far outside my domain, have never had a reason to study/investigate, and were completely unrelated to the task at hand. The good interview asked me similar things, and when I indicated some of the boundaries of my knowledge, proceeded to work with me on how quickly I could learn something and become useful. There is a huge difference in these organizations. One of them is thoughtful, has great people, and would be a terrific place to work at. The other ... not so much. Later confirmed by talking to people who worked there. Many people are justifying "hard" problems using various reasoning. When I ran my own company and hired, I never used this. What I wanted to see, was how something thought through something they've not seen/done before. This is what I cared about. Could they learn, and apply this learning, in situ, at high speed, and grow as a worker. It seems my viewpoint is in the minority here, with a number of people preferring to test random knowledge fragments, as compared to actual ability to learn and apply what you learn. This is a shame. This generates groups whom are really good at recall, but possibly less so at applying this (as the "applying this" is not tested/measured). I've seen the focus on velocity and accuracy of regurgitation in grad school. Test scores from people who focused on that were high. Capabilities as researchers ... quite low, with very rare exceptions. The same effect is likely to occur in this scenario. Technical interviews are hard. Probing depth of knowledge is challenging. Getting a sense of thought processes requires creating things that people can learn from, and apply. I've had precious few interviews like this. Happy my current position is one of them.
• rifung 9y ago
  > "Look, you know as well as I that this job has nothing -- as in, nothing whatsoever -- to do with actually building production-grade database servers. Or anything even remotely analogous to it. Debugging that tangled mess of poorly conceived, never-reviewed JSON APIs left behind by the other developer (while you were pestering them about 'disruption' and 'just needing to get this thing to market') is more like it." I was asked a similar type of question at Microsoft once about operating systems. I don't think the interviewer expected that I know the answer to what he was asking but rather explain what I do know, and then based off my limited understanding work backwards to see what might be done and what tradeoffs are being considered. At least that's what the interviewer said to me when I responded with "Oh God I have no idea I have never done anything like that before." For what it's worth I did get the offer despite not knowing anything. That being said, I did interview at another company where I was asked something that I guess the interviewer thought was very basic and I responded with something similar. His advice to me was to never say I don't know something, which I don't really agree with. I didn't pass that one.
  • kafkaesq 9y ago
    I didn't pass that one. Sounds like they're the ones who messed that one up - not you.
• cbanek 9y ago
  > 3. What are the things you should consider if you were writing your own database server? Answer: I would consider why I'm writing my own database server, as opposed to using something off the shelf.