I have asked some similar questions as listed in the article in the OP, but my motivation is different from necessarily finding out something new - it is more t

I have asked some similar questions as listed in the article in the OP, but my motivation is different from necessarily finding out something new - it is more to understand where the candidate is coming from, and to hear them out. My goal as a hirer is to get a wholesome picture of the candidate, how his/her experiences have shaped him/her, and how sharp the person is. I don't even walk into the room for a candidate's in-person interview with a set of questions - I use cues in our conversation to get details that shapes what technical questions I ask. While I need to efficiently get a certain set of information about candidates, I also am respectful of their time and that they have options - I take a more humanistic approach to the interview process with candidates, which helps ease people in. I will tell candidates straight up that I don't care about perfection for [insert technical question], but that I want candidates to step through a problem and figure out a solid way to solve it (potentially with help), then retroactively optimize if they get hung up with trying to get the best solution off the bat due to typical interview pressures. In a way, solving the technical questions themselves are not the important part when I ask them (mostly) - it is the ability to walk through the problem and collaborate that I care about. Easing in the candidate is important to me when I interview - I want the candidate to feel comfortable with the team, and be more willing to volunteer important information for our evaluation. You cannot evaluate a candidate properly otherwise, since you might miss important cues that affect the evaluation.