Even a simpler real world problem whereby it takes days of research is not respectful of your time. I've seen people note they can't take a 6 hour time-out of their busy work/home lives to do coding challenges that are popular among startups.
So the balance is in-person interviews. Ones where you have to give difficult problems, ones you haven't seen before and ones that don't take days to explain. This usually means algorithmic, data structures, or mathematical in nature. They have subtleness, depth and complexity. As for 'reverse a string', you'd be surprised how many people who have "programming jobs" who apparently can't do basic programming.
And do I use these skill sat my job here? Yes. All the time. I'll spare you the spiel about "everything's different at scale". Google is a different kind of company that attempts to solve as many problems as possible with CS.
For reference, I work at Google, given interviews here, and passed the interview bar twice. Once at 29 and once at 39. Some of my coworkers are older than me. Many of them have children. Some are younger than me. I see plenty of people in the office with grey hair (I work in the SF office).
I refuse to defend past practices, but I believe the company currently sincerely overall seeks to be the best employer for any age. Small pockets of suck happen, but the internal transfer rules let you switch without your manager's permission. The interview process is known to not be perfect, but that is inevitable for any process - nothing is ever perfect!
However, the interviews do involve whiteboard problem solving. I understand some can't do it, and this is one of the blind spots. I personally love diagrams, and think visually, so it works for me. I also prefer when my colleagues use diagrams as well.
About diagrams.
I had the whiteboard experience once and will avoid repeating it.
When I get a problem I want to sit back and think about it. The interviewers kept insisting that I draw diagrams, and that interrupted my thought process, they were not impressed.
However that does not mean I am incapable of making diagrams once I've sorted the problem out in my mind. After I've arrived at a proposed problem solution I like to produce a written document with just enough information to convey the problem and the solution approach, together with whatever diagrams, data structures, and pseudocode are required to communicate.
That's how I roll. ymmv :)
As a side note, I think there are fundamental limitations to "solve entire problem in mind" - tooling, including written word, pens, pencils, crayons, paper, documents, diagrams, whiteboards, provide methods for expanding your working memory.
One other thing "just enough information" is a phrase that worries me. I've seen a lot of academically written papers that basically "by implications you should know that the resulting answer is X". I'm not sure this is your style or not, but it is one style that personally I believe has no place in the workplace. Convey your ideas clearly, and help your coworkers.
With regard to your other two points I either wasn't clear or you took my comments too literally. Be that as it may, let me clarify.
I do form my entire impression of the problem and various solutions entirely in my mind, without the aid of external memory. However, and this is important, that evolves out of research. During research I build something like an intuitive understanding of the problem. Along the way I consider possible solutions to the evolving problem, solutions by others or that happen to occur to me. Eventually, usually at night when it's quiet, I have an insight, which often turns out to not be quite right. Rinse and repeat until I have something that seems good. At which point I will sketch out some data structures (as struct or object like things, or simple diagrams) and some pseudo code to operate over the data. If that finds a flaw in my idea I go back for more rinse and repeat cycles.
When I say "just enough information" I mean just enough for any engineer with sufficient experience and background to fully understand the problem and solution. I don't leave anything out, I want feedback and I don't want the feedback to be "huh?". By "sufficient experience and background" I am leaving open the possibility that there might be someone in the group who doesn't quite get it, but to tell the truth most good solutions to most problems turn out to be reasonably simple, simplicity is one of my target criteria. Simple solutions are easier to implement, less likely to have bugs, and if the solution is both simple and good the performance is likely to be at least acceptable as well.
Better? :)
The one thing I'll say is that with your background, it's a shame you filtered yourself out. You might not have gotten through the interview process, but if you retained anything significant from what you cut your teeth on you also might have been more successful than you think.
http://nautil.us/blog/why-blind-people-are-better-at-math
It seems that I'm better at doing math in my head than most people. I've wondered whether that might be related to aphantasia.
I was contacted by Google several times but chose not to submit myself to an interview process which I feel is biased in favor of CS graduates and consists of exercises which provide little insight into the most important characteristic of a good software engineer; the ability to understand the nature of a given new domain, the problems to be solved in that domain, and good ways to solve those problems.
I cut my teeth on MIT's Computations Finite and Infinite by Minsky (now out of print), Donald Knuth's three volume classic, and later The Structure and Interpretation of Computer Programs, which, at least, I suppose recent CS graduates are familiar with. And many many books after those.
Over the subsequent decades I have developed many unique algorithms to solve specific problems. Most recently, the past month, I increased performance of a graph database issue by an order of magnitude by creating an abstract representation of the graph connections in RAM. That is not a terribly unique approach but somehow it never occurred to the CS types here that the cause of their performance problems was a failure to understand the fundamental nature of the problem being solved.
If Google's filtering consisted of solving a real-world problem, one requiring some days of research and development, then I'd be happy to go toe-to-toe with recent CS graduates. I know how to use The Google to find related domains, problems, and solutions. After understanding the nature of a problem research is step #1, regardless of whether I think I already know a good solution, it is almost always the case that someone has already solved a similar problem (if not the exact same problem), there is value in understanding the differences.
But I suppose that's not a practical filtering process for a company hiring many engineers and not having the resources to evaluate real solutions to real problems.
Also, side note, approximately 5% of the population do not imagine the same way the other 95% do. Like me they cannot, to varying degrees, actually visualize anything with their eyes closed. I never see anything but black with my eyes closed, when not dreaming. I suspect that this is related to my inability to do whiteboard exercises. I don't visualize, I think.
'nuff said