> if an engineer can't do a simple 20-30 line coding problem or reason over the constraints/design space - then there is a good chance that they will need help with core coding in the day to day.

This isn't my experience, I've found that the number one reason for not doing well on leetcode problems is simply because the candidate hasn't practiced doing leetcode problems. I've known plenty good engineers who, when interviewing with LC style interviews for the first time, fail utterly. Then they realize they just need to practice and did better.

I've been in the industry for around 15 years now, my anecdotal observation is that the average quality of engineers is negatively correlated with the rise of leetcode. 10 years ago the strongest signal was a solid github profile with lots of relevant projects.

That's not to say leetcode is the cause of this decline. The cause is the flood of SWE being rushed into the career as fast as possible (this is why github is no longer a good signal, bootcamps started training their students to create meaningless GH projects just to attempt to create signal).

However I've also seen no indication that leetcode type challenges have any relationship to being a good engineer. I've worked at plenty of places that required pretty tricky leetcode style problems filled with very, very mediocre engineers. Leetcode has become a game that has little to nothing to do with real world programming, in the same way that speed-cubing (solving Rubik's cubes in record time) has absolutely nothing to do with the player's underlying understanding of group theory and combinatorics.

The old fashioned walk through and reason about non-trivial code someone has written is still an excellent method to see how a programmer thinks and if they can code.

"Code review this" or "debug this" or "refactor this" are things that an actual developer doesn't need to do special preparation for as they probably do it almost every day, unlike LC, and should provide a signal more relevant to the job of coding that the candidate is smart and capable of doing good work. Having a bit of code to work with can also take away some stress by reducing the emphasis of typing a complete solution from scratch -- there are many LC interviews where if someone isn't typing right away, they have no hope of solving the problem in their 20-25 minutes of time even if they fully understand the problem and the correct solution.

Take homes can get a bit out of hand because candidates can choose to spend too much time (12 hours on something that "should" take 2 hours) out of desperation (or perhaps simply not having a life) if the primary criterion is the completeness of the solution. I think it works best if the solution or partial solution is used as something to have a conversation about in the next interview. For instance, the applicant can explain their lack of unit tests by providing their reasoning for relying more heavily or entirely on integration tests as the system relies too heavily on an external service.

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.

>"Build a service/program to a spec via take home."

The problem with this is that the company has no skin in the game. Sadly flakey companies and recruiters are prevalent enough that it's not at all uncommon for a company to ask you to complete their "take home" assignment and then never get back to you. I've had it happen enough that I would simply refuse this now. I think if a company wants you to spend 3-4 hours on their take home project they should pay you for that time.

Anecdotally, as someone who just did a bunch of interviewing, I saw a number of these types of questions instead of super hardcore LC stuff. Particularly the last two. It was a pleasant surprise, as I really struggle with dynamic programming/binary trees/etc.