Earlier quoted context omitted.
Without leet coding, named algorithms (binary search, dynamic programming, and other esoterica) or data structures (only requiring knowledge of arrays, assoc arrays, loops is enough), coding interviews still allow you to demonstrate your thinking ability. You can construct various simple problems (that require only loops and arrays) that can easily be mapped to real world problems and see how well the programmers per…
You throw some good arguments and although I am not in agreement with such methodology let me ask would you apply the same process when hiring a senior engineer with a demonstrated experience of N+ years in tech you're looking for? Isn't that off putting and isn't that ingraining distrust from the very beginning?
Are open form questions for which the candidate can give an honest answer or that start a discussion better, or do you find them similar to a simple coding problem? What if during discussion I probe for more details about one particular thing?
Just to be clear, I agree that coding questions can be ridiculous. These do appear in some interviews. Questions related to quicksort, radix sort, counting sort, heaps, Dijkstra, 0-1 bfs, dfs, iterative deepening, prime testing or integer factoring, or convoluted problems of counting the many ways of tiling a n x m grid with 2x1 and 1x1 tiles, can all be found in the wild.
My buses problem is completely different and simpler.