Making connections and building a hiring network is awesome advice, that many many developers miss. Thank you.
I run a company (http://interviewkickstart.com) in Sillycon Valley, that helps developers brush-up their data structures, algorithms and system-design skills for interviews. Previous to that, I worked at a very fast growing startup in the valley, where I had joined early and had the privilege to contribute to multiple iterations of their technical interviewing processes.
Here is the thing: not a single employer is happy with their interviewing processes. They do it not because it's the best process ever, but it's the least evil for demands on the business, for their size, stage and culture. Every single process has its flaws.
The core reason most companies ask data-structures/algorithms and such, is because that's the lowest common denominator of knowledge between the interviewer and the interviewee.
How is that?
That's because the field of programming is so vast, that candidates apply to ANY available job, whether that fits their experience or not. e.g. If you worked on Payment systems and you apply to a Deployment systems role, what am I, as an interviewer, going to ask you about? I can't ask you about Payment systems and JUDGE you on your knowledge of 5 years in 45 minutes especially when I have not worked in it myself. And I can't ask you about Deployment systems because you haven't worked with them enough in the past. I hence fall back to the lowest common denominator of knowledge between us, which is, most likely, something in the CS programs we attended.
Then why ask algorithms, of all the CS that we may know in common? Because that needs the least amount of specific knowledge, compared to things like compilers and systems. Algorithms is a proxy to your problem-solving skills. An unfortunate proxy, but the best available among the things we know in common.
If you however end up applying to the exact SAME thing you have been doing, they should not ask you all the algo shit. They should ask you exactly what you've done and how you've done it and judge your experience off of that. After all, interviewing, by definition, is a verification of your experience.
But reality is, that you probably don't want to continue working in what you have been working in. Because you want a change and because frankly, CS is just so vast and cool opportunities exist anywhere. Data Structures and Algorithms hence, become the best equalizer/normalizer among anyone who wants to do programming.
Also, business pressures are such, that as a company, I just cannot spend more than a day or two evaluating someone's fit. Otherwise I'll take my team's attention off of more important things e.g. the holiday e-commerce season, or I'll be second to the market with a feature or I'll miss that big conference where I wanted to launch that product. I'll much rather hire an okay developer with a short interview process and hit that deadline that's going to keep my business afloat, than wait for a unicorn by a thorough evaluation. And when I can only give a short amount of attention to you, I will fall back to the easiest and most prevalent method of interviewing, which is what you see today.
In conclusion, I don't think it helps agonizing over interviewing processes of companies. It's best to remain prepared. Keep solving problems, keep interviewing. And when you need a booster, just come to us ;-) http://InterviewKickstart.com.