> Exactly on point, which is why for interviews I like to discuss code snippets. Asking what's wrong here, is this the right collection type to use here, what would you do instead, how would you refactor this
LeetCode can be great for both of those--but not the way most interviewers use it.
Instead of using it as a source of problems to throw at someone and expecting them to produce in short order a working, correct implementation, use it collaboratively with the candidate.
Pick a problem, read it with them, and discuss possible approaches. Try to let them take the lead on this, nudging them as needed to keep them going in the general direction of a viable approach.
When that is done go to the discussion area for the problem. There people post all kinds of purported solutions. Go over a few of those with the candidate, critiquing them together. Plenty of the posts will contain errors, ranging from minor to severe, providing plenty of points for discussion.
I do like to ask algorithmic questions, but I don't expect the algorithm in detail. Instead I want to know if people understand when to use it, and what is the principle behind it. Because while you don't need to implement your own collections, you should know what their advantages and disadvantages are.