17 ms·

This feels condescending. I've been developing for well over a decade as full stack engineer. I've worked as a successful software dev at some big corporations

• castis 8y ago
  The theoretical interview was never about writing a BFS. Its about how you approach answering the question.
  • y-c-o-m-b 8y ago
    No I got that point. You missed my point; it's completely unnecessary when there's a more productive way to observe someone approach a problem. EDIT: I noticed you edited your post so it looks less inflammatory. Not cool.
    • mentat 8y ago
      Not cool that he made it less inflammatory? I think you're missing the goal of HN here.
      • organsnyder 8y ago
        It does make the reply look more brash, though. Good that [s]he made it less inflammatory, but it would have been courteous to add "edit: made the tone a bit nicer" or something.
      • y-c-o-m-b 8y ago
        That all depends on the intention. If the intention is to make my response look more hostile, than I would say it goes against the conduct of HN. They could have replied or added a remark in the edit. The poster could have said "editing, sorry for getting too heated" or something if the intention was to deescalate, but this was a ninja edit.
      • Rooster61 8y ago
        Disagree. Editing a post like that without leaving a message about why it's edited appears disingenuous.
    • castis 8y ago
      The edit button exists for a reason. Your regard for what is and is not cool is of little consequence. No one owes you an explanation.
      • antoinevg 8y ago
        And no one owes you a white boarded BFS implementation which bears no resemblance to how they would approach a problem in the real world.
        • deleted 8y ago
          [deleted]
        • castis 8y ago
          Let us all be grateful that you were never asked for one then.
          • antoinevg 8y ago
            Oh I know you weren't asking, I was merely responding to the incongruence apparent in your own expectations of the world.
            • deleted 8y ago
              [deleted]
  • eagsalazar2 8y ago
    The fallacy here is that you are actually getting to observe people's problem solving approach when asking them questions like this (vs their ability to talk) and that your subjective perception of someone's problem solving ability in those situations maps to actual job performance at all (vs your own biases).
    • throwawaymath 8y ago
      Is that a fallacy with basic algorithm questions, or with interviewing in general? How does another category of question provide objective feedback about problem solving ability instead?
    • castis 8y ago
      The entire point is that I _am_ gauging their ability to talk with me through something they may or may not be uncomfortable with. This has worked well in the past and most people deal with this favorably. If their response is "this is stupid, no one has to know how to do this" and storm out with the same indignation that is present in half of these comments then they are not the ones who dodged a bullet.
  • ModernMech 8y ago
    I hear this a lot, but I've been in interviews were, yes, it really is about writing the BFS (or whatever algorithm they were asking for). I can remember one, where I was asked to write write an algorithm that, given a vector of points, calculates the euclidean distance between every pair of points. I wrote out a one-liner in MATLAB that accomplished the task in about 2 minutes, but then they wanted to see it in C++. Then I wrote it out in C++, which I don't know so well, so it ended up being in pseudo-C++. Then we spent the remainder of the time quibbling about syntax errors and missing import statements. It was very clear to me the interviewer only wanted to see perfect, compiling C++ on the white board, and had no interest in my problem solving or thought process.
    • mk89 8y ago
      > It was very clear to me the interviewer only wanted to see perfect, compiling C++ on the white board, and had no interest in my problem solving or thought process. It depends on the position you apply for, I'd say. Some jobs require C++ and algorithmic skills. If you don't know how to write a basic algorithm in C++, then you might not be the best fit - and you might not want to join the company as a junior developer.
      • ModernMech 8y ago
        FWIW, this example was for a company that refused to tell me what the job description was and what the position was. They didn't tell me ahead of time which languages they preferred or what kind of work I would be doing. It's a company everyone knows and is renowned for their secrecy. While they refused to tell me what they were looking for, it became clear during the interview they were looking for something very specific.
        • throwawaymath 8y ago
          I'm fairly certain I know which company you're talking about - I'd recommend you redact the specific question they asked, because I'm aware that they do check online (including HN) for interview questions that were asked. You have plausible deniability as long as you don't name the company, but given the NDA they throw at you it's probably better to be safe than sorry :) That being said - sorry to hear that was your experience. That shouldn't have happened, but it does.
  • zanny 8y ago
    If your first contact with a potential hire is asking them asinine pointless riddles meant to try to imbalance them you are going into the process with an adversarial relationship. Which is probably the root problem. Almost all tech hiring is carried out like a war between companies that want results and candidates who don't want to be treated like shit.
  • watwut 8y ago
    I never understoood this. What does that even means and what is good and what is bad way to approach the question? Because BFS has two approaches - 1.) I know BFS or similar example and will write it with no thinking 2.) I am figuring it out in head while saying things to keep you pleased. You don't need to know employee internal thought process. Practically, BFS tests whether you are able to BFS, which is cool by me. It is simple enough so that people who were really unable to learn it should really be filtered out. (It is ok to not know name, obviously. Just ability to find a thing in datastructure should be question.)
