This is a real problem. If you are hiring coders you have to have a couple people in the team go deep on coding chops to ferret out the charlatans. Personally I like to show people a piece of code from a big system they've never seen and let them walk me through what it does and what they would change to make it work better. Some teams I work with also give 'homework' exercises, which I believe is fairer than trying to do it in front of somebody else. (Unless that's how you actually write code on a day to day basis.)
Good interview processes reflect complementary broad and deep concerns. It's kind of analogous to the way a strong team is better than the sum its parts.
> Personally I like to show people a piece of code from a big system they've never seen and let them walk me through what it does and what they would change to make it work better.
This could be the first coding interview style that actually makes sense to me
You can easily do programming problems without algorithm questions.
I don’t think I’m against the algorithm part as strenuously as I am against the gauntlet part. You shouldn’t be locking someone in a room for 6-7 hours and then judging them on how they keep their cool, for many reasons, including those I mentioned above.
As I mentioned elsewhere I think you can ask questions that look like work but aren’t (go too far the other way and you’re into IP problems)
One of the most painful interviews I have ever seen was a guy who had a resume listing a number of interesting projects. He could talk energetically and in detail about them. Then we asked him to write some code to solve a simple problem. He said he didn't know our primary language, but was very familiar with Python. I know Python, I was good with that.
He didn't know Python. I tried to help him, but he didn't get much farther. I eventually called the interview, with a complete 180 of my hiring opinion. Nice guy, but he couldn't be what we needed.