[jrochkind1]

Interesting idea.

Several of the solutions I encountered are just... plain done wrong. They have a bug, sure, but the bug's actually there cause it was written in a really hacky way instead of the simplest way that would implement the function.

I feel like it took me longer to find the bug in the hacky implementation than it would have to rewrite it 'right'.

(For instance, the 'right' way to find "largest integer with x number of digits" is clearly and inarguably `Math.pow(10, x) - 1`. Not the hacky 4-line-with-for-loop thing they showed me with a bug in it. No?)

I wonder if it would be interesting to have something like this run your solution through a simple test suite to see if it works (like my university professors used to do on our homework), instead of accepting only one exact right answer.

[blatherard]

This reminds me of more than one job interview I've had. One included a puzzler that was "fix this horribly convoluted javascript code by adding exactly four characters." I'd consider myself a pretty good bug finder-and-fixer. As in, I've read multiple books on debugging methods and even given some talks on effective debugging. Nevertheless, these kinds of stumpers make me freeze up.

I dunno exactly what puzzles like these demonstrate. That you spend a lot of time working in poorly written code?

[Too]

I've actually seen this mentality on production code. "The smaller the diff the better. And The less we change the less likely we are to introduce new bugs!!1".

[jrochkind1]

If you don't have tests, it's probably true.