I disagree. Consider: You're hiring for a data science role, and the candidate doesn't know what an array is.

Consider: You're hiring for a senior systems software development role, and the candidate doesn't know what an instruction is.

etc.

I don't think knowing what an array is would be something you can trivially Google. Sure you can look up the set of words that make up the definition, but that's not knowing what it is.

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.

It comes down to what one considers "fundamental knowledge" that one needs to do the job. If you claim to be a programmer, but don't know what an array is, you're probably not actually a programmer. But not knowing esoteric data structure that one may encounter once in their career is not really indicative of anything.

Would you agree that what an instruction is depends on context?

Yes, ofc, he is applying for the "senior systems software development" role so there is our context.

I once interviewed a candidate who (1) picked C to solve the programming problem they were given (some other languages were acceptable, and, actually, preferred) and (2) did not know how to dynamically allocate memory in that language.

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.

Isn't this the case for most interviews? You could simply Google in almost all scenarios. Also, you can fail a single interview and still pass assuming all other interviews go well.

Using Google is the expected real world situation no? I think being able to figure something out you don't know is better than demonstrating something you know perfectly. You'll find out much more about someone if they can do this rather than asking them mundane syntax questions or if they pre-learned how to reverse a binary tree.

I've worked on several projects that used "Black Chamber" development.

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...

I've worked in these environments before (not as a programmer though).

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.

Dropbox is literally creating a vector for copying your files to the Internet...

When I interview a candidate, if they don't know the answer but say "they could Google it" I would then ask them what they would Google.

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.