6 ms·

Is BFS really that hard, especially if the interviewer is willing to talk it out with you and doesn't care a lot about finding the most efficient solution possi

Is BFS really that hard, especially if the interviewer is willing to talk it out with you and doesn't care a lot about finding the most efficient solution possible? I've been out of college more than 10 years now, do a mix of hardware and software (so am not coding all day everyday) and I can hack together algorithms like BFS if I spend a couple of minutes thinking about it. I get that there are many awful interviewers out there and that hiring is pretty broken, but BFS seems like a pretty reasonable interview question, so long as the interviewer talks through what it actually needs to do and isn't only looking for a memorized answer. The question is well contained, doesn't require the candidate to know any specific API or framework, and can be implemented in pretty much any language. Probably the biggest downside to it is it's such a common question that many candidates study it ahead of time which makes it a worse filter.

spyspy 8y ago
You and a lot of other commenters are getting hung up on the BFS example. It's just that - an example. There are dozens of algorithms that are "common" enough to be asked about and diminishing returns to having them all memorized.
- cornellwright 8y ago
  Sure, but that's my point. So long as the interviewer is telling you what they'd actually like you to do, you should be able to just derive the algorithm you need to do it. At some point the algorithms become difficult enough (particularly if you add lots of constraints like efficiency) that it's pretty unreasonable to expect that in an interview though, and at that point it's a bad question. Rather than memorizing a thousand algorithms, I generally focus on being able to solve problems simply, quickly, and elegantly, which will help in actually doing most jobs.
  - pishpash 8y ago
    You're still not getting it. Even for BFS, which is not a hard problem, the current state of the market is that enough people have memorized the BFS recipe so that the interview doesn't allocate much of any time to it. You're not going to have/be given time to "just derive the algorithm" or "solve problems simply, quickly, and elegantly." You're competing against rote speed, which, if you don't implement BFS all day or haven't recently done interview prep, you don't have and you're definitely going to fail. I've heard people actually defend these useless interviews on correlation grounds, like people who are docile, follow the herd, and "prepare" are good hard-working workers who also tend to have done well in school or look polished in other aspects of life. That's what these interviews are really looking for. So, if you're not a well known expert, suck it up, be a servile cog and follow the script.
    - skybrian 8y ago
      It seems like there might be a middle ground, like being willing to play the game, that doesn't imply being "a servile cog?" The trick seems to be knowing when the game is worth playing. There are certainly situations where competition is too fierce and requires too much preparation, so it's not worth doing if you don't really enjoy the game. I'm not sure getting hired at a large tech firm is quite that competitive, though? They do hire lots of people all the time.
  - nicoburns 8y ago
    My first reaction when inplementing anything more than a very simple algorithm is to google the best way to do it. Of course, I could probably come up with a way to do it by myself. I could probably even come up with an efficient way if I spent an afternoon/day on it. But why do that when I can google it, and get 3 blog posts and 2 stack overflow answers detailing the different options and the trade offs between them, most likely even with an implementation I can base mine off of? That's why these interview situations are stupid. They're like school where copying is cheating, whereas in real-world situations copying is a great way of doing something.
    - smallnamespace 8y ago
      > But why do that when I can google it, and get 3 blog posts and 2 stack overflow answers detailing the different options and the trade offs between them, most likely even with an implementation I can base mine off of? A lot of resources out there are wrong, inaccurate, or not reasonable for your particular context, and it requires a reasonable amount of algorithmic intelligence to be able to sniff out what's appropriate. If I had a dollar for every high-upvoted SO post that misstates a problem or doesn't offer proper caveats... but I can make that judgment because I've already thought about a related problem in the past. It's like asking why one should learn how to write properly when Grammarly and spell checkers exist, or why mental arithmetic is useful when we have calculators—at some point those your tools will be inappropriate or unavailable. Search tools are force multipliers, not replacements for personal knowledge and intuition.
      - nicoburns 8y ago
        > A lot of resources out there are wrong, inaccurate, or not reasonable for your particular context, and it requires a reasonable amount of algorithmic intelligence to be able to sniff out what's appropriate. Right, and having that algorithmic intelligence is key part of me being a good developer. But testing how someone implements an algorithm in time-scarce circumstances is not a good test of that kind of intelligence because it is likely to favour people who have been exposed to that particular algorithm before (even if they only rote-learnt information about it - as many interviewees seem to do in practice) over people who have the capability to think deeply and reason correctly about it, but have not previously been exposed to that problem.
