[dimino]

I guess I should rephrase. I've been programming for ~8 years and I've never been presented with a problem that insisted I know what BFS was explicitly.

It is intuitive, which even further pushes the question "Why do I need to know this to be an effective programmer"?

[Morgawr]

You don't need to know BFS, you need to show that you can come up with a BFS implementation if you need to do so. You can always say "wait, remind me again, which one was BFS?" and the interviewer can certainly tell you at least what the conditions are. Maybe he might think a bit less of you (although I personally wouldn't) because BFS is a really really common name in the jargon of a programmer, but still it's better than simply blanking out and then angrily claiming that it's unfair to ask BFS.

A similar question could be "Can you print in order all the elements of a given tree/graph?", would you find that more fair compared to straight out using the word "BFS/Breadth First Search"?

[dimino]

Yeah, I think presenting the actual problem rather than a jargon test is a better way of determining a programmer's competency, but even then I'd prefer to ask questions specific to the problem domain, like if you're a streaming company ask about compression algorithms.

My favorite questions are when companies ask actual problems they're having and try to get the interviewee to suggest solutions and/or implementations.

[bad_user]

How can anybody have knowledge about compression algorithms without knowing what BFS is? This is like claiming to be a mathematician and not knowing what rational and irrational numbers are.

You speak about the problem domain, but the primary problem domain we are facing first is programming. And without a shared vocabulary, you can talk with other software developers, but you aren't going to be very efficient in that communication. So going back to the problem domain, as software developers we are supposed to master whatever problem domain we are facing, in order to efficiently communicate with the business side in their own domain-specific language. How are we supposed to do that if we haven't even bothered to learn our own domain-specific language?

But it goes deeper than that. Many software developers these days rely too much on libraries, without knowing how they work. And this hurts them a lot.

This is all about standing on the shoulders of giants. And it all starts from the most basic data-structures and algorithms. BFS is right up there with the characteristics of a List or a Map. It's common knowledge that everybody should know. And this common knowledge is half of "Introduction to Algorithms" by Cormen et al. So instead of reading another fluffy piece on Agile methodologies or on soft skills like the "Pragmatic Programmer", or other such bullshit, maybe people should read this one instead.

One recent problem we had was one of scaling out our micro-service-based infrastructure. And I've heard from colleagues wild ideas like "oh, lets introduce an external queue, like Kafka". DevOps for some reason think external queues are the solution to all problems. Yeah, great, but this isn't a freaking webpage reading from a database, we've got singletons, as in producers of truth that need strong consistency in their decision-making because we aren't that smart and you're just moving the problem around, because locks don't freaking scale, no matter how smart your queue is. Or "we'll just add Akka Cluster or Finagle or whathaveyou, should take care of it". Dude, yeah, we've got singletons, which means we need to do sharding and have a protocol for failure detection, so maybe we should talk about that first.

This is just a recent example. Developers are so eager to jump to the latest fads and the latest cool things, without thinking for a second if those solutions would work, only because they can't imagine how these tools are even implemented. And this isn't something that a superficial Google search can fix, because the unknown keeps piling up, the more complex the system is, until the shit hits the fan and you throw your hands in the air and bring in external consultants to fix it. And if you think the UI is spared from all of these problems, think again. I've seen dozens of Javascript-enabled interfaces with performance issues, only because of the "thundering herd" problem happening due to sloppy event handling. How many UI folks understand how Facebook's React works? Not that many.

[taneq]

Because it's not intuitive to some people. Some people just don't 'get' it. The assumption is that such people are probably also not good software developers.