>It’s not, really: this could be true if your day to day work is writing very basic websites without real performance or scale constraints, but if you are building large, performant systems, a good technical interview will give you a chance to show those skills.

I don't write websites at all. I have had to deal with performance issues but frankly it is rarely a major concern for anyone. Furthermore, interviews don't resemble work, they resemble LeetCode or other competitions.

>Being a good engineer does not imply you’ll pass the interview (there are plenty of reasons good engineers fail interviews) but passing an interview does imply you’re a good engineer. (Edit: I’m assuming the interviewer is competent.)

Having a degree and a long employment history implies that you are a good engineer more strongly than your performance on a random puzzle question. Most interviewers are not that good.

>And that’s the point: hiring a bad engineer is one of the worst mistakes a company can make. They’re expensive, take a long time to manage out, drain team productivity and morale, and can destabilize systems. You want a process that would rather say no to a good engineer than say yes to a bad one.

Yes, these companies want a process that provides superior vetting compared to 4 or more years of intensive schooling, or else something so far out that it can distinguish among expert candidates (while taking no more than an hour). It's a stupid objective. Coding interviews should mainly determine if you lied on your resume or not. It should not be seen as a magic way to spot "good engineers."

If you want to filter out bad engineers, just ask them questions that you expect bad engineers to do badly. These are mostly design questions and not coding questions.