49 ms·

Hiring Is Broken

• Stoids 8y ago
  Yikes... Interviewing sucks but half the reason interviewers ask these types of questions is to see your attitude and how you respond. Writing an Instagram clone in Angular doesn't really tell me much about your problem solving skills when faced with a unique problem. > How many people can actually write BFS on the spot, without preparing for it in advance? Ughhh, should I tell him? > why would they ask me this question, what does breadth-first search has to do with front-end development Tree data structures are really common in front-end.. like the DOM or JSON.
  • faitswulff 8y ago
    I've only ever implemented BFS for coding challenges. Do you find yourself reaching for it on a regular basis in front-end development?
    • dkersten 8y ago
      No, but its a really easy algorithm, it really shouldn’t be too hard to implement given a description of it. (not accounting for the people who are just bad at writing anything on the spot in a high pressure interview situation, of course)
      • tptacek 8y ago
        It doesn't matter if it's a really easy algorithm if it's trivia or unrelated to the job.
        • drenvuk 8y ago
          How do you know that implementing a feature very close to how BFS works won't be necessary in the job? You can't. At this point asking if a candidate can make BFS is akin to asking if they can count. Same thing for inverting a binary tree or doing fizzbuzz. They're general and easy enough that anyone with a programming background should be able to figure them out.
          • akerl_ 8y ago
            Given that the hiring process has time constraints (however you do hiring, you can’t use infinite time, so you need to pick what you’ll include in the process), why use time testing the candidate’s ability of something that might be necessary in the job. Wouldn’t that time be better served testing something you know will be necessary?
            • drenvuk 8y ago
              You ask about things you know will be necessary as well. In an interview the time shouldn't be spent entirely on academic programming questions. They're there only to gauge problem solving skills in real time in a stressful environment, which work sometimes is. Who says you can't fit any of the above mentioned programming problems in 10 to 15 minutes?
              • akerl_ 8y ago
                Wouldn’t asking real-world questions that the person will definitely run into during the job also gauge problem solving skills? Unless problem-solving isn’t part of the real job, in which case it’s not worth testing for. If your point is that you do a mix of questions that are definitely relevant and some that are academic and might be relevant, why not just do 100% known-relevant questions? What’s the value add of asking questions that are less than 100% relevant?
          • tptacek 8y ago
            Here's a simple way to quantify the argument: go find the most popular Node or React front-end projects on Github, and then find out how many of them --- in their own source code, not in the vast, unending dependency tree NPM generates --- contain a breadth-first search. My guess is: not very many.
    • dbattaglia 8y ago
      I’ve had to write tree searching algorithms at multiple companies, although I usually find myself reaching for depth-first search instead. It comes up often when dealing with hierarchies (think things like company org charts for HR software, for example).
    • YjSe2GMQ 8y ago
      I did use BFS/DFS or things like find/union in my job. But I'd say it's mostly about how quickly you can wrap your head around abstract concepts. An analogy from finance: if you take a pen and a paper, and think about it for a few minutes it'll be clear that buying a stock and a put option is equivalent to buying a call option (and a bond, since you're also locking in some capital). This is fine, and most people can do that. But the brilliance happens only when such things are immediately obvious to you, in the same manner as you don't need to consciously decode English while reading this sentence. It's another question whether this or that particular company really needs brilliance.
    • scarmig 8y ago
      I've used a version of it before, to traverse a cached client-side hierarchy of domain objects. The inevitable response to that is "well that's an exception, it's only occasionally needed." True, as far as it goes. But if you exempt all of these "rare special cases," you've suddenly exempted 10% of the work. That 10% is among the trickier bits (though the hardest is always organizational and product). I also hate to say this, because it's snotty, but as far as obscure algorithms or tricky, complicated algorithms go... BFS and DFS don't really fall into those categories.
      • hoorayimhelping 8y ago
        >But if you exempt all of these "rare special cases," you've suddenly exempted 10% of the work. I don't think that's the issue though. The issue, as I see it, is not that you had to figure out how to implement BFS. I think many of us are confident we could do that under professional working conditions. If I had a day and some data structures to poke around with, I'd write a killer BFS supported by tests if I needed to (I've had to do similar things in the past). The issue is that interviews expect us to recall this kind of specialized and rare problem solving like it's a day-to-day thing. We as candidates are being judged on how well we can come up with a novel solution on the spot to something that many of us will need to do once or twice in a career, and will be able to solve under completely different conditions. In short, for most candidates, these kinds of questions don't test anything realistic, and a lot of people have issue with that. It's like judging whether you want to go to a chef's restaurant based on how well they did on Chopped! They might do well under pressure because they have practice with it because they're always in the weeds because their restaurant is poorly run. A terrible dining experience might translate to a win on a cooking competition show, because the show isn't testing the chef on the experience they provide you. Just as these kinds of interview questions don't test you on how you'll actually be interacting with code and solving problems day to day.
        • scarmig 8y ago
          I don't want to hold up whiteboard interviews focus on algorithms as the be all, end all. They're a poor proxy for day-to-day skills: the hard stuff is organizational, knowing all the things that can go wrong, and technical design that's both flexible to changing conditions and easy to work with. None of those are really amendable to probing in a 45 minute interview, or even several hours of pair programming. But it's about friction: I want my coworkers to be focused on the genuinely hard problems, not spending a day writing a BFS. The current interview process does manage to probe that. Going a bit deeper, the whiteboard interview process is a good proxy for ability to prepare over the medium term (a month or three of consistent studying should give you as good a chance as anyone to get into a generalist position at a prestige company) and of IQ. The latter is controversial and most organizations can't test for it directly (owing to legal concerns), but a relatively high IQ is a core requirement of technical roles, and whiteboards provide a solid proxy for that when coupled with the opportunity to prepare for them beforehand. That said, I'd always go for someone who has the ability to deliver on complicated, large projects over someone great at whiteboards or who has a high paper IQ. It's just that it's pretty much impossible to evaluate for that in a way that works on a general application pool.
  • delinka 8y ago
    And if the candidate will be writing a new DOM traversal API, this is a valid exercise. As it stands, any of the libraries that do DOM manipulation for me also traverse the tree for me ... so, again, why do I need to implement a toy BFS in an interview?
    • jokh 8y ago
      Because one day you might need to, and you'll write a 100 lines of code to do it. If you had known what a BFS is and how to write it, you'd be able to accomplish the same task in 10 lines of code.
      • dimillian 8y ago
        Counter argument: I could google it, read about it, and implement it. All of it in 1/2H with a computer with internet. Not on a whiteboard. Which is a fucking stupid interview process.
      • dev_dull 8y ago
        Very unlikely in my opinion. Either you’re told about it beforehand, inherit a project that’s using it, or introduced to it during your PR. Especially in places that ask about them during an interview... I don’t think it’s about the BFS, it’s about attitude.
    • mattnewton 8y ago
      To debug the traversal algorithm when it breaks in production? Also, if you know that all the companies do this, why don’t you just study before hand? Tree traversals come up multiple times in the article. I understand the author’s frustration but not their (early) insistence on not studying for an important interview. When they did study later I wonder how seriously they took it based on the tone.
      • delinka 8y ago
        >To debug the traversal algorithm when it breaks in production? And what's the likelihood of that happening with a well-used framework? Maybe the interviewer wants to see my ability to debug problems - great let's do that instead. You want to see how I work? OK, let's pair on something. Pinning this to "implement BFS at the drop of a hat on a whiteboard or in this project" is bullshit. >Also, if you know that all the companies do this, why don’t you just study before hand? Fine. I'll implement a few solutions to the problem in the languages I'm familiar with and put it on GitHub. Now the interviewer can check it out and we don't have to waste time at a whiteboard.
  • pier25 8y ago
    > Tree data structures are really common in front-end.. like the DOM.... 99.999% of front end developers do not solve those kind of problems.
    • jermaustin1 8y ago
      Also there are font-end languages (XPath, CSS selectors, etc) specifically for these types of structures, so you don't have to traverse them.
      • sjburt 8y ago
        Yeah, just pile on another layer of code you don't understand. And then wonder why it's slow or doesn't work the way you expect.
        • lsschmidt 8y ago
          Software developers always have to work on top of some sort of abstractions throughout our career, correct?
          • wtetzner 8y ago
            That doesn't mean you shouldn't have a reasonable understanding of what those abstractions are doing, though.
            • bgdam 8y ago
              For the purpose of selecting a DOM node in a performant manner, you really don't need to know how CSS/XPath traverse the DOM. You just need to know that querySelector exists. In general, I think it's enough to know what your abstraction does, rather than how it does it.
          • yongjik 8y ago
            There's a huge difference between using an abstraction with vs. without understanding what it does. Often the latter leads to more layers of abstraction piled on top to "fix" the problem, until everything sorta works and is barely workable at the same time.
  • chowells 8y ago
    > > How many people can actually write BFS on the spot, without preparing for it in advance? > Ughhh, should I tell him? Yeah, that's where I stopped reading. This isnt specialized knowledge. If you know how to program, you can write a BFS. The entire algorithm structure is in the name. The only extra details you need to remember or figure out are "use a FIFO for tracking what to check in the future" and "make sure you don't go backwards". Neither is some great secret. They're obvious if you sit down and think through (or talk about with the interviewer) the structure specified in the name of the algorithm. This person is either not a good programmer or has a very poor attitude about solving new problems. Hiring isn't broken. I'd reject this guy too. Knowledge about a specific technology is a lot less valuable than general knowledge and willingness to explore.
    • rammy1234 8y ago
      you know what is broken , empathy. Every individual have certain skills and strong and weak points. to that effect, have empathy and understand person being interviewed is not in best comfortable position as the interviewer. In an uncomfortable situation, where everyone is peeping up what you do makes few people thinking messed up. Programmers need a zen place to concentrate and focus. "Homework" assignments should be a good measure to test skills and questions on decisions made on his and how would he improve a code given the use cases would be more comfortable and now we are level playing field. my two cents.
      • quest88 8y ago
        I find empathy hard here. If the author had said they froze or panicked and blanked on BFS, then that's understandable. But that's not what happened here.
        • y-c-o-m-b 8y ago
          > I find empathy hard "If only the author did these very precise things that they just so happened not to do, THEN I would find empathy". I'm pretty sure that's not how empathy works.
      • 8y ago
  • quasse 8y ago
    Yeah, I've seen some real horror stories about bad interview processes in the past, but this seems more like the guy outing himself as a defensive and impulsive person who immediately shuts down when he doesn't "know" something. I can't remember Djikstra's algorithm either, but I would happily try and write a 15 line brute force recursive maze solver in an interview. Of course it's not something I expect anyone does day to day, but it's also the kind of simple problem that I'd expect almost anyone with a CS 102 level of knowledge to be able to reason out by just taking a few minutes with a pencil and paper. As an interviewer, even a brute force solution would demonstrate a good willingness to look at problems using your fundamental skills and reason about something you don't have a ready made solution to.
    • Merad 8y ago
      > I can't remember Djikstra's algorithm either, but I would happily try and write a 15 line brute force recursive maze solver in an interview. You'd fail the interview. The type of interviewers that ask this style of question are never interested in seeing the the naive brute force approach.
      • throwawaymath 8y ago
        That has not been my experience as an interviewee. Implementing the naive solution for small n has been well received in my interviews, and from there (imperfectly) optimizing it is a collaborative experience. I don't doubt you've experienced differently. But if you have, I think it's likely the interviewer, not the question. Lots of interview questions can be abused, not just basic algorithms and data structures questions.
      • EduardoBautista 8y ago
        My experience has been different. Usually the best thing to do is to write the naive approach first and then let the interviewer guide you towards what they think you could improve.
        • Rooster61 8y ago
  • Rumudiez 8y ago
    Getting around the DOM is really simple: querySelector and querySelectorAll do the work for you. Accessing properties of a known object is better handled with the selector pattern. I guess you might use BFS to implement a search feature for user-generated content on the fly? I don't think it's relevant to most FEDs roles making CRUD apps with backend searching APIs.
  • BurningFrog 8y ago
    I've had a successful programming career since the 80s. Including a fair share of browser front end programming. As far as I remember, I have never written any BFS code, and I would also find it absurd to be asked to do so in an interview. There is great library code that does this in any reasonable situation. If you're the kind of shop that would rather write your own code than use third party libraries, then that's a really great sign that I shouldn't work there.
    • mikestew 8y ago
      If you're the kind of shop that would rather write your own code than use third party libraries, then that's a really great sign that I shouldn't work there. Do keep in mind that you're eliminating the places that wrote that "third party library" in the first place. Libraries don't just grow on trees (though they can help you navigate a tree). Just a few weeks ago I had to knock out a test framework, creating an API from scratch (basically an object model on top of some websockets messages), because there's no library that's going to do what we need. Oh, I friggin' abused Python's import keyword to hell and back, but there was a lot of stuff that just needed to be written from scratch. Given there are a few tree-like structures, I'm sure I briefly weighed depth-first vs. breadth-first before hammering out the code. And this is nothing exotic, just a small company working in the industrial controls industry. And such a task is nothing exotic, it's why they hired me. But I think to effectively create something like this in an efficient manner, having at least a rough idea of something like BFS is table stakes. One is not being asked to implement a red-black tree on a whiteboard, just something that I think a competent software developer could come up with from first principles. A company asks you, "which direction will you be searching, and how would you do that?", and you'll reject them. I mean this with due respect: you're probably right, neither party will want you to work there, and the filter worked. Hurray? I'll tell you what grates me, though: the companies that insist they need someone like that, and then the new employee finds out that the culture is so borked, that said employee will never get to actually do that stuff. "We need test infrastructure." Turns out the reason they don't have any isn't for lack of someone to write it, it's lack of culture to do anything with it. As just one example.
      • 8y ago
  • fhood 8y ago
    I was taken aback by the BFS thing at first as well, but after thinking about it, I'm not sure I would be so confident about writing one if I didn't already know the basic structure due to the 50 or so times I had to implement some version of it in college. I don't feel like I can judge because I was forced to implement most of the basic data structures and traversals so many times that I can usually re-create them based on knowing 3 or 4 steps and filling in the gaps myself. I think a lot of software engineers also had this experience, and so they expect it of others, but if nobody forced you to write a path finding algorithm inside a composite pr quad trie in college then you are at a huge disadvantage for interviews, but probably less of a disadvantage for actual practical programming. Be honest, how many of us implement our own data structures these days? I sure don't. I just build on or use whatever version of map comes with the language 98% of the time.
  • scarface74 8y ago
    Yikes... Interviewing sucks but half the reason interviewers ask these types of questions is to see how your attitude and how you respond. Writing an Instagram clone in Angular doesn't really tell me much about your problem solving skills when faced with a unique problem. How many software developers work on "unique problems" that involve hard computer science problems compared to the number that are just using an existing framework to solve business problems? Tree data structures are really common in front-end.. like the DOM.... And most of the time you're going to end up using a pre-existing implementation....
    • watwut 8y ago
      Most projects require you to solve small simple unique problem once in a while. And any long term position requires you to regularly learn not so simple new things. Depending on your existing knowledge, the BFS question tests either whether you was able to learn BFS in the past or whether you can solve small unique problem. There are positions that does not involve anything harder then BFS ever, but I would not say they are majority of them.
      • scarface74 8y ago
        In 20+ years of development, including 12 doing cross platform C work, two maintaining a bespoke development environment for Windows Mobile (compiler, VM, IDE, etc.), I've only once had what I consider a problem that needed any type of complex CS algorithm. That was to evaluate an algebraic expression in a string in C using the "Shunting Yard Algorithm". And the 20 years of professional development was after I had been a hobbyist writing 65C02 and x86 assembly language....
        • watwut 8y ago
          Do you really consider breadth first search complex algorithm? It literally is "you have structure of related data, find the object with given id by systematically going through the structure". That is all what it does. Find whether directory contains file bigger then x is example of breadth first search. That sort of thing. It makes perfect sense to not remember the name and that should be ok. But it really is not something complex - it is pretty much simplest algorithm used to explain the concept of algorithm to students.
  • y-c-o-m-b 8y ago
    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 (like Intel, and yes it was fulltime for several years) and almost always outperformed my peers. I work in finance now where everything is about managing portfolios for people - lots of numbers and heavy calculations. 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. Coders like me write business applications where these things are literally never an issue. If there's something I need to know and don't, I simply research it. That's the point he's trying to make. Don't interview people on algorithms they will never ever use. It's as simple as that. There are more productive ways to interview someone; for example take a bug in your product and see if the candidate can fix it. Or if you're worried about sharing proprietary info, then make a sample program that simulates a bug or feature that your application will use and observe the candidate working on that.
    • 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.
  • organsnyder 8y ago
    I can't write BFS off the top of my head, but I can probably do it after reading the Wikipedia page on it. The last time I interviewed (for the company I'm working for now), I faced a similar question, and said up-front, "It's been a decade since I've had to implement that, so let me Google for a quick sec." I proceeded to do so, skimmed the Wikipedia article, and wrote the code in the shared editor we were using. I got the job, so the interviewer must have seen my candor and quick comprehension as positives. But I know (based on the parent comment here, as well as discussion with colleagues) that this sentiment is not universal. If I had claimed a lot of algorithm-heavy experience on my resume, I would have expected my response to be met much more harshly. But, as my experience was focused more on API design and interactions with business stakeholders, it wasn't a useful question to gauge my competence. However, it was useful for gauging my personality. Like everything, context is vital.
    • zanny 8y ago
      Absolutely this. The better question is, given several data sets, how would you approach traversing them. What is your intuition, and what are the limits of your awareness of how to approach the problem. That is actually informative on your programming ability, not regurgitating buzzwords (albeit BFS is a light one) or rote memorization. Like just hearing these kinds of questions is infuriating because I often immediately ask things like "is the data processing complex enough to justify threading it? what are the synchronization points? if the data processing is variable, we probably want a job pool, etc". The performance of code is almost always noninutitive until you have an implementation done in order to optimize it, and questions about searching graphs are almost always these "optimize light" problems where they want you to really know how to do the navigation right because of my precious 10 cycles per branch but don't want to even consider the operating environment that could influence the decision in anything but a purely academic setting.
  • towaway1138 8y ago
    I stumbled a bit on "write BFS" at a FAANG interview. The specific question was to write it for the Facebook friend graph. I just blurted out my reaction, which is that this was a terrible idea (given the space requirements). His response, "Well, pretend it's not.". Ugh.
    • theamk 8y ago
      Huh, what's terrible about it? BFS is exactly what I'd want. Let's make up a synthetic problem, like "the closest friend which has property X". Then you'd first check all of your direct friends for X, then check friends-of-friends for X, then check friends-of-friends-of-friends for X, and so on. You'd go on forever until you either find a friend with property X, or run out of time/space. This is the classic BFS problem, and I can see how it would make a good interview question.
      • towaway1138 8y ago
        It depends a lot on the specific question, and the connectivity of the graph, but in general, BFS can use space proportional to the size of the entire graph, which for the FB friend graph is huge. Even on a machine with a lot of RAM, you shouldn't assume this will work. DFS or IDFS can generally use space proportional to the diameter of the graph, which is far smaller. That caveat with BFS turns out to be so bad in practice that I've never seen the algorithm used in practice, outside of a classroom. And indeed, I first thought the point of the question was to elicit this complaint. The interviewer wasn't on that page, though. The problem being asked was considerably more complex than "closest friend with property X". I don't recall the details, but perhaps it was something more like "find the ten shortest friend paths to (a unique but unknown) someone with property X, where those paths share no nodes".
        • theamk 8y ago
          Agree re "depends a lot on specific question", but the problem you specified still sounds very much like BFS, especially "shortest path" part. My assumption for the Facebook graph would be that there is basically no way we can traverse it all, so your only hope is to find the path without expanding all the nodes. DFS will not work for that at all, but both BFS and IDFS may give you practical results. This leaves the question of BFS vs IDFS, and that depends heavily on the details of the problem. For example, if the graph is already in RAM, then IDFS would be the best. But if the graph is not already in RAM, and you have to fetch it (from database or remote API), you'd definitely want the caching between successful IDFS rounds. And if you do that, then you might as well do BFS -- approximately the same memory performance, and much easier code. As for usage, while BFS itself is not used this much, it's more advanced versions, Dijkstra and A*, are used all the time in graph traversals. For example, in many computer games, navigation apps and robotics planners. (And back to original topic: if we had conversation like this during the interview, then you would likely get good score from me, even if I was fully convinced that BFS is the only way to go. After all, I am not testing for the specific bot of trivia -- I am testing for the ability to reason about algorithms)
  • eagsalazar2 8y ago
    And asking people tricky questions doesn't tell you about people's problem solving skills either, it just tells you that person is a good talker. Justifying tricky tree traversal interview questions by comparing it the DOM??? That is a stretch. In any case, beyond _solid_ coding skills, the thing that makes someone a great member of a dev isn't coding skills, it is a whole pile of professional best practices, social skills, and general passion for continuous improvement. It is simply not possible to test for those things in an interview. The reality is that interviews are broken. Not because of this guys subjective perception that it is so but because for employers you just aren't getting the SNR to justify typical interviews. People who cling to that approach anyway are largely, IMO, motivated by ego and cargo cult (lack of understanding and creativity). In addition, in that context, interviews are also broken because in being worthless, they are demeaning to the candidate who isn't great at tap dancing on your command. What does work is past performance and actually working together. Both are problematic data to get at so I don't think there are easy answers here. We do a resume review to see if they even claim to have the expertise we're interested in, a very short and simple "gut check" coding exercise (not tricky, just checking they can actually write decent code and tests), a 30min phone conversations where we check that both parties are aligned on what we're looking for, contract to hire, then exercise extreme discipline in parting ways with people that aren't great before converting to W2. Our SNR is pretty good. A lot of people don't want to contract to hire so this system has cons. YMMV of course.
  • oarabbus_ 8y ago
    There's always the interviewing apologists out in force whenever someone brings up how broken the process is; this post is no exception.
    • theamk 8y ago
      Have you been on the other side -- too optimistic interview? You know, your had great-sounding candidate, had nice, non-technical interview, and hired them. Then the person could not really pull their share. They did a few simple PRs, it all looks good. You gave them the more complex task, and they just could not make it to work. After teaching them basic CS concepts for a while, you give up, and try to move them to backend -- and they do not do better there. Then to do data analysis -- no luck. You really do not want to fire them, but this seems the only way forward. The resulting experience is painful and time-consuming for the team. You wasted many weeks trying to teach that person and nothing good came out of it. You promise that in the future, your interviews would always contain technical questions, and no one who does not know about big-O complexity would be hired.
  • drugme 8y ago
    Ughhh, should I tell him? I agree with the sibling commenter: responses like these are very condescending -- and basically prove the main point of the original article. And BTW: Writing an Instagram clone in Angular doesn't really tell me much about your problem solving skills when faced with a unique problem. Neither do your made-up puzzle problems.
  • fatnoah 8y ago
    I think my current company does a decent job of this. Yes, we'll ask you design questions on a whiteboard, but any algorithms or code implementations are done on a computer, and Google is encouraged.,
