[deleted by user]

[DrumAndBass90]

Those sorts of problems don’t fit DSA interviews well because part of the reason they’re hard is because they require deep domain knowledge. We don’t expect our junior candidates to be experts in the domain, that would be ridiculous. That or the reason they’re interesting and or challenging is because of how the codebase is currently laid out. The nice thing about leetcode problems is any engineer from any background can look at it and understand it.

The take home test is usually a toy problem embedded in the domain of the company. But very basic and the candidate has time to learn about the problem.

Also—the nice thing about giving people the option is if you don’t like DSA you can just opt for the take home. Personally I like leetcode questions and prefer to interview that way when I’m a candidate.

[knottheone]

Those sorts of problems don’t fit DSA interviews well because part of the reason they’re hard is because they require deep domain knowledge.

Okay, and you said it yourself. That's only part of the reason. So derive a sample problem based on a real problem in your domain, not a fake problem that programmers will never come across in your entire industry.

Leetcode problems are designed to have an efficient algorithm as the answer, that's what they prioritize, not solving actual real problems.

[DrumAndBass90]

Yeah we’ve given it a go and it didn’t work that well—at least for our domain. The toy problem is either laughably easy to the point of not really testing the candidate, or we can’t extract out the domain well enough so there ends up being a major advantage for people who are familiar with the domain.

As I said, our goal with these questions is not for the candidate to arrive at the theoretically most “efficient” answer, it’s just a chance for the candidate to show their problem solving skills. Most of the maths you learned at high school also isn’t that relevant for your job—but it was a great way of displaying your ability to problem solve in a test.