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?