> Or at least, that's my expectation: I've never actually considered working somewhere that does leetcode interviews.

Hrm. So what you're saying is you've never actually taken or given this style of interview. Nor presumably ever worked at a company that did this interview. So if on the off-chance these interviews actually were a somewhat successful tool for filtering candidates you wouldn't actually know it?

That feels like a miss.

▲

gnfargbl 3 days ago | parent [-]

Your criticism is valid.

I've also never worked at a place that uses beatings to improve employee morale. So, I can't guarantee that beatings aren't an effective technique for doing so.

▲

forrestthewoods 2 days ago | parent [-]

lol.

My deeply unpopular opinion is that "leet code style" interviews are actually pretty decent at avoiding false positives. Obviously some specific questions are gotcha trivia and many interviewers are bad no matter the question. But they're a reasonably accurate proxy. Their issue is false negatives.

End of the day the ONLY question an interview sets out to answer is "will this candidate be successful in this role". Interviews are strictly a proxy for "the real job". So arguments that "it's not reflective of the real job" are utterly irrelevant. It is not possible for ANY interview to fully reflect the real job. And you can't ask someone to quit a steady job to trial for 3 to 6 months to see if they're a good fit or not. So we're stuck with proxies.

I definitely think it's important for people who are hired to write code to in some form demonstrate that they are capable of writing code. That seems reasonable. But we can't expect candidates to write a big project for every place they apply. That's too much. And almost all candidates can't share code from their prior job. And solo GitHub side project are quite frankly not relevant for 99.99% of candidates. (And maybe more).

The one tried and trued method of hiring is to hire people you've worked with before who were good. This is not scalable.

Hiring is hard. Really really hard. I find that the vast majority of leet code complaints come from people who don't hire. If anyone ever cracks the puzzle of how to hire better they'll have a monumental competitive advantage. Many many have tried. So far none of have succeeded.

	▲	gnfargbl 2 days ago \| parent [-]
		It's a fair point; hiring is hard. It's been a while since I had to hire outside your "people you've worked with before" bucket, but when I did, here are the two questions which worked best: 1. Tell me about a time you analysed a complex problem and came up with a solution. 2. Tell me something creative you did at work. Something you're proud of. In my experience, a good candidate typically had excellent answers to those questions, because (1) a good candidate has had to do some real engineering at some point and they can tell you about it, and (2) a good candidate has done technical work which they're really proud of just in and of itself, and they want to tell you about it. A technical question was useful in reducing false positives, but something a couple of steps above FizzBuzz should be fine for that. You just find out anything useful about a candidate by asking them to recreate some esoteric CS algorithm on the spot, unless you really need to select for people who can recreate esoteric CS algorithms on the spot.