Unlike the other top solutions, this one will not mutate the input list (as stated in the requirements). It will generate a new list without the identified smallest element.

There are arguments both ways for the "truthiness" of comparing [] to [].

1. it should return True because nothing is equal to nothing squared
2. it should return False because there's nothing to compare and it doesn't make sense, as with NULL.

I'm in camp #2, but the phrasing is inherently vague. Is it really that difficult to say "comparing empty lists should return False (or True)"?

I would pick O(n^2) over O(n) if it's code that is A) quick to produce, B) readable and quickly understandable by those who will maintain it, and C) isn't running in "hot" code that's being called 100x per second.

While calculating the sum of the entire array and then shifting values from one side to the other is undeniably more computationally efficient, it's probably not your first instinct when presented this problem and will probably take you longer to get working. This is especially true with code that's more complex than this example.

IMO, good enough is perfect, until it's not good enough anymore. Once it's proven to be your biggest problem, then you can optimize it.

For those reasons, I would argue that this is best practice code. I would not argue that it's clever.