[jonahrd]

Since everyone knows what they're getting into with a tech interview, I don't see why it's such a bad metric. Many companies purposefully give you a rubric/criteria to study. It's a good way of measuring whether a candidate can take the time to learn/prepare a specific set of knowledge, and then work through problems in a way that includes the interviewer (ie. other devs if hired) in the steps to solve the problem.

[hocuspocus]

> It's a good way of measuring whether a candidate can take the time to learn/prepare a specific set of knowledge

And how isn't that a terrible metric? Most of my current coworkers would fail as they simply don't have the time.

[Terr_]

> Since everyone knows what they're getting into with a tech interview, I don't see why it's such a bad metric. Many companies purposefully give you a rubric/criteria to study.

It's often so broad that to really cover everything that might come up you've got to have time to make the studying a part-time job.

And even then you might get hit with one of those "you almost have to have seen the trick before" questions, like detecting a cycle in a broken linked-list with O(1) memory.

[gaius]

Why interview in a way that's unrepresentative of the actual work?

The only reason is that you want to build an environment where the work is secondary, such as wanting to hire a bunch of bros to go drinking with and help you spend all that sweet VC cash...