[alfalfasprout]

I think a lot of people are getting hung up on the fact that these challenges take a long time. Yep, and that's a problem...

But the goal of having a candidate work on a real problem is a good once. IMO a far better approach is to do a live exercise with them. Not a leetcode problem... take an existing codebase and add a feature to it, fix an issue with it, etc. Heck, you don't need them to complete everything, but you just need to get signals on how they approach the task, how they pick up working in an unfamiliar codebase, attention to detail, communication, etc.

Anything to get rid of leetcode interviews that are a collosal waste of everyone's time and lead to awful hires. Over the years there has been a democratization of study material for "coding interviews" which has led to a huge influx of wildly inexperienced/unqualified candidates. It also means if you want to hop to another company, you have to waste months grinding leetcode problems completely irrelevant to anything you'll ever do.

[frumper]

Why not, you know, interview them? See if you like them, see if they are reasonably knowledgable about what you need them to do. Putting people on the spot doesn't mean they can or can't develop software or solutions. Sending homework is even worse though.

[alexyang21]

I'm a big fan of live exercises too, mainly because it's a great way to see how candidates think and how they collaborate with others. There are only a couple tradeoffs with this format (every approach has them): live exercises can be more stressful and teams with many applicants won't have the bandwidth to offer this to everyone who could be qualified.

My favorite is a combination: short (1 hr) take-home followed by live discussion/pairing with anyone who does a half-decent job. It reduces stress because candidates will already be familiar with the code (they wrote it!) while being efficient with time.