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)
For example, if your solution involved generating all permutations of a sequence, and you didn't remember how to do that efficiently, I would let you make up a black box function that just does it. We might come back to this later in the interview, but I'm generally uninterested in whether you memorized an algorithm for it or remembered how to call the standard library function that does it.
That said, if you make up the black box function, I might dig into why you designed the function signature the way you did, and I'd do that to see whether you can talk about code design from a "other people will read and use and debug your code" perspective.
But sometimes, the interview question is generating all the permutations :(
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.
The biggest problem with whiteboards is that they reward exactly what they say they try to weed out, rote memorization. It's no secret you could spend weeks practicing on leetcode for an interview but those skills simply don't translate to real-world programming. Algorithm design is maybe 2% of software engineering. The vast majority is knowing what pieces of technology are out there in order to avoid reinventing the wheel all the time. Whiteboards don't test that skill. It tests a marathon runner on their 100 meter dash time.
This 100% happened to me (apart from being laughed at) only it was even more of a meltdown. Also 10 years experience and a problem I could do in my sleep. It was my first interview after a long time and it triggered performance anxiety and nervousness.
The solution is you need to practice live interviews, not just leetcode solo.
You could argue it's stupid and colleges should only look at personal essays and GPAs and extracurriculars. But then there's problems with that too (lack of standardization for one).
You could argue that high schools shouldn't teach trig or calc because they're largely irrelevant to most tasks in most fields and "what does that say about the system". But actually they do come into play once and awhile and lay a conceptual foundation, so they're still sort of useful to learn. And thus they form a good common foundation to test aptitude inside an hour or so, or at least no one's thought of a better one.
The truth is, software engineering really quite hard, but that whiteboard interviews just happen to be a rather poor way of evaluating candidates.
A work sample test, structured interview, or IQ test (alone or in combination) would be a much better filtering process.
I'm not sure what any of these mean in concrete terms. Is an IQ test like those "why are manhole covers round" Microsoft questions of yore? Yuck. Is a work sample a homework test? That takes more time for both parties. It's not a good substitute for a 1 hour first round screen. And what's a "structured" interview??
Now I'm not saying the situation isn't complicated. In the mid-20th century, IQ testing was a great driver of social mobility. However, as was pointed out in _The Bell Curve_, it's becoming the opposite. From what I understand, the heritability of IQ and assortative mating (i.e. people marrying other people of similar IQ/educational attainment) are the main drivers of this.
I don't think the formation of an entrenched class system is necessarily a good thing, but I think in the local context of our industry there's still a lot of good that could be done by improving our hiring process. I mean, would you rather hire people who only sound smart, or who are smart?
https://www.wired.com/2015/04/hire-like-google/
If you have more questions after reading that, then ask away.
I think there's a serious disdain for interviewing in general. The whole process sucks from end to end. Often it's because the interviewers just aren't good at it. But when it comes down to whiteboard interviewing, I think it's about your value system.
More specifically, I think every interviewer has an opinion on the practical <--> theoretical spectrum, and the problem is when the candidate disagrees with the interviewer's opinion on where on the spectrum the interview should be.
The upside of a practical interview is that you are testing whether they can do the work. The downside of a practical interview is that it indexes heavily on experience and lightly on the ability to cross disciplines. Theoretical interviews are the reverse.
So the important question is: what does your team care about? Google will care much more about the ability for their engineers to move around than your startup will. In general large companies will care much more about portability. They have deeper pockets and are therefore more willing to train you on the job, so generally speaking if they think you can ramp up (even for senior hires), they're happy. As much as startups will say they see things this way, it's not really true. Startups in general care that their senior hires come with substantial domain expertise.
It's a whiteboard, I'm looking out for far more important things than whether the method is named `size` or `length`.
But I do think that Computer Science Jeopardy on a whiteboard is a bad idea.
A shitty interviewer will follow a rigid script and "ding" you on trivial errors.