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.

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....

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.

I’m not saying that given a scenario, I couldn’t figure out a way to do it, but at the level of a job that I would be applying to after all of these years, would a company really be more concerned about whether I could write a breadth first algorithm or how well I could design a highly available, fault tolerant, redundant system, write maintainable code, my mentoring and leadership capabilities, my experience with Domain Driven Design, my years of experience designing and developing “cloud first solutions” (yeah I grown a little bit when I write that), and certifications?

My current employer asked me no programming questions even though I supposedly came in as a “Senior developer” in my small company.

He was more concerned about everything I mentioned and how could I help mature the organization.

Heck, he didn’t even care that I didn’t know any $cool_kids front end framework.

Whenever my last day on my current job comes and I don’t expect that to be for a few years, I’ll probably end up working for a consulting company as an overpriced “digital transformation consultant”, “implementation consultant”, or “solutions architect”. Do you really think they are going to ask me about my leetCode capabilities?

The same should be true for anyone at a certain stage of their career.

I would kind of expect that if you can design a highly available, fault tolerant, redundant system then you would figure it out. I can see how you could find the question easy and not allowing you to show what you can do. But that is opposite situation. A lot also depends on the position. If the position is not leadership position and does not require specialized knowledge you have, I don't think the company does wrong by not asking about it. Then those easier questions have place. I assume that overpriced "digital transformation consultant", "implementation consultant", or "solutions architect" does not write code or only little of it. As such, code focused interview makes no sense. It is however different for position that writes code a lot.

I don't get insulted over basic questions. Mostly because I worked in a company that did not asked programming questions. As a result had to work with few people who could talk design and maintainability such, looked like great socially and turned out they could not write the code except in simplest situations. It was not good and harm was long term, Largely because of resentments etc that build up in team who had to do someones work while that person was treated as superstar. Such person needs strategy to mask inability and those are all toxic - masking own inability by blaming others etc.

What are alternatives out there? Take home assignment, fizzbuzz, simple algorithm, trivia questions, requiring you to already know exact technology they use. Someone complains about every one of these. There is no hiring process that make everyone happy and fit everyone, but imo, as long as company does not go to some crazy extreme somewhere it should be fine. If candidate have to balance red-black trees then it is very clearly too much, figuring whether string is palindrom is not too much.

There is also something good to be said about repetitive hiring process where company can compare how people did on interview and then how they did in real life. As such, it will contain some generic or easy questions.

If you are getting paid to solve business problems, then why not have them solve simple version of business problems?

My interviewing process for developers is giving them a skeleton of a class with corresponding unit tests that they have to make pass.

Then they get another set of unit tests that they have to make pass without breaking the first set.

The code models a simplified version of real world types of problems we had.

That sounds good, really. It is better then asking about breadth/depth first search. Added bonus is that potential employee gets some idea about what he will do daily too before making decision.

Another way to screw hiring is to select for algorithms loving geek who seeks algorithmic challenge and can recite obscure edge cases - and then put him on position where he has to solve normal business problems or maintain unit tests because that is what job is. And then wonder why genius is demotivated and does not seem to produce.

But, I still don't think either of these search questions is outrageous or a deal breaking question. It is within acceptable questions range - partly because it is so common that I would expect a person to quick google it if they heard it twice already and did not figured it out in stress of interview.

After 20+ years I'd expect you to be able to make it up on-the-fly.