- Vel0cityX 8y ago
  Except you don't need to have them _memorized_. You shouldn't. That's not the point.
  - ec109685 8y ago
    But given it is straightforward to memorize, it isn’t a good test.
  - Datsundere 8y ago
    Except all of these questions can be grouped into a category of the same kinds of problem and it is in fact spending time to find out that pattern and which category from sliding window, nested intervals, recursion and dynamic programming it belongs to
  - TrinaryWorksToo 8y ago
    If you memorize them you appear more competent
rossdavidh 8y ago
If the interviewer is willing to talk it out with you, then it is totally a different situation. But, it came up in a recent other HN discussion on tech interviews, and it is an example of something that, if you memorized it, would have a vanishingly small improvement in your ability to get the job done. But, if you explain what it is in words, and have them whiteboard how to turn those words into pseudocode or somesuch, then it could be a appropriate, sure.
autokad 8y ago
I'm a data scientist, and google asked me to sum all values of nodes at each height of a tree. I had to implement the tree, bfs, and the algo (which was easy once you have bfs) in a 25 minutes, minus any talky time. BFS is not something I thought about much in the last 5 years, and quite frankly could care less about. I got stuck when I knew I needed 'something' to finish implementing BFS, but couldn't remember and the google interviewer offered no help. What I couldn't remember was the queue.
- alasdair_ 8y ago
  >I'm a data scientist, and google asked me to sum all values of nodes at each height of a tree. I had to implement the tree, bfs, and the algo (which was easy once you have bfs) in a 25 minutes, minus any talky time. THIS is the problem. The (unreasonably) timed nature of the exercise means that the only people that will do well are the people that prep heavily for this specific skill, in much the same way that people about to take the LSAT are likely to do better than it than actual fucking lawyers with proven experience.
  - rossdavidh 8y ago
    Time (and being watched) do make it very unrealistic, but the other thing missing is that programming now is not like in the 1970's, you don't need to memorize much of anything. If you forget something, you look it up, it takes 30 seconds to remind yourself, "oh, yeah, the queue", and then you go. Testing if you can do it without looking it up is not testing the skills you actually need in order to code well.
  - lr4444lr 8y ago
    Now take this analogy one step further: why aren't lawyers asked stupid timed LSAT questions at every job interview? Because they take a really challenging professional exam called the bar, which is a strong base level guarantee of actual knowledge and competence. Software Eng. have been fighting this kind of credentialing because somehow tech is "top innovative" for such standards. Hence the status quo, and why companies like TripleByte see opprtunity.
LaserToy 8y ago
Bfs is just one of examples. I can ask you a question you will not be able to answer without knowing the answer. There is a reason it took researchers years to find those optimal solutions
- cornellwright 8y ago
  Sure, you can come up with an algorithm question hard and obscure enough that no one will be able to answer it in the time given and no one will have bothered to memorize it because it's so obscure. That doesn't mean all "implement X algorithm questions" are categorically bad.
- joshuamorton 8y ago
  This is such a cop out. It took millennia to invent 0. That doesn't mean that 0 is an exceedingly difficult concept to grasp.
  - Aeolun 8y ago
    BFS as a name isn’t a difficult concept to grasp either.
    - joshuamorton 8y ago
      Neither BFS the concept, nor 0, the concept are particularly hard to understand. That's why I used the word "concept". If you disagree with that, I'd be interested in what you feel is exceedingly difficult about the breadth-first search algorithm to understand, or if you prefer, to explain why the time it takes to discover or first write down a concept is strongly correlated with its age. Consider that BFS was first published in 1945, while the turing machine was published almost 10 years prior. Is BFS an implicitly more complex concept than a turing machine? That seems like a strange argument to make, but I'm certainly interested.
  - mehrdadn 8y ago
    I don't understand your comment. Was the parent suggesting BFS (or the like) is an exceedingly difficult concept to grasp? And if we're going to claim understanding BFS is like understanding zero, then wouldn't that just mean it's just as silly to complain about a question on BFS as it is to complain about a question on zero?

