I've asked variants of this question before, and although it is kind of good *for it's kind*, it's still a sort of algo leetcode-style question. Actually the b

I've asked variants of this question before, and although it is kind of good *for it's kind*, it's still a sort of algo leetcode-style question. Actually the best questions I ask, and the ones that give me the best candidate "signal" are what I call the "clean code" style questions (as in code that is simple, easy to extend, not necessarily Uncle Bob Clean Code). I'd rather not post examples here because I still use these questions, but the theme is as follows: * These questions ask to implement functionality that you could see in a (super simple) real world application. * They start super simple, and include several follow ups that increase in complexity. * No data structures and algos beyond the basics. Loops, lists, hash maps and little else. What most programmers would use on the job on a daily basis. I found in practice these work really well, specially with experienced programmers who can flex their low level design skills. People who ace leetcode style questions tend to do worse here, but no wonder, since they've been trained in a complete different style of interview.