Yeah, asking questions with multiple stages/progression, where the early stages are obvious but still provide signal through coding competency are good. Simila

Yeah, asking questions with multiple stages/progression, where the early stages are obvious but still provide signal through coding competency are good. Similarly, many small questions is going to give you a more accurate view than a single hard algorithm problem. There tends to be a trick or specific process to solve leetcode style problems, thus sessions are more black/white on whether the person makes that observation. Very unnatural to usual dev work. Interviews should never feel “hard” even if your threshold for success is high. There’s nothing that requires you to ask hard questions to get good candidates. By definition if your problems are perceived as “hard” then they aren’t assessing people on relevant skills, because a problem that is correlated with real world work shouldn’t be hard for anybody who is coding all day/every day. (Though somebody who is unskilled may find pretty much any problem hard, speaking more broadly here)