spyspy 8y ago

You and a lot of other commenters are getting hung up on the BFS example. It's just that - an example. There are dozens of algorithms that are "common" enough to be asked about and diminishing returns to having them all memorized.

cornellwright 8y ago
Sure, but that's my point. So long as the interviewer is telling you what they'd actually like you to do, you should be able to just derive the algorithm you need to do it. At some point the algorithms become difficult enough (particularly if you add lots of constraints like efficiency) that it's pretty unreasonable to expect that in an interview though, and at that point it's a bad question. Rather than memorizing a thousand algorithms, I generally focus on being able to solve problems simply, quickly, and elegantly, which will help in actually doing most jobs.
- pishpash 8y ago
  You're still not getting it. Even for BFS, which is not a hard problem, the current state of the market is that enough people have memorized the BFS recipe so that the interview doesn't allocate much of any time to it. You're not going to have/be given time to "just derive the algorithm" or "solve problems simply, quickly, and elegantly." You're competing against rote speed, which, if you don't implement BFS all day or haven't recently done interview prep, you don't have and you're definitely going to fail. I've heard people actually defend these useless interviews on correlation grounds, like people who are docile, follow the herd, and "prepare" are good hard-working workers who also tend to have done well in school or look polished in other aspects of life. That's what these interviews are really looking for. So, if you're not a well known expert, suck it up, be a servile cog and follow the script.
  - skybrian 8y ago
    It seems like there might be a middle ground, like being willing to play the game, that doesn't imply being "a servile cog?" The trick seems to be knowing when the game is worth playing. There are certainly situations where competition is too fierce and requires too much preparation, so it's not worth doing if you don't really enjoy the game. I'm not sure getting hired at a large tech firm is quite that competitive, though? They do hire lots of people all the time.
- nicoburns 8y ago
  My first reaction when inplementing anything more than a very simple algorithm is to google the best way to do it. Of course, I could probably come up with a way to do it by myself. I could probably even come up with an efficient way if I spent an afternoon/day on it. But why do that when I can google it, and get 3 blog posts and 2 stack overflow answers detailing the different options and the trade offs between them, most likely even with an implementation I can base mine off of? That's why these interview situations are stupid. They're like school where copying is cheating, whereas in real-world situations copying is a great way of doing something.
  - smallnamespace 8y ago
    > But why do that when I can google it, and get 3 blog posts and 2 stack overflow answers detailing the different options and the trade offs between them, most likely even with an implementation I can base mine off of? A lot of resources out there are wrong, inaccurate, or not reasonable for your particular context, and it requires a reasonable amount of algorithmic intelligence to be able to sniff out what's appropriate. If I had a dollar for every high-upvoted SO post that misstates a problem or doesn't offer proper caveats... but I can make that judgment because I've already thought about a related problem in the past. It's like asking why one should learn how to write properly when Grammarly and spell checkers exist, or why mental arithmetic is useful when we have calculators—at some point those your tools will be inappropriate or unavailable. Search tools are force multipliers, not replacements for personal knowledge and intuition.
    - nicoburns 8y ago
      > A lot of resources out there are wrong, inaccurate, or not reasonable for your particular context, and it requires a reasonable amount of algorithmic intelligence to be able to sniff out what's appropriate. Right, and having that algorithmic intelligence is key part of me being a good developer. But testing how someone implements an algorithm in time-scarce circumstances is not a good test of that kind of intelligence because it is likely to favour people who have been exposed to that particular algorithm before (even if they only rote-learnt information about it - as many interviewees seem to do in practice) over people who have the capability to think deeply and reason correctly about it, but have not previously been exposed to that problem.
