I agree with what you said even though it seems a bit outdated. I made a general statement looking at the evolution from 2005 until today. I switched employers many times, worked for small, medium and large companies. I got to interview a lot of candidates for the last 10 years collaborating with other colleagues to make hiring decisions. I'm aware there are exceptions out there, totally agree with you! Though, it changed since 2005. It seems that most of the tech companies are now following the google model by putting CS principles at the center of the technical screening. It doesn't matter if you applied for a Web, Mobile, Backend position, if you're a junior, senior, staff, etc. You'll have to go through it and it's usually a 30 minute question within a 45 min to 1h interview. So I call it the main technical evaluation for engineers. Versus a 2 minute question going over the technology you used and how you tackled some of your challenges. I personally dig into those questions but most of the interviewers don't want to hear about anything else rather than their own voices. They need to make a "valid" decision at the end of the day so they better get a solid justification. Like I said, it's easier for them to ask YES/NO type of questions rather than engaging in a design discussion for 30 minutes. Some do but most don't.
Right now the market is saturated by people applying everywhere at the same time. Some recruiters get handed multiple choice questions and get involved in the filtering right up front. If you use a referral these days you still have to go through the standard hiring process, again, there are exceptions. I got hired by an ex-collegue from another company a few years back, where he got promoted to manager. We worked together, coded together and were both engineers at our previous employer. He had an open req in his team and contacted me personally. I still had to go through the standard hiring process and crack a few algorithm questions with other engineers. He bumped up my rank though to the max when he hired me, which is where the referral boost came into place. Not during the hiring process, I was just a regular candidate for other engineers.
Anyway, back to your points, algorithm questions are the main topic of conversation during tech interviews in 2017, minus the exceptions. It all comes down to writing code on a whiteboard or in a notepad. When I say code I mean palindrome, dykstra, doubly linked list and all this crap. I say that because it's the hardest problem you can ask to a candidate with or without experience. People know you'd feel comfortable talking about app optimization, scaling an infrastructure, common problems in a multi threaded system, etc. They use it for architect positions where they know the person won't write a line of code. There's just a big misunderstanding because interviewers aren't trained to evaluate candidates. They'd rather go for the generalist route and hire the "smartest" algorithm guru over someone who has a deeper knowledge of the field.
>It all comes down to writing code on a whiteboard or in a notepad.
Thanks for elaborating but that's sad news. I thought we had all collectively decided this was a horrible way to interview people. If a company absolutely must have code written, assign all interviewees a programming task and have them submit it through GitHub or on your site. Something that shouldn't take more than 30 minutes for a moderate developer. Anyone who doesn't complete it gets filtered, and you get a good example of their thinking, style, sloppiness, comment habits, etc. If you think they nicked it from the internet, have them make a slight change.
I've always considered the ability to be able to design a piece of software or module from nothing to something complete in a moderately elegant way was way more important than if someone had memorized how some algorithm works without ever having the need to implement it.
It's akin to asking a painter how to build various types of brushes and how to harvest paint, or an author how to make pens. That ability isn't useless, but certainly don't make that the focus of your interview.
I want experienced software designers, they can learn anything they are lacking with whatever stack we use in house in just a few weeks. I'll just stick to using my methods and wait until the industry catches up. :)
What you're describing is the perfect way to evaluate a developer. That's exactly what I promote to my employers. That's what I ask at the last step of the hiring process if we still have a doubt. we should use this evaluation only and get rid of the extras. Then we should talk about life and work in general for an hour rather than a stupid algorithm question just to make sure the candidate isn't a d*ck.
Right now the market is saturated by people applying everywhere at the same time. Some recruiters get handed multiple choice questions and get involved in the filtering right up front. If you use a referral these days you still have to go through the standard hiring process, again, there are exceptions. I got hired by an ex-collegue from another company a few years back, where he got promoted to manager. We worked together, coded together and were both engineers at our previous employer. He had an open req in his team and contacted me personally. I still had to go through the standard hiring process and crack a few algorithm questions with other engineers. He bumped up my rank though to the max when he hired me, which is where the referral boost came into place. Not during the hiring process, I was just a regular candidate for other engineers.
Anyway, back to your points, algorithm questions are the main topic of conversation during tech interviews in 2017, minus the exceptions. It all comes down to writing code on a whiteboard or in a notepad. When I say code I mean palindrome, dykstra, doubly linked list and all this crap. I say that because it's the hardest problem you can ask to a candidate with or without experience. People know you'd feel comfortable talking about app optimization, scaling an infrastructure, common problems in a multi threaded system, etc. They use it for architect positions where they know the person won't write a line of code. There's just a big misunderstanding because interviewers aren't trained to evaluate candidates. They'd rather go for the generalist route and hire the "smartest" algorithm guru over someone who has a deeper knowledge of the field.