• cal5k 8y ago
  Hiring is hard. It's very difficult to figure out what combination of activities/questions will correlate to actual job performance, not to mention uncover someone's day-to-day personality when their guard is up. With that said, my interview process basically is: * 30 minute intro call to dive into the CV a bit and see if it's worth everyone's time to go further * 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job * If that goes well, 30-60 minutes to meet with the team and figure out if everyone will get along That's it. No whiteboarding, no FizzBuzz, no algorithms. If we make a mistake we try to recognize it within 6 weeks of the person starting in that position.
  • TulliusCicero 8y ago
    > * 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job This advantages people who have actually used that language/framework for prior jobs. If that's a thing you want to optimize for, then that's fine. If you want to evaluate people as more generic software developers, it's not so great. That's why whiteboarding algorithm questions can be useful. They're sufficiently abstract to generalize to lots of different 'stacks' and experience levels. If you just want to get generally competent developers first and then figure out where to put them later, then this type of question can make a lot of sense, which is why Google, Facebook, et al. use them.
    • taurath 8y ago
      Algorithm questions may be more “general” than doing something like the actual work being performed, but frankly most programmers aren’t writing optimized low level algorithms on a day to day basis. All you get is people who’ve memorized the algorithm tricks.
      • TulliusCicero 8y ago
        It's not as simple as just memorizing "algorithm tricks". There are too many possible questions to just memorize all the answers, you need reasonably strong CS fundamentals, and also to be fairly smart. I think that's part of why they're used: actual IQ tests are legally fraught, but giving someone what amounts to a programming IQ test is not. It's certainly true that studying these kinds of questions helps, but if you're not too bright, I don't think that would take you very far.