Vel0cityX 8y ago
Except you don't need to have them _memorized_. You shouldn't. That's not the point.
- ec109685 8y ago
  But given it is straightforward to memorize, it isn’t a good test.
- Datsundere 8y ago
  Except all of these questions can be grouped into a category of the same kinds of problem and it is in fact spending time to find out that pattern and which category from sliding window, nested intervals, recursion and dynamic programming it belongs to
- TrinaryWorksToo 8y ago
  If you memorize them you appear more competent

rossdavidh 8y ago

If the interviewer is willing to talk it out with you, then it is totally a different situation. But, it came up in a recent other HN discussion on tech interviews, and it is an example of something that, if you memorized it, would have a vanishingly small improvement in your ability to get the job done. But, if you explain what it is in words, and have them whiteboard how to turn those words into pseudocode or somesuch, then it could be a appropriate, sure.

autokad 8y ago

I'm a data scientist, and google asked me to sum all values of nodes at each height of a tree. I had to implement the tree, bfs, and the algo (which was easy once you have bfs) in a 25 minutes, minus any talky time. BFS is not something I thought about much in the last 5 years, and quite frankly could care less about. I got stuck when I knew I needed 'something' to finish implementing BFS, but couldn't remember and the google interviewer offered no help. What I couldn't remember was the queue.

alasdair_ 8y ago
>I'm a data scientist, and google asked me to sum all values of nodes at each height of a tree. I had to implement the tree, bfs, and the algo (which was easy once you have bfs) in a 25 minutes, minus any talky time. THIS is the problem. The (unreasonably) timed nature of the exercise means that the only people that will do well are the people that prep heavily for this specific skill, in much the same way that people about to take the LSAT are likely to do better than it than actual fucking lawyers with proven experience.
- rossdavidh 8y ago
  Time (and being watched) do make it very unrealistic, but the other thing missing is that programming now is not like in the 1970's, you don't need to memorize much of anything. If you forget something, you look it up, it takes 30 seconds to remind yourself, "oh, yeah, the queue", and then you go. Testing if you can do it without looking it up is not testing the skills you actually need in order to code well.
- lr4444lr 8y ago
  Now take this analogy one step further: why aren't lawyers asked stupid timed LSAT questions at every job interview? Because they take a really challenging professional exam called the bar, which is a strong base level guarantee of actual knowledge and competence. Software Eng. have been fighting this kind of credentialing because somehow tech is "top innovative" for such standards. Hence the status quo, and why companies like TripleByte see opprtunity.

LaserToy 8y ago

Bfs is just one of examples. I can ask you a question you will not be able to answer without knowing the answer. There is a reason it took researchers years to find those optimal solutions

cornellwright 8y ago
Sure, you can come up with an algorithm question hard and obscure enough that no one will be able to answer it in the time given and no one will have bothered to memorize it because it's so obscure. That doesn't mean all "implement X algorithm questions" are categorically bad.
joshuamorton 8y ago
This is such a cop out. It took millennia to invent 0. That doesn't mean that 0 is an exceedingly difficult concept to grasp.
- Aeolun 8y ago
  BFS as a name isn’t a difficult concept to grasp either.
  - joshuamorton 8y ago
    Neither BFS the concept, nor 0, the concept are particularly hard to understand. That's why I used the word "concept". If you disagree with that, I'd be interested in what you feel is exceedingly difficult about the breadth-first search algorithm to understand, or if you prefer, to explain why the time it takes to discover or first write down a concept is strongly correlated with its age. Consider that BFS was first published in 1945, while the turing machine was published almost 10 years prior. Is BFS an implicitly more complex concept than a turing machine? That seems like a strange argument to make, but I'm certainly interested.
- mehrdadn 8y ago
  I don't understand your comment. Was the parent suggesting BFS (or the like) is an exceedingly difficult concept to grasp? And if we're going to claim understanding BFS is like understanding zero, then wouldn't that just mean it's just as silly to complain about a question on BFS as it is to complain about a question on zero?