The challenge with code review/debug/refactor interviews is that they rely on the candidate being familiar with the "this". The original intention of LC interviews was to remove domain specificity from the "this". Prior to LC interviews, candidates would get asked about their familiarity with things like ISO standards, random libraries, or other weird behaviors best learned through memorization. This can be mitigated with candidate prep and/or problem selection, but it's worth keeping an eye on.
For take-homes, I don't think the candidate spending 12 hours on something that should take 2 is necessarily a negative signal - but it's also something that should be considered. If the candidate spent 12 hours ensuring the solution was perfect, then it's probable that they are just thorough - which is a good thing more often than not. You do end up in a quirky situation of judging candidates by how much time they are willing to dedicate to your take-home interview though.
Anecdotally, for the few take-homes that I've done - I've always gone a bit overboard out of pride. Granted, this is also how I approach a lot of coding tasks.. so I guess you get what you test for?
Domain specificity can be mitigated by matching the interview problem(s) with the tech stack that's being hired for. Doing a refactoring of some basic Java code that's not going crazy with annotation processing would be quite reasonable for a job ad seeking to hire someone to do Java development; the same problem can be replicated in Python, JavaScript, etc. to accommodate different skill sets. I wouldn't expect this style of an interview to determine whether one understands the specific gotchas of Django Models if the company is seeking an average developer to do average work for average pay.
The 12 hour vs 2 hour thing is to allow for a degree of normalization, similarly to how it's unclear about what's being considered when 1 applicant spends 3 hours on a LC medium and another spends 30 minutes. Spending an extreme amount of time on take-homes confounds simple pride with someone who's otherwise a bad fit skills-wise but can eventually make up for it with an input of time, something that might not be appreciated after an offer is accepted. Too often companies will refuse to speak further with candidates if even 1 out of 20 test scenarios are not covered just because someone else chose to spend their entire weekend on the problem -- they'll be the same ones complaining about a dev shortage, no doubt.
> Doing a refactoring of some basic Java code that's not going crazy with annotation processing would be quite reasonable for a job ad seeking to hire someone to do Java development
This goes back to the days where job ads would request N years of X experience. The big takeaway from the last ~10 years is that this type of requirement is unnecessary. As an engineer who knows the fundamentals, it's relatively straightforward to pick up a new tech stack.
I wouldn't want to pass on someone who spent the last 5 years working in C because we have a java stack.
For take-homes, I don't think the candidate spending 12 hours on something that should take 2 is necessarily a negative signal - but it's also something that should be considered. If the candidate spent 12 hours ensuring the solution was perfect, then it's probable that they are just thorough - which is a good thing more often than not. You do end up in a quirky situation of judging candidates by how much time they are willing to dedicate to your take-home interview though.
Anecdotally, for the few take-homes that I've done - I've always gone a bit overboard out of pride. Granted, this is also how I approach a lot of coding tasks.. so I guess you get what you test for?