> I don’t really have a solution to this problem, I just know it’s a problem.
The solution is simple: refuse to do those interviews. I have, and I wish more engineers would. It's one of my screening questions: do you do whiteboard style quiz/brainteaser interviews? If the answer is affirmative, I politely (and sometimes impolitely) decline.
I've written a book, edited another, contributed to plenty of open source, including Golang, started a few companies, and been around the block. I'm more than happy with a take-home or with going over code I've previously written, but doing leetcode in a "live coding session"? I'm good, thanks.
For FAANG and other huge companies, it's probably a decent heuristic (though I doubt even that), but smaller startups or non-tech companies doing this nonsense is a clear red flag. I mean, there's entire books dedicated to gaming the software engineering interview. The signal-to-noise ratio is probably so terrible, it's essentially just professional hazing at this point.
I am starting a company, and I need smart people; I do not care how good they are at programming language X, or technology T - all the skills my employees will need can be learned on the job.
I want to optimize the time it takes for an arbitrary hire to become independent, to have learned the basics, and to make meaningful contributions. They would write code at most 20% of the time, and the job has many other nuances.
In your opinion, what would a process that you wouldn't refuse look like? Would a learning interview (I present something that you have not seen before, act as an oracle, provide docs, evaluate how quickly you pick up concepts) be so insulting?
> all the skills my employees will need can be learned on the job.
> optimize the time it takes for an arbitrary hire to become independent
So you are looking for somebody in top 5% cognitive ability and top 5% independence which is what pretty much every other employer wants.
My advice is if you can pay competitive FAANG salaries (or compensate lower salaries by prestige/saving humanity/bringing people to Mars), just do what everyone else is doing - Leetcode, behavior interview and architecture interview. Innovate on something else, standard interview process will give you smart motivated folks.
If you can’t pay those salaries, you need to be creative and decide what compromises you are ready to make and tailor interview process to them. No one size fits all process here. You are essentially looking for people who failed in standard process while still posses qualities you need. Expect to spend more time on hiring and have more bad hires.
realistically we're looking for much higher (sub 1%) cognitive ability. I understand this is highly sought after, so we incentivize by paying a few times what FAANG does locally.
I was genuinely wondering how OP preferred to be approached vis-a-vis this sort of assessment, since they suggested that they would walk out on conventional approaches. I mentioned cognitive ability and ability to learn as I feel those are harder to extrapolate from one's existing publications/contributions/take-home assessments, compared to in-person discussion(s).
In this particular discussion, I am not looking for the best process for the task. I am looking for a process that will not get deemed a "red flag" by candidates.
I have frankly dealt with some people, who wrote books, had lots of titles, yet were incompenent in the very subject their books are about. So yeah, does not mean much to me. I personally love whiteboard tests; shows your ability to code quickly and reliably.
> yet were incompenent in the very subject their books are about
Gonna <press X to doubt> on this one. I mean I guess anecdotes are cool, but yours goes against basically any editor/publisher due diligence, not to mention the financial incentive of writing a book in the first place (the book actually being good), but alright.
It does not have to be bestselling books; just some niche books. And also I can guarantee you I can write you a book, say, "intro in datascience" without actually knowing much about the subject, just by mixing together existing material; after that succesfully forget everything I had learned why was writing the book.
The solution is simple: refuse to do those interviews. I have, and I wish more engineers would. It's one of my screening questions: do you do whiteboard style quiz/brainteaser interviews? If the answer is affirmative, I politely (and sometimes impolitely) decline.
I've written a book, edited another, contributed to plenty of open source, including Golang, started a few companies, and been around the block. I'm more than happy with a take-home or with going over code I've previously written, but doing leetcode in a "live coding session"? I'm good, thanks.
For FAANG and other huge companies, it's probably a decent heuristic (though I doubt even that), but smaller startups or non-tech companies doing this nonsense is a clear red flag. I mean, there's entire books dedicated to gaming the software engineering interview. The signal-to-noise ratio is probably so terrible, it's essentially just professional hazing at this point.