• joshstrange 8y ago
  Can we get a (2016) added to this? Also previous discussion: https://news.ycombinator.com/item?id=11579757 https://news.ycombinator.com/item?id=11579757
• SamWhited 8y ago
  > I really wish companies would be more transparent about their candidate rejection reasons I always wish this too. At my previous job a (also at BigCorp) candidate reached out to ask why they hadn't been selected so I started putting together a little email for them trying to give polite feedback and encouraging them to apply again in a few years (they were great, but we needed a more senior role and had no open junior positions at that time). I asked my boss to review it and make sure it was okay, and he told me that under no circumstances do we ever give candidates feedback because if you say one wrong thing it's a lawsuit waiting to happen. Having been on the interview side where I really wanted to know how I could have done better, I was a bit angry on behalf of the candidate.
  • taurath 8y ago
    I would really love an answer whether this is ACTUALLY the case - it appears to be everyone’s assumption, but is it actually true?
    • dkersten 8y ago
      Surely you’re open to a lawsuit anyway: candidate doesn’t get a response to a feedback request and sues because they’re a minority, no response must mean discrimination, right?
      • rock_hard 8y ago
        What the company is trying to do is decrease the attack surface
      • stronglikedan 8y ago
        Nope. I live in an at-will state. Even then, when letting someone go, if you give a reason, you may have to prove that reason in court. If you don't give a reason, then you won't have to prove anything. Therefore, a simple, "you don't fit into future plans" is always the safest reason, and nothing more. It sucks and it's cold, but it's the harsh truth. Similarly why you see very few companies and people apologizing for misdeeds, even if they're really sorry - because it opens them up to liability.
