[xenocratus]

> If someone solves a leetcode hard with a constraint solver and you don't hire them, you are an idiot.

I do hope you're exagerating here, but in case you aren't: this is an extremely simplistic view of what (software) engineers have to do, and thus what hiring managers should optimize for. I'd put "ability to work in a team" above "raw academic/reasoning ability" for the vast majority of engineering roles, any day.

Not that the latter doesn't matter, of course, but it's by no means the one and only measure.

[lucianbr]

> I'd put "ability to work in a team" above "raw academic/reasoning ability" for the vast majority of engineering roles, any day.

In this hypothetical, why do you do leetcode hard interviews?

[bluGill]

> why do you do leetcode hard interviews?

I don't. I do easy code interviews because there are people who work great on a team and know enough buzzwords to sound like they know how to write code, but cannot. Something that isn't hard to solve in about 20 minutes (I can solve in 5 - but I've seen a solution several times and so don't have to think about the solution), but is different enough that you haven't memorized the solution. If you can't solve an easy problem then you can't code.

[Too]

One can be gifted while still producing code that the rest of the team can read.

[xenocratus]

> In this hypothetical, why do you do leetcode hard interviews?

I thought I already answered that:

>> Not that the latter doesn't matter, of course, but it's by no means the one and only measure.

[SkiFire13]

Maybe because they are simplier to practice than working in a team?

[Der_Einzige]

Hey I'm with you 100% about the idea of code-interviews/leetcode being a problem and the importance of culture-fit and ability to work on a team.

I should have said "if you deemed this a fail on the code interview, you are an idiot".

[bryanrasmussen]

OK, but obviously this presupposes a job where the hiring process is focused on leetcode.