Ask HN: How do you conduct take home coding exercises?

I quite like tests which are really open ended. If you get too specific, you can have 3 outcomes: they did it right, they did it wrong, you did it wrong. It seems like only the last one can lead to an interesting discussion in most cases. And if the problem is known, you may get a googled answer instead of real work.

I've seen a few open tests work well, but the one I created was (DevOps skills): Read rows from CSV, write them to database, print how many were written (in any language) - treat it as production quality app and impress us.

You can learn so much about people's approach and experience from this. Do they do documentation, do they handle non-us-ascii characters, do they handle errors (and how), do they create package ready for deployment, do they care about resource usage, and loads more.

The review was pretty much: are we impressed with the quality, thought put into it. We tried to assign some points to specific things, but quite often either we got impressed by something unexpected, or choice came down to the subjective quality.

Keep in mind that for some take-home is a very big no.

I mean, if I attend a full day of interviews on site, after 4-5 phone interviews, asking me to code over the weekend after all that will just make me wonder what's wrong with the company.