If nothing else, again, it's an opportunity for a conversation— the person might have a great war story about how they deep-dived on library X after finding it lacking, or tried to submit a PR that was shot down. Or even if they had no idea, it's an opportunity for them to demonstrate teachability, like "oh that looks nifty, yes I can definitely see how that would make this whole section redundant and the rest easier to read."
As an early career developer, your team wants you to write useful code with few errors and that works best when you can rely on established libraries.
But as your career progresses, your value comes from understanding how those libraries work and from being capable of writing new libraries that support and stabilize the early career developers coming up behind you.
And the only way to go from the first group to the second is from getting your hands dirty. Writing personal and hobby projects that “reinvent the wheel” is one of the best ways to do that.
One of the reasons why I enjoy programming as a hobby and avoid it as a profession is the pleasure of reinventing the wheel. For example: I learnt how to use git and am learning how to read datasheets is by taking simple Arduino programs then refining it until most of the abstractions are removed. Likewise, it can be fun to implement my own data structures and algorithms. Contrast that to simply using libraries. It's mostly an exercise of reading documentation and hoping that a tiny subset of what's learnt is transferable to other libraries.