That's not it - it's that interviewers set problems that they already know how to solve. They forget how hard it is to solve new problems on the spot in an interview setting.
In my experience technical interview questions are usually way harder than they need to be. I don't agree with getting rid of HackerRank style filters entirely because they save you a ton of time with candidates who just can't code at all (or candidates that think they aren't applying for a coding job). But the questions should definitely err on the easy side.
As an ex-Googler who's done a fair bit of interviewing, my bar for "will I use this coding question" is to look at the problem statement, do a from-fresh implementation in a suitable language, and if it took me more than 7 minutes, it is not suitable for a 45-minute interview slot (I would expect the candidate to have a solution in ~20 minutes, then maybe 10 minutes of follow-up questions, then flip to "do you have any questions for me").
I thus gave the candidates roughly three times longer than I needed to solve the problem myself, which should pretty much account for the interview situation.
In my experience technical interview questions are usually way harder than they need to be. I don't agree with getting rid of HackerRank style filters entirely because they save you a ton of time with candidates who just can't code at all (or candidates that think they aren't applying for a coding job). But the questions should definitely err on the easy side.