• alexandercrohde 8y ago
  The thing that appears to me, most overpoweringly, is the bitterness. I understand, I've felt bitter about interviews before, I'm sure some interviews were unfair. But I also recognize this bitterness is a weakness of mine, unproductive, unattractive. The way the author indulges in this resentment would make me very cautious about recommending him regardless of technical capability. An employee who has low tolerance for the massive randomness/unfairness in the world probably would get sick of most companies pretty quickly.
  • LaGrange 8y ago
    > unattractive. You're hiring a software developer, not an actor portraying a generic love interest.
    • polityagent 8y ago
      It's likely they're referring to the person's attractiveness as a potential candidate, not their physical appearance.
      • LaGrange 8y ago
        And yet, it boils down to the same issue, and the issue with interviews in general: they're highly subjective in ways that often end up exclusionary (and in specific, racist and sexist), with a significant amount of smoke and mirrors (of varying levels of annoyance) designed to distract both sides from what's actually happening.
        • watwut 8y ago
          Here it was quite clearly used to express the idea of "makes other people less want to give you job" rather then anything vaguely subjective.
  • taurath 8y ago
    The frustration mounts over time - give the person some slack, they’re probably just venting. Most everyone hates the interview process. The way I see it is if perfectly qualified and not nervous, you have a 40-60% chance of passing an interview - it only takes a few coin flips for someone actually competant to go “hey, this shit I’ve worked much of my life for is arbitrary and random”. The issue I think the poster is having is they just don’t understand how algorithm interviewers think - it’s totally reasonable to think oh, frontend has a DOM tree usually, so they should know BFS (even though you’d rarely if ever use your own traversal alg - leave it to the people actually researching it, not the person building a frontend).
• ilovecaching 8y ago
  The google interview really isn’t that bad. In fact it’s kind of unfair in the sense that someone who just did leetcode for a month can pass it while also being a terrible coder. It’s true the interviews don’t test your real coding abilities. It’s probsbly very low signal you aren’t going to go in and write spaghetti algorithms (but they will at least be fast).
  • dajohnson89 8y ago
    >In fact it’s kind of unfair in the sense that someone who just did leetcode for a month can pass it while also being a terrible coder. That isn't unfair, that's just a bad interview.
    • beefalo 8y ago
      It is very unfair to people that have other obligations than doing leetcode for a month.
      • Twirrim 8y ago
        If you can pass a Google interview just from doing leetcode for a month, you got some bad interviewers there. Last time I interviewed there I got pushed on just about every aspect of knowledge I had, going back over a decade+ of experience. There was an awful lot of bullshit trivia questions buried in it, though, and a bizarre obsession with apparently expecting me to know every argument flag for a CLI off the top of my head.
