Average of 6 people involved in an interview loop. Let's say they make $250k a year each fully loaded on average (at the FAANGs, I'm probably underestimating). There's a 30-minute prep, a 30-minute debrief, the actual hour long interview, and probably 15 minutes of writing up the notes about the interview. Let's call it 2 hours. Taking the rough 2000 hours a year, that $250k is $125 an hour. So $250 per person times 6 people is $1,500. Times 4 companies is $6,000. Now, trade that 10 hours back for tickets. Who knows what the tickets would be, but it's 10 hours of work, with some likely positive ROI. I won't pretend to put a value on that, but it's non-zero.
He openly admits that he had no intention of taking the offers for these companies. He just wanted to test his cheating tool to see if it would work.
If that doesn't scream theft to you, I don't know what would. And sure, can FAANG pay the bill? Yes. But should they have to? What if he did it at a tiny 50-person bootstrapped startup? Can he be called a thief then?
Sorry mate, but as a hiring manager, spending time to talk to people for fit assessment is part of the cost of doing business. You don't get to call it theft because the guy wasn't game to play your games. You're the one erecting barriers, not them.
What would you prefer instead? X years in stech stack, keeping devs boxed in their role for their entire careers.
Is the claim that the majority of developers are proficient because of Leetcode as a filter?
I don't think Leetcode is a useful interview tool when the actual role deviates from the style of questions that are expected to be completed in an interview scenario. And this is a prevalent issue.
Clearly it can be gamified and I don't think this makes for good engineers. It makes for people that are good at solving Leetcodes. Jira tickets aren't Leetcodes.
Whatever technical filter is implemented (pairing/take home/in house white boarding etc.) I care much more about observability, logging, approach to difficult problems etc. and general attitude.
Run me through the architecture for previous solutions that have been worked on. Did you own it? Were there any outages? What happened when requirements change? How can you ensure what you've created is fit for purpose for the organisation?
There's so much more to engineering rather than just code. And in my experience many engineers are worse at this than they think.
Apart from that, I'm just passing on what I have heard from people. It's not first hand, but I believe it.