• cynicalkane 8y ago
  A breadth-first search is a pretty basic algorithm, but even if you don't have it "memorized", the question is simply: here's a data structure, we need to traverse it in a certain order. Traversing data structures is so common that, even without a formal CS education, I'd expect an engineer with years of experience to have the strategies in a sort of unconscious memory, like a rock guitarist who plays the right chord progressions without knowing what they're called. A candidate who freaks out upon being asked that question is not a candidate whom I'd trust to be a good problem solver. Solving a problem with simple constraints is something that happens all the time. If you don't know how to approach that, you could just "look it up", but how would you even know what to look up?
  • 0xFACEFEED 8y ago
    > Solving a problem with simple constraints is something that happens all the time. I disagree. My experience has been that these problems are exceptionally rare. They're so uncommon that programmers get excited when presented with such a problem. It feels like "real programming" as opposed to fixing bugs, writing prototypes, or writing business logic. > I'd expect an engineer with years of experience to have the strategies in a sort of unconscious memory, like a rock guitarist who plays the right chord progressions without knowing what they're called This is fantasy. You're comparing the average programmer to musical savants? What? You happen to have memorized a bunch of algorithms for traversing data structures. That's great, but nothing about that is "unconscious memory". The fallacy is expecting everyone else to have memorized the same thing you have memorized. > If you don't know how to approach that, you could just "look it up", but how would you even know what to look up? Google for "tree traversal" and spend 10 minutes researching common algorithms. Pick one that fits. Spend 20-30 minutes writing it (hopefully with some tests). Worst case you've spent an hour. Someone who memorized the algorithm could probably write it (with tests) in half the time. And that's okay because how often are you doing tree traversal? And even if you're doing tree traversal all the time then you'll have memorized all these techniques in 1 month anyway.
    • calcifer 8y ago
      > Google for "tree traversal" and spend 10 minutes researching common algorithms. The point is you wouldn't know what to search for. If you don't know anything about cars, you wouldn't be able to search for "alternator fault". The best you could do is "engine problems" which won't help you solve the actual problem.
• zeroname 8y ago
  > I have no fucking clue how to write a BFS. I've never needed to know how to write a BFS. I will probably never need to know how to write a BFS. If I give you a description of what a BFS is, you as a programmer should be able to write one. A BFS is rather trivial. You shouldn't have to know how to write it, you should be able to figure it out. The same goes for implementing a linked list or the FizzBuzz problem. As a programmer, you need to make up algorithms on the spot to solve business problems. You don't know the solution beforehand, you figure it out, that's your job. It's the key skill that basically separates you from a typist. > There are more productive ways to interview someone; for example take a bug in your product and see if the candidate can fix it. This is a different skill. It's an important skill, but finding errors in an existing structure and fixing it is different from being able to create that structure in the first place.
  • TheOtherHobbes 8y ago
    Depends on the algorithms. Some people can brute force something basic, and the brute force answer will usually be slow and stupid at scale. I'm working on something at the moment, and one of the key features is that while there's a fair amount of data, none of the structures are particularly big - and are very unlikely to ever become big. So my thought process is that stupid brute force algos are absolutely fine for this domain. If I have performance problems I can look into optimising them. If I had hundreds of terabytes of data to start with, I'd take a different approach, and I'd research - not invent, because I don't care to reinvent a wheel if someone has already produced a much better solution - more efficient algos. If none of the above work, then I'd consider improvising something and testing how it performs. Would this pass your interview process or not? Do you want someone who's going to brute force an answer to your toy problem and think they've solved it with something that works but is inefficient, or someone who has memorised a collection of standard answers but maybe can't improvise something new, or someone who is going to check what's already available to save time, or someone who can improvise a super-efficient answer and do it even if it's not needed? Who would you pick? Do you really think this question has a simple answer?
    • zeroname 8y ago
• skookumchuck 8y ago
  > I have no fucking clue how to write a BFS. I've never needed to know how to write a BFS. [...] If there's something I need to know and don't, I simply research it. The problem with that is when the best solution to a problem is a BFS, you may never recognize or realize it, because you know nothing about BFS. You won't know what to research for. I see it when people who don't know what calculus is go to enormous efforts to develop workarounds that sort of half-assed work. I see it in my own work when I didn't know about a class of techniques, so I invented some crappy solution. For example, reinventing bubble sort when I could have used quicksort. BFS is awfully basic knowledge. How do you know you've never needed a BFS? Maybe you never needed a BFS because a linked list is your go-to data structure? Maybe you've been reinventing bubble sort. (I'm not the only programmer who incompetently reinvented bubble sort, not even close. I just didn't know any better.)
  • zanny 8y ago
    At least in my case I'd like to think I absorbed the habit of recognizing sub-optimal traversals of data (for example, yesterday I was writing a parallel iterator and made the intentional choice to "waste" effort duplicating the map result than having to synchronize threads on mutable boundaries) but I don't remember all the buzz word jenga that was in my data structures class in uni.
    • skookumchuck 8y ago
      I've often been able to dramatically improve other peoples' code by selecting the right data structure (array, list, tree, hash, whatever) where the original programmer clearly did not know about them. They were able to make the code work, but not very well. It's hard to do research when one doesn't recognize there's a problem, nor know what question to ask.
  • devxpy 8y ago
    You think every programmer has a CS degree?
    • shkkmo 8y ago
• 3minus1 8y ago
  I'd like to say that I appreciate this comment even though I disagree. It's true that you can be a perfectly good or even above average developer without ever using BFS, and interviewers shouldn't pretend this is not so. It's also true that software development is a problem solving job. You are paid for your ability to think for yourself and solve a problem. BFS is artificial but also a nice self-contained exercise that any developer worth his salt should be able to figure out.