> Sure, those statements (just use an existing library) are what you'll do in practice especially as a beginner
The more code you write, the more you have to maintain. Sure, of course there are times where you need to re-implement something from scratch. But those times are rare (or should be). Making something from scratch without strong justification is a strong signal, just not a positive one.
Now, as you point out, "when would you write x from scratch" is a great question to ask someone. I am vary wary of people that are willing to overspend innovation tokens. But thats a design/systems/culture question, not a coding question.
the signal I want from a coding test is the following:
o Can they demonstrate and understanding of the programming language?
o Do they create readable code?
o Do they ask questions?
o Do they follow the style of the programme they are modifying?
o Do they say "I don't know"?
o Do they push back on weird or silly requirements?
all of those things make working with someone much easier. None of those questions require "implement algorithm that only exist in Computer Science courses". They can all be answered by something like:
"here is a program that fetches a json document, but it breaks often, please make it more reliable"
That is far more realistic, and more likely to what they'll be doing.
The dirty little secret about most coding jobs is that actually, the important thing is getting something functional and stable for the business, so it can make money. Then after that its responding to feature/bug requests. As a programmer, your job is to convert business logic into computer logic. 99% of the time, this doesn't mean making artisan libraries that improve some tiny metric by 20x.