Either they've never had to work on a really Hard Problem, or worse they have tried to solve such a problem without the hard-won lessons present in these books.
I've heard senior recruiters express skepticism about candidates who say they're into "Hard Problems." Experienced engineering managers usually hear that phrase when you're looking for a lifestyle and you don't really care what the application is.
For example, "I have no qualms that your business arbitrages nonconverting clicks from bots and sketchy web traffic (i.e., 99% of the Internet) into Google AdWords revenue, using up a Google customer's ad budget until the customer has barely made a profit... You see, I'm into Hard Problems. Besides, bots don't click twice! It must be real traffic!"
It turns out that junior people on the interview team care a lot more about Hard Problems and the stories in these books than senior people do. And you'd never want your hiring pipeline run by junior people.
In my opinion, Google's focus on Hard Problems has robbed academia of all the sincere Hard Problems people. Then, they've ruined the interview process for everyone else, ironically with the book How Google Works, convincing CEOs that they should be asking about C.S. fundamentals and Hard Problems totally unrelated to their Actual Problems.
That said, I happen to like problems in general... not necessarily "hard" problems, but just new problems. I also like working in new domains... I mean what other industry of work allows you to work in education, aerospace, banking, security and marketing in a decade and a half.
Hmm. Arguably small operations need to be more stringent if they are deciding who will make up the next 25%-33% of their engineering workforce. At small companies one bad hire can really poison the well.
I mean, have a trial period of a week or three... That will tell you far more than a gauntlet interview process with a lot of false negatives.
Also, there's the cost of existing staff in interviews... if you only have 2-3 devs, and you're keeping them all in interviews with multiple candidates, you're not getting work done.
Before starting my own company I was a bar raiser at Amazon. Interviews were not supposed to last weeks (though many did and there were internal metrics aimed at driving interview to offer cycle time down).
I'd much rather spend a few hours per interviewer per candidate getting a solid candidate than hiring, onboarding, training, learning the candidate is a poor fit, and ultimately going through the not-fun-for-anyone firing process.
High turnover isn't worth the lost productivity from other employees or the hit to morale. On top of that, while learning whether or not the candidate will make it through the trial, you're burning precious cash.
Learn how to interview and teach your people how to interview. It will save you heartache and money.
Especially when many of those concepts necessitate code that is less than discoverable, well documented and easy to follow?
Can you explain what this business model is and how the arbitrage works? Is this SEO gaming? Thanks
A large part of the job market has little need for those kind of books.