Myself, I've only conducted dozens not hundreds of FAANG-style coding interviews. I also loathe the format, and it does indeed wear on me. I hate every second.

Damn. What is your success rate? A lot of times it seems to mee that luck and your ability to withstand stress are one of the main factors. Is it something you can teach yourself?

If by success rate you mean inclined rate, it varies a lot by level. I'd say it's around 30% for interns (which is by far more lenient) and closer to 5% for Senior level. However it's also common to downlevel senior candidates rather than downright reject.

From my side of the table I can confirm that of course luck plays a role. Nevermind the variability of the coding problems themselves, but the variability on the interviewers. Even in my company, that has a formal process and pretense of objectivity, interviewers quality and expectations vary greatly.

In short, I'd say what people on the hiring side hate to hear, but interviewing is ultimately a numbers game. I wouldn't take rejections too seriously. The best you can do is to improve your chances with proper prep (leetcode, system design) and interview broadly.

The illusion of objectivity is strong. We have an official interviewing process. It has a big survey that turns into "metrics". We have a debrief where we talk about the "metrics" as though it was an "evidence based" process. Then you'll hear someone say "Well, he found a solution for the balanced tree problem, but he just didn't seem all that confident doing it, you know?"

> Then you'll hear someone say "Well, he found a solution for the balanced tree problem, but he just didn't seem all that confident doing it, you know?"

This sounds like yet more evidence that it's really just pledging a frat.

I hate leetcode style interviews, but I've done hundreds of them. The irony is not lost on me. Some might say I'm part of the problem.

Thing is, in a small way, I'm trying to change things from within. I try to make the process as palatable and fair to candidates as possible, while working within the constraints of the system. When I train new interviewers some of my top tips are:

a) The purpose of the interview is to determine whether the candidate is a good fit for the company, and the company is a good fit for the candidate. b) The interview is an imperfect proxy for this.

It then follows that interviews shouldn't overindex in the coding round. If I have helped someone to get an offer that wouldn't otherwise, I'm satisfied.

BTW that's also one of the reasons I'm publishing this. I hope to push the point that leetcode-style coding interviews are outdated and should be burnt to the ground.