• rossdavidh 8y ago
  I believe the fundamental problem is, most organizations interview in a style similar to testing in college: ask a question about a technical topic, evaluate if the answer is correct. This doesn't correlate especially well to how well a candidate will program if you hire them, but it's the method people learned in school for evaluating someone's knowledge of a topic, so it's what they use. Most developers, and most managers, have almost no training on how to interview well in order to determine who would be a good candidate, so they fall back on the only halfway-similar experience they have. Now, this raises the question of why our society's method of educating people (or determining if that education has been effective) is not very well correlated to their real-world performance, but that's a whole 'nother conversation.
  • mattkrause 8y ago
    The weird part is that this is almost exclusively found in organizations that think of themselves as "tech"-y. I work somewhere on the border between neuroscience and machine learning. Interviewing in a "neuro" group usually involves a lot of talking--what you've done on project X, how would you approach Y, what do you know about Z. Coding does come up, but in the context of stuff that I've done or would do on the job. Applying for a very similar job in a tech company usually starts with me reversing strings on a whiteboard or abusing C++ templates to calculate factorials or something....
    • Ngunyan 8y ago
      Exactly. I worked in Business Intelligence and having both an accountant and a programmer background, whiteboard coding never comes up in interviews. Its more domain knowledge that's important, which is mostly about finance/accountancy.
• deleted 8y ago
  [deleted]
• ukj 8y ago
  Why does nobody get it? The coding interview is not about memorizing algorithms! The coding interview is about demonstrating that you can think from first principles and DERIVE an algorithm! If you understand the problem and the strategy for solving it, you don't need to remember the algorithm.
  • mattnewton 8y ago
    Maybe some very talented candidates will do this but most will memorize a large toolbox of algorithms that people invented over a very long period of time that are known optimal for certain uses. And then the test is recognizing a problem that needs one of these algorthms. Very few questions let someone derive an optimal solution from first principles on a whiteboard in 1 hour with an audience.
    • ukj 8y ago
      You assume you are being tested on deriving an optimal solution. What you are actually being tested on is whether you can derive A solution. ANY solution. And if it is inefficient, you can figure out what needs optimisation and where. The very fact you recognize the inefficiency and you can speak up with ideas on how to make it better is data for the interviewer. Perfect is the enemy of good enough.
      • mattnewton 8y ago
        But in an arms race where one person does this and the other person recognizes it as being solved optimally by an algorithm they know, who looks like a better candidate?
        • Traster 8y ago
          I interview people a lot, if you get to a solution to one of my questions too quickly you get a very small amount of credit and I'll move on to another question until I find one you don't know. If you finish the interview having been familiar with all my questions at best I'm bringing you back for another interview, at worst you'll be discounted because I'll get the impression you've memorized everything you know and you'll be stuffed the first time we give you something new.
• fopen64 8y ago
  Tech job interviews: the Tinder of labor marketplace https://medium.com/@carlosreutemann/tech-job-interviews-the-tinder-of-labor-marketplace-d5ea644e0501 https://medium.com/@carlosreutemann/tech-job-interviews-the-...
• Twirrim 8y ago
  "I really wish companies would be more transparent about their candidate rejection reasons." There is just too much legal risk from doing so. Too much risk of wording being misinterpreted and being turned around to be discrimination etc. To provide feedback you'd have to have so much oversight and absolutely ridiculous levels of paranoia about the potential interpretations of what you'd said that the risk is just not worth it. The value giving feedback to candidates provides to the company is next-to-nothing as well, especially for the larger companies.
  • brightball 8y ago
    That's definitely true. I've only heard of a couple of cases where people pursued rejection feedback and got it. One of them was very important though. A friend of mine in college graduated from a degree program with a 100% employment rate but for 2+ years could not get a job. Anywhere. He was a really charming, funny and smart guy. Interviews always went really well...but nobody ever hired him. One time, a guy who interviewed him called to tell him that he was sorry but they'd gone in another direction. He basically broke down on the phone and begged the guy to help him understand WHY this kept happening to him after 2 full years. The culprit, it turns out my friend had a DUI on his record. He's never actually had a DUI but he was pulled one night after working at a bar and the officer arrested him for DUI anyway. There was nothing in his system but he had to stay overnight anyway for some reason. The arrest was never removed from his record and he had no idea it was showing up in background checks. Once he got it corrected, he got a job almost immediately and is doing really well now, 15 years later. I honestly wonder what would have happened if nobody ever told him about the problem.
  • mattkrause 8y ago
    Everyone says this, but do you know of any actual situations where a company's feedback led to a lawsuit? Even an unsuccessful or settled one would be interesting. I'm also not totally sure about the minimal value of feedback. I interviewed at IBM several years ago, and actually did get useful feedback from the hiring manager. I was referred by someone way up the food chain and the feedback was fairly non-controversial (unlike my background, the job was much more business than technical), so maybe this was unusual. However, the fact that someone was willing to spend 5 minutes explaining why their decision–and outlining some steps I could take to make myself more competitive—gave me more positive impression of IBM than their 3,000 different Watson commercials put together.
• shinepl10 8y ago
  If I had to resolve BFS problem I wouldn't bitch about it like this guy, because the only thing you need to know is how to move across the tree. The rest - you can come up with that - it's not that hard and it's showing your thinking process.
  • pdpi 8y ago
    Yeah, precisely. BFS and DFS are part of a very small collection of algorithmic questions I consider fair game — but I would never ask them directly. Instead I'm likelier to ask something like pretty printing a directory structure, so a function that prints out something like bin/ sh usr/ bin/ local/ bin/ var/ ...
• normal_man 8y ago
  This guy probably got a negative reaction because he says "hiring is broken", when what he meant was "my strategy for getting hired is broken." The goal of "hiring" is for companies to satisfy their needs, not to guarantee that every smart person that comes their way gets a job. A "hiring is broken" article coming from the position of a hiring manager would carry more weight. Also I've never heard of this guy, not sure his handful of Medium articles and cookie-cutter tutorials is sufficient justification for his belief that Google should be lucky to talk to him.
  • rammy1234 8y ago
    have you read his code ? make a judgement after you have. be empathetic.
    • normal_man 8y ago
      No, and I guess I could. But why should I? More importantly, why should/would a prospective employer?
      • y-c-o-m-b 8y ago
        Why interview anyone then? Pick a resume out of a hat and hire that candidate.
      • bgdam 8y ago
        Are you asking why someone - who is hiring a programmer, would want to read the code that a candidate might have written? Because it gives a good idea of the coding style, technique, ability to tackle problems, and put together a solution, and ship that solution, all of which are very pertinent when hiring a programer.
      • mclightning 8y ago
        Because obviously, you spent time to judge the guy by his "cookie-cutter tutorials", if you are really good judge of a coder, you would judge the coder by the code. Not by tutorials he writes.
  • 8y ago
