I'm a micro-optimization and numerics guy by trade (mostly I write math libraries); they are almost completely irrelevant to my area of work.

Priority queues should be covered in a competent introductory data structures course. Bloom filters are marginally more obscure, but I still expect a good candidate to have come across them at some point. They're so widely used that it's pretty hard to avoid learning about them if you've done any significant amount of work or just spend time reading HN (they come up in someone's blog every month or so).

Note that I said "would hesitate to", not "wouldn't hire". If someone were otherwise a strong candidate, but happened to not be familiar with these, I would almost surely still hire them.

I should clarify that a typical candidate for a junior position on my team is either coming from graduate school or has 3-5 years experience in industry. I have correspondingly higher expectations for their background knowledge.

I've been working as a software developer professionally for 20 years and I only came across bloom filters a few weeks ago.

This is just not true.

Bloom filters are marginally more obscure, but I still expect a good candidate to have come across them at some point.

Possibly in your area the candidates you get may have come across them, but then they wouldn't be junior engineers, by definition. If you're advertising for "strong algorithms" candidates then sure, but I bet half the people reading this have never used or come across any probabilistic data structure!

> then they wouldn't be junior engineers, by definition

I don't think so. My impression is that junior/senior is defined by years of experience more than technical skills. Having been out of university for one year now, I know I sure as hell won't get a job as a "senior engineer" anywhere, even if I could easily implement both these structures.

Those aren't basic at all, and I'm not sure why the commenter considered them so. As we all know, junior engineers have very limited exposure to a small area of tech, that's the very definition. It might just happen to be that the dev just finished a CS degree and is great at some of these algorithms, but that doesn't translate into a wide spectrum of technologies, which is only found in people with many years experience.

I was the one that actually picked those, just out of thin air to illustrate my point.

This I feel pretty confident that if they were the best solution to a problem I was having, I would find them through research. is exactly my point. How would you know that a bloom filter might be the best solution unless you know of it's existence in the first place. An architect's role is to suggest areas of research to junior engineers, who very likely may only have some vague memory from algorithms class.