This is not at all implied by anything else in the article. This feels like a common "I'm unfamiliar with it so it's bad" gripe that the author just sneaked in. Once you become a little familiar with it, it's usually far easier to both read and write than any of the alternatives. I challenge anyone to come up with a more readable example of this:
var authorsOfLongBooks = books
.filter(book => book.pageCount > 1000)
.map(book => book.author)
.distinct()
Specifically around type-safety, that is knowing that the chained type is what you expect and communicating that expectation to the person who is reading the code without them needing to know the wider context of both the chained-API nor the function the chain resides in. In the context of this article, that means more complexity, and therefore less readability.
I feel this is important because I have worked on many legacy code bases where bugs were found where chains were not behaving as expected, normally after attrition in some other part of the code base, and then you have to become a detective to work out the original intent.
For readability chains are bad, because they can lie about their intent, especially if there’s various semantics that can be swapped. But, like any industry or code base, if their use is consistent, and the api mature/stable, they can be powerful and fast, if.
This does require a rather skilled interviewer, so the benefits may well not be worth it. But it can be very interesting information to have.
The “thinking ways” that allow one to solve the problem can be considered to be socio-normative and neuro-typical; normally these fit white patriarchal modalities.
The mental modalities that make it harder to solve such problems are those related to sequence memory weaknesses, comprehension weaknesses, stress factors, attention weaknesses, social differences, exposure, culture, education. So dyslexics, ADHD, Autistics, socio deprived (poorer backgrounds), may struggle with tums like this that assume a consistent world view - when in fact they likely have other strengths in problem solving. It’s not a one size fit all.
Additionally like IQ, ability to solve these types of problem is down to either natural ability or practise in the domain - that is you can increase your IQ by training against the core elements IQ tests look at.
I tend to get candidates to take me through something they know well, or love, or have solved, and then I ask them about how they did it. This shows me genuinely how good they’ll be at the job in hand.. and is why my teams are actually diverse.