• dev_dull 8y ago
  This candidate reminds me of someone who went on a date and is bitter they didn’t get a call back for a second, despite their qualities that obviously made them the right choice as a partner. Dating must be broken...
  • lelima 8y ago
    Totally agreed! This dude most play League of legends
• xiphias2 8y ago
  I don't get the entitlement of people who try to interview with Google. The ROI of a few months (or in my case years) of preparation for a Google interview is huge. In Google you are supposed to work on things for a year before it comes to fruition (and you get promoted), but people are patient. Getting to know a few algorithms is like real work: you put in the effort and you get a nice paycheck at the end.
  • Traster 8y ago
    Well firstly, Google's plan is not to hire people who are well-prepared, it's to hire people who are smart and familiar with working day to day with the concepts that are used in Google's interviews. If a significant number of people spent months prepping for the interview Google would have a serious problem with their interview process - unable to find the truly talented engineers amongst the naturally gifted. But secondly, if months of prep is required to work at Google what you're saying is they're selecting for young people, rich people, male people - ie, all the people that can afford to be spending their spare time on interview preparation as well as holding down a day job. Go explain to a mother of 2 that the reason she can't get a job at Google is because she can't spend her evenings and weekends on hacker rank despite a job at Google never really requiring work at evenings and weekends.
    • xiphias2 8y ago
      What you say may be true, but there's a loophole for women that Google does specifically: at least in the Zurich office interns are 90% female. Also Google made a new category, called step interns (interns who are in the first years in university). They generally just need to be young, have good reviews, and this way they just need to get through 1 interview when they are converting to full time engineers. As for old people: don't even try, Google has a huge age bias.
• stevespang 8y ago
  This contrasts with my son who is graduating in 3 yrs. with a BS in CS from UT, did a internship in Austin at a major tech company last summer, created an interface for their EE's to use, did a presentation for an auditorium full of EE's there, got an unexpected offer even before he graduates for $101k, plus all the goodies. Many of his CS college friends would only work on the West Coast for the top 3 tech firms just to have it on their resume and also higher starting salary so when they jump ship in 18 months anybody who wants to interview them will be staring at those salary numbers. They all know that the high costs of living on the West Coast will actually result in less savings after rent, food, transport, etc - - - than if they stayed in Austin and worked for tech here. Some background: My son is only a "B" average in CS, got the Google call since he registered for and used Tensorflow once for a project, Google clowns asked for his transcript, never called after that. His roommate with better grades got through 2 google interviews and a flight out to Mountainview, no call back, will probably take an offer with MS in Seattle. Another friend from his HS is a Turing Honors student in same Dept at UT (only about 3% of CS students at UT get Turing Honors). He also got through 2 Google interviews and no call back. oh, and by the way . . . he never was asked to do an interview or any whiteboarding algo's, etc.
• BeetleB 8y ago
  I stopped reading in the middle. I sympathize quite a bit with his frustration, but he does a good job of making it difficult to sympathize with him. He goes on about how there are books written on how to interview at Google, yet it's patently clear he didn't even try to read one of them. It's one thing not to know BFS on the spot because you didn't want to prepare. It's another thing to be totally shocked that they asked the question. A few minutes of searching the Internet, or casually browsing the table of contents of several books, would give you an idea of what they want you to know. And not to defend Google or other companies, but frankly, BFS is not some super complicated academic problem that only smart people can code on the fly. It is one of the more basic recursive[0] algorithms there. So even if you haven't memorized it, it's not ridiculous to expect you to "derive" it. And equating maze solving with AI. Really? I've gone to interviews without preparation, just because "Why not?" However, I don't go on a rant when I do poorly on it. [0] Actually, it need not be recursive.
  • scarmig 8y ago
    BFS isn't really suited for recursive solutions. Trying to do so usually amounts to trying to write BFS with a stack only.
• blunte 8y ago
  Many (most?) programming jobs are about understanding the tools and libraries of an ecosystem well enough to build something useful. When I interview people, I want to know if they can think. I want to know what their attitude will be like (to work with/near them). I want to know what gets them excited (in the context of work, mind you). The older and/or more things a candidate has done in their life, the more accumulated wisdom they will have. This will translate into making better choices earlier (about approaches to problem solving). Testing against university compsci concepts is more likely to get a candidate who will either ignore a well tested and commonly understood library in favor of rolling their own (less-maintainable) code.
• stunt 8y ago
  In this regard, A lot of interviews are designed to test soft skills. I know many recruitment teams aim for soft skills first because they don't want to bother their technical staff if a candidate is not a good match. Many algorithm questions are designed intentionally to see how you tackle an uncommon problem or even an unfair situation and to see if you have a strategy to solve it. Of course, a candidate invited for front-end position at a decent company knows how to tackle his common tasks regardless of how complex they are in comparison. However, that is definitely not true about all interviews. Many companies just copy these interview formats without understanding what is the actual idea behind them. Or how to facilitate these interviews correctly with different candidates from different cultures in different situations. But you shouldn't go to interviews with this assumption. I'm sure at least one of those BigCorps had a professional recruiter. After all, hiring a professional recruiter is as hard as hiring a good software engineer.
  • craig1f 8y ago
    This is a good answer. I was talking to someone at a company that actually used questions like this. He asked me a question like "You're shrunk down to a couple inches in height and put inside a blender. How do you escape?" My response was "Is there anything else in the blender? Can I see anything nearby?" He told me that I "already passed", but if it was an interview, we'd probably have a 1 or 2 minute conversation about it and then move on. The fact that I didn't start rattling off ideas, but instead asked smart questions, was what he was looking for. It's easier to take a measure of someone if they can't figure out what they're being judged on. If they know how they're being judged, they optimize for just that one thing.
• sleepysysadmin 8y ago
  Something the author might not realize. It might be name discrimination for why he's struggling.
• chronotis 8y ago
  Why is this article popping again now? It's from over 2 years ago.
• banachtarski 8y ago
  Yikes as an engineer and not a hiring manager, I do NOT want to work with this person, and I would thank the hiring manager that passed. It's not even just the attitude. It's the competence too. If you can't code a BFS on the spot, sorry... that feels like far too low of a bar.
  • towaway1138 8y ago
    I could mention something about the prevalence of this skill, but I don't want to spoil the surprise...
  • atom-morgan 8y ago
    > If you can't code a BFS on the spot, sorry... that feels like far too low of a bar. I would guess 99% of developers I've worked with couldn't do this on the spot and I've worked on a lot of teams at a lot of companies lol.
  • bgdam 8y ago
    You really should walk into your office tomorrow and ask your team mates to write out BFS on a sheet of paper in half an hour (and take away their phones/laptops). I have a feeling you would be quite surprised at the outcome.
    • banachtarski 8y ago
      It really depends on what you do but I doubt your average graphics programmer wouldn't be able to do it in a heartbeat.
