[esperent]

Not that I'm a fan of this kind of interview, but these answers illustrate different kinds of skill/intelligence.

One is domain knowledge which is less important in the age Google search and StackOverflow (and even less so in the age of LLMs but I guess interview techniques haven't caught up yet).

The second is the ability to understand a nested for loop, and if a coder can't do that by the point they reach an interview, it can probably never be taught.

It could be argued that being able to think up using a set in this instance is also an important skill, and I agree. But nested for loops are foundational skills, if the interviewee has problems there it's a good thing to know about early.

It could also be argued that they should just say directly "solve this using loops" if that's what they want, and well, yeah.

[IgorPartola]

A Bloom filter would be a way more fun solution. But I think the quiet part of this is that people conducting interviews just like to feel clever in knowing some puzzle and its answer. Make them feel good about their puzzle and they like you that much more as a candidate.

My favorite way to interview people is to ask them about their work and personal projects and about what parts of those were tricky, why, and how they solved those challenges. This gets candidates to talk much more openly about what experience they have and we can discuss real world practical problems down to having them show pseudo code (or showing off their GitHub repos of specific projects) that can very efficiently tell you how they think. It’s the equivalent of “tell me about bridges you have designed” vs “here are popsicle sticks, design a toy bridge” approach.