I disagree with the premise that the following are contradictory:

    1. “It tests CS fundamentals.”
    2. “It tests reasoning through a new problem.”

Both can be measured in an interview together, using well-known CS concepts to reason through a new problem based on CS fundamentals.

Especially today, as almost everyone uses standard library implementations, asking candidates how those implementations actually work, and then working through a variation of them (e.g. add an unusual requirement) is very useful in an interview context.

Everyone "knows" what a Linked List, so you don't have to spend a lot of valuable interview time explaining it. The implementation for the simple case is short enough it can be quickly written out. Then you can add a novel requirement for the candidate to extend their implementation. Now you've checked all 3 boxes:

    1. Knowledge of CS fundamentals
    2. Using well-known CS concepts
    3. Reasoning through a new problem

If interviewers were longer, or used alternate paradigms (take-home exercises or pair-programming), then much better questions can be offered.

But ultimately, doesn't all software engineering come down to the 3 things I described? Sure, the context is different if you're a Frontend vs Backend vs Mobile vs Embedded person, I hope the interviewer is adapting for that and not asking everyone the same Linked List question.