By quite deep, I meant that it's easily understandable, it's hard enough, and there are tons of different solutions. You can also see differences in recursion v

By quite deep, I meant that it's easily understandable, it's hard enough, and there are tons of different solutions. You can also see differences in recursion vs iterative, and talk about ordering and Gray codes, and all sorts of things. Many people I interviewed managed to do it, and I passed many people who didn't. Usually I start the question by saying: "this came up in my day to day job and I found it interesting. It seemed simple, but it took me a solid 2 hours to solve properly. I don't expect you to finish it during the interview, but I'd like to see what are you thoughts about how to solve this." For me it's a good question to assess: 1 If the person enjoys programming 2 If the person can articulate the problem to another person 3 If they are creative 4 To what degree they have a programming culture (how they talk about enumeration etc). If they finish in 5 minutes using recursion, then you can ask how to make it so the enumeration can be enumerated in parallel, which is very useful, and involves ordering/gray codes and what not.