| If I used Leetcode to interview someone I wouldn't even ask them to code a solution. I'd show them a few problems that I thoroughly understand, ask them to pick two or three of them, and ask them for their thoughts on how to approach them. It would just be a discussion with no need to touch a computer. A whiteboard and scratch paper would be available if they wanted to use them. I'd provide enough input to make sure the discussion moves along to figuring out a solution, but would try to let them take the lead only providing enough myself to make sure we make progress. If I ended up providing most of the solution that would be fine. The most important part of the interview comes later. Then what we'd do is look at the official answer and talk about it, seeing where it matches what we expected and where it does things differently, and maybe talk about whether those differences make it better than what we came up with. Finally, and this is the most important part, we'd go to the Leetcode discussion for the problem. In the discussion people post all kinds of solutions and those have all kinds of errors. Some are just flat out wrong. Some are mostly right but miss common edge cases (edge cases I would have made sure the interviewee and I talked about earlier). Some miss somewhat ridiculous edge cases such as failing if an input array is so large that all positive integers in the language they are using are valid array indexes. Some always give the right answer but don't meet the specified time or space constraints. We'd do code reviews on some of those, again with me trying to just provide enough input to keep things moving along. |