Yes. If you don't understand one layer below the code you wrote (a rung below on the ladder of abstraction) then you cannot understand if you are even using the correct abstraction (if the library is doing the thing it says it does when you call x). You literally have no idea what your code does, or even should do.
A linked list is a perfect example. If you use a linked list, you should know the basic properties of a linked list. When given one from an unfamiliar library, you should go read its code. You should run some basic performance tests on it. You should separate it from your code via some basic delegating api, so that you can replace it with another implementation in the future.
And concurrency is another example - do you need, and does, your chosen library give you parallel execution, or merely asynchronous execution.
This isn't as onerous as it sounds -- you do it all the time. But blindly trusting any software without a proof of its correctness (encryption is an example of where you might not understand ecen the interface layet of the software, but use it directly anyway) is a dangerous habit.
If there's magic there that you don't understand and you choose the library, when that magic fails to satisfy some goal you need to understand why so that you can fix it, implement your own workaround, or swap it out with a library that does what you want.
If you use a concurrency library, and don't understand threadpools, block in a thread and threadlock your application, you are in trouble.
If you use IEnumerable, and don't filter out the results before you toList, you are in trouble.
If you use monads and think flatmap is stack safe, always, you are in trouble.
Note you don't need to know ALL the tricks. Just the ones employed by the functions you call.