I used to do bowling then a leetcode hard question for interviews, but I had very little interest in whether they got the right answer. I would try and ask a question that was very unlikely they'd know with the focus on how well they communicated their thought process while working through the code. I did run into a couple of Chinese grad students applying for intern level positions that actually nailed the problem in minutes, but couldn't explain at all how it worked. Really frustrating as I'm sure they were probably capable, but they didn't make it past other steps of the interview either due to inability to communicate. Then for one intern interview where I could see the kid was not even qualified as an intern- I was told during the feedback review process- "oh he's related to so and so, I know that you were a no, but we're hiring him"...I left that job not too long after.
> I would try and ask a question that was very unlikely they'd know with the focus on how well they communicated their thought process while working through the code.
I'd probably do something like that. No actual writing code, more of a discussion with them about ideas for solving it. I'd try to let them take the lead on approaches, just adding ideas to keep things moving if they were getting hung up on something.
After we've got what seems like a reasonable approach and I'm sure the candidate understands it, I'd then have us take a quick look at the official solution and see if it is along the lines of what we came up with.
Finally, I'd go to the discussion area for that problem and take a look at a few of the solutions posted there and ask the interviewee to help me do a quick code review of them.
The discussion areas for Leetcode problems are an often overlooked resource. They are full of proposed solutions with all kinds of issues. Sometimes they just won't work. Sometimes they solve the problem but don't meet the time or space constraints the problem asked for. Sometimes they work except for edge cases.
