Contrary to a common view, I believe that this approach actually imitates my daily interactions …

I like giving SWEs small coding problems but it's more of a filter against: a) The 90% of applicants who literally cannot code. Although I filter out 99.9% of those by screening CVs and a short telephone interview. b) They can be a point for more discussion. It's silly to give someone, in an interview setting, an exam question style problem and to make that a key factor in the interview. It's up there with giving someone tasks which could potentially take them an evening just for an interview. I've tried everything and I've had the best results by talking, digging into the details. Not only do you get a better idea of the person but it's really easy to rat out those who are less capable (especially those who've studied hard for exam questions but fail at everything else).

As an interviewer, what you do seems to make sense and I do similar interviews. Removing the pressure of memorizing leetcode question algorithms (yes almost everyone has to memorize for leetcode hard to solve <1hr, most will need to memorize for medium) puts both sides in a better mood. I also observed starting a process with easier questions still filters out the bad candidates (80%+). Once a candidate 3-4 rounds more open ended questions seem to be much more discriminative anyway.