> Interviewing is mostly a different skillset from day to day work.

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.

There are plenty of places that have lower bars for hiring if you can call a JSON API in Python and run some Linux commands - but for the places everyone wants to work, you should expect a high bar. And that’s a good thing! A players want to work with A players. I would not want to work at a place that has a low technical bar for hiring.

> Knowing that you are good at the job you're applying for, perhaps better than the smug interviewer, yet blocked because you can't produce an optimal solution to their puzzle (that they probably stole from someone else and/or could not solve themselves in an interview)

It goes without saying that interviewer successfully passed that interview process to get hired there. So they have demonstrated at some point that they can do the problems they’re asking you to do.

Blowing a technical interview sucks, I get it - I have blown dozens of them. It’s humiliating, I’m aware, and so people find all sorts of copes (I would’ve been better than my interviewer at the actual job if I had just been given a chance! They couldn’t solve that problem anyway!) but they don’t want people that can just do the job - they want really talented engineers that can grow with the company and build all sorts of things.

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.)

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.

> It goes without saying that interviewer successfully passed that interview process to get hired there

It does not.

Also, even at the places with the most consistent interviews difficulty is pretty all over the place (or questions are well-known).

Anyway, for me the answer to my interviewing woes was a propranolol prescription

>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.