A rather click-baity headline. The article doesn't claim that job interviews don't work so much as it claims that subjective job interviews are more subject to

A rather click-baity headline. The article doesn't claim that job interviews don't work so much as it claims that subjective job interviews are more subject to bias than structured job-interviews. I'd say that's true, but the caveat is that structured job interviews are more subject to people studying and honing skills specific to the job interview process. Grinding leetcode definitely makes you a better at solving algorithms problems on a whiteboard in 60 minutes but doesn't do much to improve working effectiveness. I think there are 3 core trade-offs for the job interview process: logistical feasibility, consistency, and resemblance to the actual work experience. Doing 2 rounds of coding interviews, and one round of systems design from a set list of questions with explicit rubrics is easy to implement and is very consistent. But you can leetcode your way to knowing most coding question archetypes. Systems design question archetypes are even smaller in problem space. These questions have moderate to low resemblance to the actual work experience. Sure, it can identify people who can't code or aren't experienced in systems design. But does it show how well someone takes feedback, or reviews other people's code? Not really. One of my co-workers used to conduct 90 interviews that started with one question: "how would you build a text editor?" He didn't specify whether this text editor was WYSIWYG like Word, a web-based editor, a code editor, etc. It expanded and touched on a whole variety of questions. It could be traditional data structures, or UI design, or systems (e.g. implementing auto-saving text fields on the web). This was low consistency, since the interview was mostly unique to each candidate. It had moderate logistical feasibility since it was hard to train interviewers on these open ended questions. But I think it had better resemblance to the actual work experience, since it didn't just test coding ability. It tested thinking through the problem and what the desired end behavior for the user really was and navigating how those expectations influence implementation. An idea of an interview process that I have is to do it asynchronously through github or another version control system. Give the candidate a task to open a PR on a mock codebase. See how they implement the task and justify their design decisions. How thoroughly the test. Respond to the PR with comments and see how the candidate responds. And next, have the candidate review another person's PR and see what they look for in a review. This potentially has even better logistical feasibility since it's not dependent on the candidate and employee being active at the same time. I think it would have the most direct resemblance to actual work experience, since it's emulating the workflow most developers actually use in their day to day work. Consistency may be difficult to achieve, but if evaluation was broken up into multiple segments for separate evaluation it may be able to be made consistent.