Consider: You're hiring for a senior systems software development role, and the candidate doesn't know what an instruction is.
etc.
Something trivially google-able is like not knowing the syntax for generating permutations of a sequence in Python. But not knowing the idea of permutations would not be trivially google-able.
I did spot them the malloc() call (I certainly would not have wanted the interview to get bogged down for that), but yes, I did hold not knowing that against them in my evaluation.
That is, local LAN only, with no access to the internet, and no internet-capable "personal electronic devices" or cellular phones permitted in the development area.
You had whatever paper documentation you brought yourself, what was in your head, and whatever was in the /documents directory for that project.
It's a different work mindset. I've since moved to a sysadmin position, running a closed network. When programmers decided they couldn't hack being cut off from the net, they'd quit. Dealing with vendors who signed a contract swearing their product didn't need internet access to install or function, when it won't even complete the install without internet access, is more awkward. Particularly when we call the lawyers in. Because that's why we tediously explained the while "no internet" thing in the contract. That they signed. No, not even for just a few minutes. And by the way, can you explain why your installer times out trying to contact servers in three different countries? Our network admin is curious...
It definitely tests your skill and you can identify who can solve problems on their own. Hopefully you have an additional network that you can do research on.
If what they Google would provide them the correct answer, I'm OK with someone who knows how and when to Google something. Those that don't think about researching themselves usually end up asking me in-person. And I usually then ask them if they have done any research themselves.