• ebg13 8y ago
  > The first round started with introductions, followed by a coding exercise — write a maze solving algorithm. What the fuck?! Seriously? Mind you, this was an interview for a front-end developer position and I am not a recent college graduate anymore. If you balk at breaking down a relatively simple and straightforward problem into approachable steps that a computer can interpret, then what exactly do you think that programming is? You don't need to _know_ the algorithm. You need to be able to think like a problem solver. And if you can't do that, then what exactly are you doing? > Anyway, that did not go too well, obviously, because it has been a long time since I took an Artificial Intelligence course in college You should be able to do this even if you've never done it before. You have a start, you have an end, and you have decisions to make to get from the start to the end. That's the literal definition of programming. The only people I know who think that basic pathfinding is some voodoo dark magic artificial intelligence problem and not just a simple straightforward algorithmic process that you should be able to do in your sleep for the rest of your life immediately after the first week of Intro CS 100 are not software engineers.
  • deleted 8y ago
    [deleted]
  • lkbm 8y ago
    > If you balk at breaking down a relatively simple and straightforward problem into approachable steps that a computer can interpret, then what exactly do you think that programming is? Programmers tend to be good at putting their head down and solving a problem. They tend to be very bad at live coding for someone whose job is to judge you. A hiring process that measures you on the latter rather than the former is broken. It's like interviewing a novelist by asking them to extemporize a speech for you. It's very annoying that every attempt to make the case against the latter is met with people equating it with the former. They're very different skills. Maybe for some people evaluating performance in live coding is a good proxy for evaluating their programming ability in general, but it's pretty obvious that there are a ton of excellent programmers for which it's a terrible proxy.
    • ebg13 8y ago
• 40acres 8y ago
  I think developers complain way to much about the interview process. The fact of the matter is that it's very clear what type of questions will be asked for most technical interviews and there is a wealth of resources available to prepare. The ROI on spending a couple of weeks preparing is definitely worth the possibility of a substantial raise at a big technology company. I can't think of another industry that is as high paying as software development, with such a low barrier to entry (formal education matters less and less) with such transparency regarding the interview process (books, blogs, literal guides from the company itself). And HN is flooded with a couple of posts like this every single month, is it perfect? No. What is? At the end of the day this just looks like entitlement.
  • msluyter 8y ago
    I only skimmed the parent article, but I tend to agree with you. I would add that a lot of the job entails quickly learning new things and solving new problems. For example, just yesterday I had to work with RavenDB, which I've never seen before. The complaint that you shouldn't need to know how to, say, write a BFS because you never have to do that IRL has only surface validity when you consider that much of your job amounts to doing things you've never done IRL. In other words, if you can't (re) learn certain CS fundamentals in preparation for an interview, perhaps you'll have trouble on the job as well. This isn't to let interviewers off the hook, however. Standard whiteboard problems like "reverse a linked list" are still suboptimal, IMHO, and even with these, there are better and worse ways to handle them. Do you focus on the interviewees reasoning and use the problem as a basis for deeper discussion or simply focus on their end result? Do you treat Sr & Jr interviewees the same? Do you seek out curiosity and ability to learn or a specific knowledge set. IMHO, if the latter, you're probably doing it wrong.
  • ucaetano 8y ago
    > What is? At the end of the day this just looks like entitlement. I had the same impression, particularly driven by these quotes: From this day on, I was even more disappointed — both with myself and tech hiring process — rejection, rejection, rejection. It honestly feels as if I am a complete failure and an unhirable candidate. How is this possible — I have received emails from people all over the world, who praise and give me thanks for the work I’ve done on my open-source projects and tutorials (and I say this as humbly as I can); people who see me as an expert on Hackhands; co-workers, friends and acquaintances from meetups, hackathons, conferences who apparently think I am a decent programmer—but I cannot pass a single tech interview. How? TBH, the author sounds like someone who went to the interviews completely unprepared, believing that just because they have some open-source projects and tutorials, they deserve to be hired. Nobody deserves anything. Most of my friends who went up for interviews with FAANG (or whatever is the latest acronym) studied and prepared for months even before applying.
• efficax 8y ago
  I'm going to join in and say: you should be able to puzzle out the pseudocode for a BFS, not from "memory", but by thinking about the structure of a tree and asking yourself what would be required to touch each node at each level before moving on to the next level. It's not fantastically difficult, and if you can figure it out just by reasoning about trees then you're a smart problem solver that I'd like to work with.
• PaulHoule 8y ago
  Why is it that people who post on Tedium find it hard to hire people or get hired? Maybe the problem is that they are writing on Tedium. https://www.youtube.com/watch?v=_f4oJ-DQdSY https://www.youtube.com/watch?v=_f4oJ-DQdSY
• williamqliu 8y ago
  One of the things that I wish we could meet in the middle on is getting the option to use your favorite text editor or IDE during these interviews.
• georgeecollins 8y ago
  There is a hiring infrastructure which is sort of like those dating apps that say they want you to find true love but really they want you to keep dating. I am thinking of a lot of HR at companies, recruiters, and people that enjoy interviewing. I have worked at startups that weren't really growing that fast but we're always interviewing to fill in the churn. Interviewing feels productive, feels like a company is growing. They say: We only accept the best so any test is reasonable. This tends to discount people's accomplishments and the idea that smart people can learn. The internet makes it possible screen a zillion candidates, so like dating it feels like there are a million fish in the sea. Why value anyone's time when there is so many to consider? I was thinking about putting my CV for a very senior role and before you could put it in they made you take this like web IQ test. Seriously? I would worry about anyone who go through that for a job that expected more than ten years high level experience. Pass.
• povertyworld 8y ago
  I think the real reason programming interviews have become torturous is to discourage people from changing jobs. It's a kind of unspoken anti-poaching agreement.
• vram22 8y ago
  Breadth-First Search (BFS) and Depth-First Search (DFS) are actually both pretty interesting algorithms (although relatively simple for the basic cases - there are some variations), partly because of their applications. It's actually initially a bit surprising that BFS has such a simple algorithm using a queue, as mentioned elsewhere in this thread and in the Wikipedia article about it [1]. Might be non-intuitive on first look, but then turns out to make perfect sense. [1] https://en.wikipedia.org/wiki/Breadth-first_search https://en.wikipedia.org/wiki/Breadth-first_search https://en.wikipedia.org/wiki/Depth-first_search https://en.wikipedia.org/wiki/Depth-first_search
  • megous 8y ago
    And this being front-end, ie. JS, you can just use map/flat in a loop to get breadth first traversal. function bfs(list, cb) { while (list.length > 0) { let i = list.find(cb); if (i) return i; list = list.map(i => i.cn || []).flat(); } }
    • vram22 8y ago
      Interesting, thanks. The Go Programming Language book also has a couple of nice examples of DFS and BFS, in the middle chapters. One is for sorting courses by prerequisites, and the other is for a web crawler, IIRC.
• devonkim 8y ago
  I'm not exactly a gifted programmer or anything but a BFS seems pretty reasonable in an interview depending upon the amount of rigor / efficiency being demanded. I remember doing it for one of my very first interviews where I was asked to implement a website crawler and hold onto URLs. Having written a lot of them while trying to scrape sites for info before every other site had an API, this was super fast for me and was a very practical problem. It's not like they're asking for a topological sort of a graph where you can use Prim v. Kruskal and now you have to make sure you remember that near the neurons that activated your memory of your 3rd week of sophomore year 2nd semester when you had a really nasty cold. If you haven't heard of breadth-first v. depth-first that should be simple. I do this problem constantly on my laptop when I'm looking for files and start getting annoyed at how long a search is taking. You start applying -maxdepth to a find command and fumble through directories perhaps and do a for loop. This is how I wind up doing a crude variant of k means clustering using cut, sort, uniq, and some creative use of awk when trawling through a bunch of log files. But I do feel that anyone pretty serious about programming as a career understands there's little to be gained by more or less bitching about the state of hiring and a lot more to be gained by spending a few hours or so working on some problem sets occasionally. We're all busy and have to keep our technical knowledge up to date of course, but almost every well paid professional has to do this (doctors and lawyers are required to do this to even practice, in fact). I don't bother interviewing for FAANGS because my brain's fried and burn-out makes working on interview prep an order magnitude harder, but I don't go around blaming everyone for acting in their own self interest either.
