those are the best interviews imho. specially when both the candidate and the interviewer engage into a productive discussion about the solution the candidate gave.
at the same time, those take time and a lot of companies want a "fast" hiring pipeline, which leads to "invert a binary tree on this whiteboard!".
I see a bunch of comments that look to me as strawman, or really bad interview experience.
A good coding interview should: - not be known by the interviewee if they spent even a few weeks on leetcode - avoid requiring anything that isn’t covered in an average CS101 class - draw its challenges from the need to process a new problem, and gradually uncover the edge cases in it and how to handle them gracefully.
I don’t do leetcode. But went now and tried the first hard question I found. It was “find the median of two sorted arrays”. I find this question to be a good example of very little background knowledge needed. (You’d need to know how to deal with arrays, and what’s a median - not everyone will know these, but it’s a pretty low bar)
This question already has plenty of room for mistakes, edge cases and problem solving. I’m going to take a wild guess from knowing talented veteran engineers I’ve seen that they can surely handle it in the interview structures I’ve experienced.
I mean, it's OK to ask for basic algorithms in interviews, to see if the interviewee has at least some understanding of basic stuff and/or can think on their feet and/or can reason about problems appropriately...
But I would still welcome it if instead of giving an interviewee a boring, memorizable problem like "invert a binary tree", the interviewer would find a more general problem and would see how the employee would tackle it, and if the interviewee refers to binary trees as part of the solution without writing out a full implementation from memory that's OK (as long as binary trees would be a valid approach to solve the problem, of course).