I think Cheryl's Birthday puzzle is exactly an example of a terrible problem to evaluate a programmer with. If I was given a real-world problem similar in natu

I think Cheryl's Birthday puzzle is exactly an example of a terrible problem to evaluate a programmer with. If I was given a real-world problem similar in nature to that, my first question would be "why? what are you trying to accomplish?" with my focus looking for a way to fix the absolutely terrible input parameters. Secondly, what's the general case? I don't generally like to solve one-off problems where my code is scrapped after a single execution. So I will ask questions to figure out how to generalize this problem so my code can find the answer to the general case. Seeing as this is a puzzle problem -- convoluted for the sake of being a puzzle -- there's likely no good answers to my questions. The ironic part is the idea of puzzle questions are presumably to find critical thinkers, but the nature of being a puzzle means you can't be too much of a critical thinker. I've many times seen developers go down deep paths solving complex problems like this (especially for data interchange). While technically impressive, the better way is to avoid the complex problem by changing process at a higher level. If everyone blindly stays within the lines, you can end up with the sending side doing extra work to push out data in a complex format (thinking it's what the receiving side needs or wants), while the receiving side then does extra work to parse out the crazy format the sending side is using. The truly critical thinker steps back and asks "Why doesn't Cheryl just tell us her exact birthday?" and doesn't back down until they get a reasonable answer.