it's impossible that they don't know about it. the more i think about it, it's that they're either lazy or want to select for age but obviously can't do that in an overt way, so they pick a tool that nobody with a family has time to grind (i.e. 'old' people)
Vast experience in compilers, embedded systems, functional languages, graphics, dev ops, or cloud technologies will be of no use. (Perhaps it will be later, if you get to a systems arch interview step.)
For example, the only time I ever encountered red-black trees was in the context of prepping for software interviews.
Mine had data structures and software engineering as CE-specific requirements (along with a dash of microarchitecture and HDL/FPGA stuff), the CS algorithms course was an elective that obviously gave priority to CS majors.
Beyond that, we had a department head that really only cared about shoving as many EEs as possible into the PG&E hiring pipeline.
Here's a radical idea (read to the end before you object). The inspiration is a blend of how open source projects recruit developers, and how the 20% Google side-projects used to work.
I work for company A, I'm starting to get slightly bored or interested in doing something else. Without quitting my job, I contribute a few days of code to company B, whose project I find interesting. As I contribute more to company B, I eventually quit company A and join company B full-time.
Benefits of this approach: no interviews. Know what you are getting into. Try different things and what works for you. How can we make this work: legal framework. California, if you are listening, pass a safe-harbor law that prevents companies from exclusive work arrangements, so I can always do a side-gig with company B even if they are competitors. Have company B compensate me, so we don't end up in a situation where company B is abusing job seekers by getting free work done. Maybe a law could say that I'm safe as long as my work for company B while employed by company A doesn't exceed 5% of my salary or so (so I worked for company B for a few days or weeks, not months). Would that work?
Certainly there are other ways to verify someone can code: code samples, talking through high level language concepts, reviewing existing code, etc.
What people should be focusing on is this - 1) Do you understand enough systems architecture / code techniques to succeed at this particular company? This can be done via mostly talking. 2) Do you have experience that will help us with our company-specific problems? Give them an actual problem you regularly deal with, and get them to attack it.