Just to be clear, this wasn't my advice, it was written into the task description -

  This project tests your ability not only to code, but to deal with ambiguity and open-endedness

I'm not sure how I feel about that to be honest. On one hand I get what they're shooting for in general by saying that. On the other, they're going to have some preconceived notion of what they want, and it's a bit of luck if you come close to that.

What about:

> And don't hesitate to tell us if you have any questions!

I personally have no problem dealing with "ambiguity and open-endedness" (and, in fact, enjoy it!), but my solution to this problem at every job that has had this issue is: talk to people and understand the problem.

Attempting to "mind-read" is the worst solution to ambiguity, and, in practice, nearly always leads to disaster.

Within the article, he details his attempts to get clarity/feedback and the response of the hiring manager is as vague as it gets

The way to deal with ambiguity and open endedness is by limiting scope and sticking to the unambiguous.

When the client can play with that, the scope can be expanded and additional features can be described.

What they want is someone they can work with. Take home tests are about cultural fit too.

That’s also where it helps to be a mind reader. :)

The best developers I've worked with have an uncanny knack for reading people's minds. (Of course, they are actually just really good at communicating and predicting what people want. But if you do it well enough it sure seems like mind reading.)

I agree, it's very fluffy. I think "testing with ambiguity" is the new version of "culture fit."

It's not really culture fit. I've used the open ended test before and it was a good filter for "can they walk the walk". Just some basic text processing, but only few people cared to mention error checking, tested Unicode behaviour, included any documentation, etc. It's "will you do the usual things without explicit prompting". (The assignment explicitly said you can call them out as something to do without fully implementing to save time)

So many poor interviews I've seen are what xkcd described once as "communicating poorly then acting smug when you're misunderstood".