I don't know, maybe some places do have ridiculously hard problems that you just have to memorize the algorithm for, but personally I haven't seen that. It's more like advent of code style stuff that you kind of just figure out by yourself.
However I wasn't as fast as others as I didn't recognize any of the questions and had to work through them. Interviewers expect you to be fast, or at least compare you to people who seem faster. Doesn't matter who studied or not, or who will actually perform better on non-leetcode tasks.
Also having kids is a real issue, it absolutely crushes the amount of time you have to anything besides working.
I don't know where you've been doing coding interviews. I'm pretty confident there are leetcode type problems you will have a hard time with and won't be able to complete in the allotted time. I'll share one of my experiences with a FAANG.
My interviewer first spent a lot of time "getting to know me" and asking trick questions, and stressing he also previously founded a startup, then handed me a problem and demanded I find the optimal solution in ~10 minutes and also wanted me to talk while working on the problem. I could not remember the arguments to a function and couldn't concentrate. It bombed.
A few days later I was sent prep material for an interview at a different FAANG. One of the videos was the author of cracking the coding interview solving this exact problem on a whiteboard. It took her more than an hour to arrive at the optimal solution.
So in short: 1) interviewer had unrealistic expectations
2) interviewer wasted time with introductions given his expectations
3) interviewer asked trick questions to determine whether I am a liar even though it was pretty clear from the introductory conversations that was highly unlikely
4) interviewer created an awkward interviewing environment and triggered my anxiety
5) interviewer thought I should be able to code while talking
6) interviewer probably forgot how long it took him to solve the problem originally and probably never timed that
This isn't discrimination on age this is discrimination on dedication to craft. Young people can have obligations outside of work just as easily as older people.
-- signed an old man
I'm saying that testing people for their skill, in any way, will have imperfections and will wind up excluding people. If it excludes people based on something they can control that's probably not the worst thing. Not everybody can get time to practice, but do I really want to be working alongside people who don't practice? Maybe in some jobs I do maybe in some jobs I don't.
If someone really does have 20 years of experience then a single evening of practicing will do a lot more for them than it will a fresh faced kid from college even if that kid from college does it for two or three hours every day for a week.
I just simply don't accept the notion that leet code interviews favor people based on age.
Why would I take my career less seriously than a game?
I don't doubt that at all. But I've also had that on a whiteboard.
Also, it sounds like your interviewer was a jerk. Which seems orthogonal to the style of interview.
I'm not older, but I was in the industry prior to the leetcode style interview. I've never sat down and "grinded" leetcode but I've also never had a problem with those styles of interview once they became common. Neither have my former co-workers. I have a few friends that are still working, past retirement age, that would crush any problem you threw at them.
In my experience, it's not much different than the whiteboard interview. Sure the presentation of a problem can stump you for a moment, but with a few good follow up questions a solution, however naive, becomes apparent.
I had a mentor early in my career that repeatedly said "There is no such thing as an unsolved problem in computer science". I think that mostly holds true, you either recognize the pattern and implement, or you learn and implement next time.
That all said, leetcode style interviews are the interview version of a "bad code smell" and I'd strongly prefer a bug-squash style, even if it was in a completely unfamiliar programming language. Actually, an unfamiliar programming language might make it fun.