This is great but the premise seems kind of straw man. I don’t know a single developer that thinks “googling stuff means you’re not a proper engineer.” Perhaps this is a reference to the interviewing process. Tests are a different thing, though. I’ve been on practical technical screens where you can google, because the test was about building a larger system, and they don’t care if you don’t remember this or that API…
Isn't that what a whiteboard interview is? Proving you can do things without google or else you aren't a proper engineer? (For the record I disdain whiteboard interviews as the accepted metric for testing one's ability)
In any case, there's a lot of strategies to show that you understand a concept without relying on exact memorization. For example, a common answer I give if I can't remember something might be something like: "The language has a sort function that can accept a list, I don't remember the exact API or the underlying implementation but let's assume it's n log(n) as that's a common runtime complexity for sorting--I'm going to define that as 'sort(listArg)'." I don't remember the exact function, so I'll just define and explain how it might work myself. If you're expected to be able to compile the code you're writing, simply ask the interviewer and explain the API you're looking for, I've had great success with that as well and prefer when an interviewee asks me over staring at the screen or board.
If it's a problem where you're expected to produce some algorithm, if you can't come up with any solution, explain to your interviewer what you're stuck on. They may provide a hint that will get you rolling. I had this happen during an interview at Microsoft (spoiler, I got the job) where I forgot how to determine the length of the hypotenuse of a triangle haha. The interviewer wrote the formula on the board and we moved on. Interviewer later told me I seemed nervous and he chalked it up to a brain fart--good call, I was really nervous! The point of that problem wasn't to see if I knew the Pythagorean theorem--it was just a small piece of the puzzle I was stumped on. Similarly start from a simple, naive solution, and interatively optimize rather than trying to recall a perfectly optimal solution. If time is running low, explain your intended optimization or ones you think might be meaningful, making note of any uncertainties in that explanation.
I've worked at Microsoft, Amazon, some other notables and interviewed at many others. I am speaking from that experience. Others may have better ideas. Of course, not all places approach this in a reasonable fashion and some are just missing the point entirely with their interview and they do expect you to somehow memorize everything.