• jonathankoren 8y ago
  The 2016 discussion on this very article https://news.ycombinator.com/item?id=11579757 https://news.ycombinator.com/item?id=11579757
• deleted 8y ago
  [deleted]
• bluejay2387 8y ago
  The core problem IMHO is that a great many of the people hiring developers are not themselves developers and have little to no technical knowledge. Companies depend on these ridiculous hiring processes because many decision makers believe it allows them evaluate candidates that they have no other way to evaluate. They see Google using these approaches and figure if it is good enough for Google it is good enough for them -- not realizing that Google is an entirely different situation with needs that don't match their own (Note to 99% of companies in existence, you are NOT Google and Facebook). I speak from experience. I have been hiring and managing IT staff for 20 years. I also happen to have 25 years of experience in development and infrastructure. One of my priorities when taking over an IT division is to get rid of these useless tests and I have received push back from internal recruiters, HR, and non-technical management every time I have attempted to do this. It requires moving a good percentage of of the hiring process from non-technical management to the IT staff and its not an easy change. Recruiters and non-technical management see it as a threat to their positions. Until there is a realization that you have to know something about a topic to judge the skillsets of others I don't see this improving (I expect that to happen... never).
• rossdavidh 8y ago
  Is it just me, or is HN, normally a much calmer and more reasonable forum than almost anywhere else on the internet, actually a little bit flamey and ranty when you get on the topic of tech interviewing? I've seen reasoned conversations about world politics, war, gender issues, etc. etc. on here, and never as much sturm und drang as on this issue. I do not necessarily exempt myself from this statement, btw.
  • rossdavidh 8y ago
    Although, still interesting to read the comments.
  • beefalo 8y ago
    Sunk cost fallacy/hazing mentality. "If I spent 6 months of my life memorizing programming problems to get a job at Google, then everyone should have to".
    • rossdavidh 8y ago
      I have a similar impression.
  • mclightning 8y ago
    It is very calming to see some more people in the comments are sharing this observation as well. So many comments seem to be projecting onto, reading into OPs personality.
• drugme 8y ago
  I was asked to write a function findSum(array1, array2, sum) that returns true if two numbers from two sorted arrays add up to a given sum. I was able to solve it with my eyes closed using a double for loop — O(n²) time complexity. For the remaining time I was able to reduce the time complexity by converting arrays to hash maps, then finding the difference by subtracting sum from the first list element and checking if that difference is a “key” of the second hash map. OK, I can accept the fact that in some environments, knowledge of BFS (and the ability to implement it from scratch) can be considered a must-have skill for a front-end developer. (Not in all environments. But granted, in some environments). But can someone please explain how the need to implement a function like findSum in less than O(n²) -- and in particular: to be able to whip out the sorting trick necessary to achieve it, while standing in front of a shitty whiteboard with strangers staring at you -- Can reasonably occur in an actual front-end engineering role?
• hintymad 8y ago
  I don't understand where the bitterness came. Yes, the author failed a few algorithmic questions. That's unfortunate. But isn't interview a chance for two-way evaluation? The companies he interviewed with valued people who were at least mildly interested in computer science 101, yet he was not. On the other hand, he didn't like being evaluated on CS fundamentals. So, neither party was happy with the other. Then move on. P.S., what's wrong with companies aspiring to hire people like React's authors, who had to have solid understanding of basic algorithms and data structures?
• draw_down 8y ago
  The way our industry treats humans generally is a disgrace, including hiring. But I don’t think this is a good rundown of what’s wrong. Oh no, you didn’t find the toy problem you were given in a screen interview interesting or memorable. God forbid anyone ever work on something uninteresting or unmemorable. Most of the best people I’ve worked with throughout my career haven’t had any open source projects, and it didn’t matter. These streets run in two directions.
• nunez 8y ago
  I disagree with the OP's premise. Yes, nobody is going to write a BFS or `Math.pow()` on the spot, but it's way too easy for people to bullshit about their experience to rely on that alone, so BFS and `Math.pow()` is what we've got to work with. While I'm a proponent of giving interviewers a bit of homework and making the interview a pairing session, there are plenty of people that complain about this being free labor (even if it isn't). OP mentioned earlier that looking these up is easy enough, so what's the harm in looking these up before the interview so you can get that out of the way? Also, failing five face-to-face interviews smells of personality or culture fit issues, not tech issues, IMO. I've interviewed tons of people over the years, and the ones that pass the phone screen but fail the tech screen usually failed due to poor culture fit (or padding their knowledge a little too much). I would see if it's possible to message one of your past interviewers and ask for a honest opinion of what they thought of you. While you're unlikely to get a response (giving interview feedback is, sadly, a big HR no-no), some people might budge on your offer. Good luck?
• mudsizita 8y ago
  On the other end of the spectrum, I have little software engineering experience but having dabbled in competitive programming, I can solve almost all algorithmic interview questions optimally within minutes if not seconds. I still failed half of my interviews though (including Google even though I believe I answered every question perfectly). Perhaps it's due to my presentation, or my lacking portfolio, or perhaps the positions have simply been filled. On another note, OP seems to rely on recruiters to approach him? Wouldn't it make sense for OP to actively apply to positions which may have better fit?
• ioncube 8y ago
  This article is from 2016. We are in 2019, I'm curious what happened to the author, did he eventually found a job? switched career?
• kskdndnsn 8y ago
  Usually the people that says hiring isn’t brokens are the ones that benefit most from it. Algorithms and programming are not one and the same. The overlap but knowing algorithms tells me nothing about your knowledge of programming. You know what I would be more interested in candidates knowing? Solving problems that have no immediate answers. For example, understanding how to architect a program without using a framework, Debugging a bug even though you know nothing about the library you are using (eg. Be able to read code and race the problem), and understanding the difference between algorithm and architecture in overall performance of a system. You can memorise algorithms. You can’t memorise problem solving and architecture. Albert Einstein said something along the lines of, “Don’t memorise knowledge that you can look up in a textbook.” What have you learned since becoming a programmer? Did you push your knowledge of programming or are you rushing to the next hype framework? I see many more of the latter than the former. Knowing algorithms is like optimising for the flow of water for your tap in the house without understanding how the pipes layout affects the overall output. And that’s the problem when you only work on one small section of the program your entire career. Apologies for the rant..
• jb3689 8y ago
  I used to feel like the author of this post, but trees have come up at each of my last few jobs. BFS is a trivial algorithm and you really should know it. It is only a few lines. Do you work with things that have dependencies? Do you work with hierarchical data? What about hierachical apis? Tree traversal is a powerful tool, and not knowing how to use trees is a sign you may take the stick-and-rock route when it comes to solving problems
• amrx431 8y ago
  Here we go again. This bickering is never ending. Personally I have stopped caring.