Small software companies. (Not startups.) They really need people who can do the actual job, so they tend to interview for that. I've never done an "algo" challenge in an interview. I've been asked to write code though to solve a contrived problem, but that's unavoidable.
I got laid off on my fortieth birthday. It hasn’t bothered me at all. Been working on building my own SaaS. I refuse to take algo interviews. Recruiter is hitting me up to work at same place as before for more money. Get your hustle on and get your last laugh.
I can relate to the interview part.
I have applied to horizontal positions in my company and been turned down so many times. They ask lots of questions that you would never hear on the job.
They had me working on obscure systems like FileNet and Neoxam. I even filled roles above my level, like tech lead (I'm a mid level dev). I got my AWS certs and it still took me a long time to move into a new position. It wasn't even a promotion, just a lateral.
The biggest thing I have learnt on the job is that you should not care about what the company or most others think. They are only there to F you over because they have this goal (and you should too): get in, make as much money as possible, get out as soon as possible. Skill and value mean nothing. Use the politics and people to get yourself ahead.
I am sorry for your pain. I have never had the 'algorithm quiz' interview, and am proud to say I have never given that quiz.
IMHO If you are good with algorithms, your resume should show it, and you should be able to speak to it. If your resume does not show the skill then they should not grill you on it. Of course as a interviewer you must be skilled enough to recognize a valid understanding of the algorithm the CANDIDATE explains not just the ones you as an interviewer knows.
That said, I have seen plenty of resumes where people will list off doing in 3 months, that which would take a genius a year. Validating that you actually did XYZZY verses just attended a meeting on topic is a key objective of the interview.
I am in the same boat now and, frankly, I am starting to care less. My medium to long term plan is to commercialize the tech that I've been developing privately for several years now. Were it not for that I'd happily throw myself into studying a big book of algorithms. However I resent spending time that would have otherwise been spent developing my tech -- which is about 1½ years from being ready, (still some R&D and several layers to build out) -- studying algorithms that most (standard) library provide.
I feel your pain. Stay strong. Good luck.
If you were in charge of the interview process, how would you design it?
This is why I am going back to school for an MBA and looking for roles outside of software engineering. Being a SWE is a great way to make decent money immediately out of school, but the reality is that, unless you're a true standout, it's hard to justify your cost as a senior engineer versus someone a few years out of school. You might think you can "make better decisions in most practical situations," but the reality is that you probably can't - at least not in a meaningful enough way to justify your significantly inflated cost versus a younger engineer to an employer. The experience curve in pure software engineering is asymptotic or perhaps logarithmic at best, and the situations in which additional experience matters are rare. In contrast, the impact of a good manager, recruiter, financier and so on is limitless. My peers that went into investment banking, consulting, and the corporate world are now getting director and vp titles, making partner at prestigious firms and so on. In 5 years they will be blowing me away financially unless I change something.
Like you, I've come to realize our interview process is stupid, despite taking part in it probably 100s of times by now. In fact, I think the entire concept of rank and hierarchy in software engineering is stupid. I'm tired of the pendantic arguments we get into, the endless architecture debates, design docs, managers using phrases like "impact at scale", listening to L7 wind bags spout off abstract technobabble and so on. In the end, I had to conclude that most of it is bullshit. I've seen the pattern enough times at some of the most iconic companies of our generation to determine that this is actually the way it works in most cases. It's as though we took the corporate hierarchy from 1950's GE and tried to apply it to the software engineering profession, when, in reality, software is much more like a trade. Ultimately, I think it stems from some sort of superiority complex or need to feel as though we are progressing towards something, so we set up a bunch of rules and hoops to make it difficult for others to reach our status as a vaunted FAANG engineer.
Ultimately, I had to look at myself in the mirror and think about my business value. For now, it's possible to ride the tidal wave of demand for software engineers at a select group of companies that happened to stumble upon a money printing machine. However, I'm not particularly confident that abundance will continue. My advice would be to take this as an opportunity to pivot into something that will allow you to more dramatically differentiate yourself professionally. Everyone and their mom is studying computer science these days. Companies are discovering they can hire remote developers. And, as you're discovering, this is no career path for old souls.
The tests are used to enforce age discrimination bias indirectly to shield from lawsuits. But at the same time I can't stand those employers who are quick to hire and quick to fire usually they're too lazy to do decent job of vetting. Its a tough question how to analyze someone's capabilities. So there is no easy answer. If you were working tons of unpaid overtime your github may be a ghost town who has time for side projects when the main job is asking for 80+ hours a week. There's no easy answer here except we should stick to practical questions and avoid testing for computer science concepts which are only valuable for university teaching or research positions in computer science.