I’ve done a LOT of interviewing for all levels of software engineering, at big and small companies, and it’s simply wrong to say it’s all leetcode-style ranking. Short-duration coding challenges are a big part of most interview processes, but it’s not graded the same way as competitions are. (at the better employers, at least) It’s not about the right answer, it’s about the explanation, follow-up questions, and understanding of the algorithm and code. And perhaps a bit about the right answer and the fluency of coding, but that’s more pass/fail than requiring tons of practice. I routinely give hints to get the candidate on the right path to remember/figure out a working solution.
It’s disturbing just how many applicants can get to an interview without having done minimal practice on those sites (or coding regularly in their previous job). It’s a necessary part of the interview, just to weed out the non-starters. For more senior roles, the design discussions and tech dives into resume topics (“I see you’ve worked with distributed caching—tell me how you managed varying invalidation needs.”) are more useful for final decisions.
More importantly, interview and hiring is a pretty small part of the career impact of a developer. In-role impact is also never 100% meritocratic, but at a lot of places is pretty good.
I have no clue if young attorneys are tested by actually knowing what cites to start with or how to prepare for a relevant case, but I kind of hope they are.
TL;DR leetcode-style interview coding is (or should be, if done well) satisficing, not ranking. Being competent at it is just as good (possibly better, if it lets you show other strengths) as being great at it.
TL;DR leetcode-style interview coding is (or should be, if done well) satisficing, not ranking. Being competent at it is just as good (possibly better, if it lets you show other strengths) as being great at it.
I would agree with this and upthread said basically the same thing. It’s a goodharted metric. Sure, if something can do it at all that’s one signal, but deciding between 10 candidates based on going to “2 mediums, 40 minutes” where only 1-2 will pass is essentially arbitrary.
The 1-2 who passed may have been better at LC than the failures, or may have been lucky this round.
Say 6 candidates finished at least 1 medium and were somewhere dealing with bugs on the second. Your test doesn’t realistically distinguish between that set of 6.
I’ve done a LOT of interviewing for all levels of software engineering, at big and small companies, and it’s simply wrong to say it’s all leetcode-style ranking. Short-duration coding challenges are a big part of most interview processes, but it’s not graded the same way as competitions are. (at the better employers, at least) It’s not about the right answer, it’s about the explanation, follow-up questions, and understanding of the algorithm and code. And perhaps a bit about the right answer and the fluency of coding, but that’s more pass/fail than requiring tons of practice. I routinely give hints to get the candidate on the right path to remember/figure out a working solution.
It’s disturbing just how many applicants can get to an interview without having done minimal practice on those sites (or coding regularly in their previous job). It’s a necessary part of the interview, just to weed out the non-starters. For more senior roles, the design discussions and tech dives into resume topics (“I see you’ve worked with distributed caching—tell me how you managed varying invalidation needs.”) are more useful for final decisions.
More importantly, interview and hiring is a pretty small part of the career impact of a developer. In-role impact is also never 100% meritocratic, but at a lot of places is pretty good.
I have no clue if young attorneys are tested by actually knowing what cites to start with or how to prepare for a relevant case, but I kind of hope they are.
TL;DR leetcode-style interview coding is (or should be, if done well) satisficing, not ranking. Being competent at it is just as good (possibly better, if it lets you show other strengths) as being great at it.
TL;DR leetcode-style interview coding is (or should be, if done well) satisficing, not ranking. Being competent at it is just as good (possibly better, if it lets you show other strengths) as being great at it.
I would agree with this and upthread said basically the same thing. It’s a goodharted metric. Sure, if something can do it at all that’s one signal, but deciding between 10 candidates based on going to “2 mediums, 40 minutes” where only 1-2 will pass is essentially arbitrary.
The 1-2 who passed may have been better at LC than the failures, or may have been lucky this round.
Say 6 candidates finished at least 1 medium and were somewhere dealing with bugs on the second. Your test doesn’t realistically distinguish between that set of 6.